Удаление InventSettlemens

[Vadik]

Цитата:

Сообщение от mazzy

А по-моему, "отсутствие в индексах" - просто ошибка.
Причем понятно откуда она взялась - просто не тестируют с отмененными закрытиями.

Ну это как посмотреть. Если регулярно проводить ТО системы, включающее удаление отмененных сопоставлений в прошлых периодах, то селективность и соответственно польза от такого индекса радостно стремится к нулю. Так что если вы N-цать лет экспериментировали с закрытием склада и не чистили InventSettlement, то соотношение "хороших" и "плохих" сопоставлений и количество данных будут такие, что оптимизатору будет дешевле запустить один table scan чем миллионы раз метаться от записей в индексе к страницам с данными. В этом случае очистка частями по дате сопоставления (TransDate) вам в помощь, благо поле проиндексировано неоднократно

[Zabr]

Цитата:

Сообщение от Vadik

то селективность и соответственно польза от такого индекса радостно стремится к нулю.

Это да, но меня на самом деле интересовала скорость чистки, сколько времени моя база будет шуршать по 53 миллионам записей без индекса по нужному полю.

[Vadik]

Цитата:

Сообщение от Zabr

Это да, но меня на самом деле интересовала скорость чистки, сколько времени моя база будет шуршать по 53 миллионам записей без индекса по нужному полю.

Если отмененных сопоставлений много (миллионы), независимо от того насколько быстро они найдутся (по индексу или нет), их еще потребуется удалить, так что все равно это довольно затратная по вводу-выводу операция и ее так или иначе придется бить на части (и тут индекс по дате сопоставления будет полезен)

[Zabr]

Цитата:

Сообщение от Vadik

Если отмененных сопоставлений много (миллионы)

Всего 53,7 млн, из них отмененных 3,7 млн. Вообще, имеет смысл чистить при таком раскладе, что посоветуете?

[Vadik]

Цитата:

Сообщение от Zabr

Всего 53,7 млн, из них отмененных 3,7 млн. Вообще, имеет смысл чистить при таком раскладе, что посоветуете?

Я бы почистил, профилактики ради и экономии места для - производительности особой это не прибавит. Если планируете запускать такую очистку регулярно и используете SQL Server 2008, можете создать filtered index (WHERE CANCELLED = 1) - получится симпатично, эффективно и не громоздко

[Zabr]

Почистил. Заняло 7 часов. Удалилось 10,1 млн сопоставлений, добавилось 6,5 млн, итого уменьшение на 3,6 млн. записей. Посмотрел на таблицу в Sql management studio .. и очень сильно удивился занимаемому объему в базе: ОН ВЫРОС! Число записей - да, сократилось. Но занимаемое место в базе: было 14 Гб данные + 14 Гб индексы, стало 13 Гб данные + 20 Гб индексы. Почему вдруг настолько сильно (на 50%) выросло место занимаемое индексами, если число записей сократилось?
Vadik, есть версии ?

[Vadik]

Цитата:

Сообщение от Zabr

Почистил. Заняло 7 часов. Удалилось 10,1 млн сопоставлений, добавилось 6,5 млн
..
Почему вдруг настолько сильно (на 50%) выросло место занимаемое индексами, если число записей сократилось?

Если не углубляться в технические подробности - это пройдет после перестройки индексов

[sukhanchik]

Цитата:

Сообщение от Zabr

Это да, но меня на самом деле интересовала скорость чистки, сколько времени моя база будет шуршать по 53 миллионам записей без индекса по нужному полю.

Тогда гораздо быстрее сделать копию таблицы (средствами СУБД), в которую перелить только нужные записи (тоже средствами СУБД), после чего грохнуть исходную таблицу, а копию переименовать в исходную таблицу. Гораздо быстрее все получится.

Только надо учесть, что имена индексов уникальны в БД (MS SQL Server) и полную копию таблицы с индексами создать не получится, если не переименовать помимо таблицы еще и индексы.
Я создавал копию таблицы без индексов - туда все переливал, после чего синхронизировал табличку (после удаления исходной таблицы)