Denis Trunin's Blogs: Implementing Dynamics AX 2009/2012 database cleanup

[trud]

Ну идея была как раз в том, чтобы не удалять неделями и выполнять удаление без остановки. А так да, если это устраивает(плюс десятки разных джобов в разных компаниях), то это и не надо.
Какой-то обработки исключений осознано нет, если они случились, пакет должен падать, т.е. исключение при удалении данных показывает что что-то явно пошло не так.
По "DeleteActions" - предполагается что должен быть анализ который выявит таблицы и связи между ними. Я об этом написал. Да и в принципе даже если что-то останется, это можно доудалить
К тому же если посмотрите примеры, там миксуются подходы, т.е. для таблиц со сложной структурой используется стандартный while select delete, т.е. опять же надо смотреть что лучше подходит
Т.е. данный framework позволит вам решать разные задачи, если взять ваш пример когда оно работало неделю, вы также можете написать класс в данном стиле, при этом получите базовый интерфейся для запуска и возможность отобразить прогресс, чтобы понять работает ваш джоб или нет, объем кода по сути вырастет незначительно.

Но если таблица простая, то зачем нагружать сервер выполняя часами этот while select?

Цитата:

Далее SQL-скриптами:
* перенести нужный 1-5% записей в stage таблицы,
* сделать truncate table (не задействует transaction log)
* перенести нужные записи из stage обратно в рабочие.

Это будет работать для простых таблиц а для каких нибудь SalesParm.. где нет прямого условия для переноса связанных таблиц так не получится. Опять же вопрос - зачем делать остановку, если можно ее не делать

Цитата:

есть огромная вероятность переполнить диск на котором лежит TransactionLog

Чтобы не переполнить лог, нужно делать бекап этого лога(стандартно это раз в 15 минут). Быстрый способ вряд ли удалит больше чем пару гигабайт за это время. Т.е. с этой частью должно быть все нормально