Удаление InventSettlemens

[Zabr]

Цитата:

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

Удалить можно те, что с Canceled = 1

В таком случае, непонятно отсутствие во всех индексах на таблице поля Canceled (я уж молчу об отдельном индексе под это дело...). То есть, похоже, разработчики таким вот образом как бы намекают, что не стоит этого делать...

[fed]

Цитата:

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

В таком случае, непонятно отсутствие во всех индексах на таблице поля Canceled (я уж молчу об отдельном индексе под это дело...). То есть, похоже, разработчики таким вот образом как бы намекают, что не стоит этого делать...

В таком случае, непонятно наличие оператора

delete_from inventSettlement
        index hint ItemDateIdx
        where inventSettlement.ItemId       == _inventTable.ItemId              &&
              inventSettlement.Cancelled    == NoYes::Yes                       &&
              inventSettlement.SettleModel  != InventSettleModel::PhysicalValue &&
              inventSettlement.TransDate    <  transDateDel;

в методе inventCostCleanup.updateDelSettlement(). На что же нам намекают его авторы ?

А если говорить по делу, то та функциональность которая нужна топикстартеру присутствует в этом самом классе inventCostCleanup. Разница только в том, что он проводки по ГК не удаляет, а сторнирует. (О чем уже было сказано Raven Melancholic).
Если написать свой класс, который удаляет отмененные записи в inventSettlement, проводки по ГК (с аккуратным пересчетом балансов в ledgerBalanceDim / LedgerBalanceDimTrans) и сопутствующую запись в inventClosing, то можно добиться полного удаления следов закрытия/пересчета склада. Я конечно знаю, что это методологически неверно, но во время запуска системы мне приходилось для устранения последствий собственных ошибок такие классы писать.

[mazzy]

Цитата:

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

В таком случае, непонятно отсутствие во всех индексах на таблице поля Canceled (я уж молчу об отдельном индексе под это дело...). То есть, похоже, разработчики таким вот образом как бы намекают, что не стоит этого делать...

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

[Zabr]

Цитата:

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

А по-моему, "отсутствие в индексах" - просто ошибка.

Да, конечно, про намёки я ж просто пошутил. У меня например inventsettlement - 53 млн. записей на 28 Гб (данные+индексы),.

[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) - получится симпатично, эффективно и не громоздко

[sukhanchik]

Цитата:

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

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

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

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