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

[trud]

Ну batchjobhistory это не особо нагруженная табличка. Из последних примеров - это проект аудита производительности и InventSum на 70млн записей большинство из которых закрыто и работающая 24*7 система.
Ну т.е. альтернатива это то что написал mazzy, останавливать систему, переливать данные. Но на практике такое довольно сложно сделать.
С описанным подходом удаляло где-то полдня, нагрузку особо не давало и ничего не блокировало.
Ну и получилось продолжить проект, решая уже другие проблемы

[mazzy]

Цитата:

Сообщение от Blog bot

Describes a custom framework for performing a periodic database cleanup

Цитата:

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

Ну batchjobhistory это не особо нагруженная табличка. Из последних примеров - это проект аудита производительности и InventSum на 70млн записей большинство из которых закрыто и работающая 24*7 система.

Тут либо крестик, либо трусы.
Либо таки "periodic database cleanup", либо внезапно "70млн записей большинство из которых закрыто"

[trud]

Цитата:

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

Тут либо крестик, либо трусы.

Идея состояла в том, чтобы сделать что-то универальное. т.е. класс очистки состоит из пустого метода execute, переданной таблицы с параметрами и режима запуска.
что туда писать это дело разработчика. Ну т.е. хочешь удаление со всеми методами и delete actions, которое работает неделю - пишешь так, плюс в базом классе есть некоторые вспомогательные методы для логирования промежуточного прогресса. Согласись что смотреть на джоб который работает неделю не понимая что он делает и сполько осталось довольно сложно?
Хочешь быстрый SQL - пишешь быстрый SQL, опять же некоторые хелперы есть
Знаешь что уже есть стандартный класс, который "работает неплохо" и хочешь использовать его, используешь его.
Требования раздельного удаления по компаниям я не видел, но даже если и будет - никто не мешает реализовать, структура очень базовая, поэтому и гибкая

[Vadik]

Цитата:

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

Идея состояла в том, чтобы сделать что-то универальное

Странно, мне казалось весь блог был про то насколько T-SQL быстрее архаичного X++, ну да ладно. Чем фреймворк отличается от batch job с множественными batch tasks - тоже решительно непонятно.

P.S. Заставить onhand cleanup / aggregation бодаться с параллельно работающим consistency check, это конечно мощный аргумент в пользу кастомного фреймворка - один сворачивает, другой разворачивает, работа кипит - красота. А склад там параллельно не закрывался и реиндексация не шла? Ну, чтобы уж наверняка

Цитата:

Требования раздельного удаления по компаниям я не видел, но даже если и будет - никто не мешает реализовать, структура очень базовая, поэтому и гибкая

Это как мне кажется базовое требование для бизнеса с операциями в нескольких странах / регионах. И, повторюсь - зачем реализовывать второй RunBaseBatch, стандартный вроде не так уж плох ?

[trud]

Цитата:

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

Это как мне кажется базовое требование для бизнеса с операциями в нескольких странах / регионах. И, повторюсь - зачем реализовывать второй RunBaseBatch, стандартный вроде не так уж плох ?

А как вы делаете очистку InventSum. Там 3 джоба(агрегирование, wms, on-hadn), которые нужно запускать в каждой компании. Ну т.е. если много компаний запускаете много джобов? в одно и тоже время или разбиваете?
Как делаете очистку SalesParm..? Она точно блокирует текущие обработки, т.е. кто-то должен озадачится запуском когда не обрабатываются заказы
Я не работал с разными регионами в одной системе, у них что разные параметры для заданий очистки в зав-ти от компании?
Т.е. вот так это выглядит в предложенном решении, одна форма настройки на все, один batch job на все, статистика в разрезе по задаче

Т.е. основная задача которая решается - реализовать периодическую очистку и убедиться что она работает как ожидается, не входит в конфликт с существующими процессами в системе

[Vadik]

Цитата:

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

Я не работал с разными регионами в одной системе, у них что разные параметры для заданий очистки в зав-ти от компании?

Разные временные зоны и разные рабочие календари (например, в заливе - воскресенье-четверг, прочие страны понедельник-пятница)

Цитата:

А как вы делаете очистку InventSum. Там 3 джоба(агрегирование, wms, on-hadn), которые нужно запускать в каждой компании. Ну т.е. если много компаний запускаете много джобов? в одно и тоже время или разбиваете?

Раньше делали только WHS (InventSum+WHSInventReserve), сейчас добавили агрегацию. Да, отдельными джобами без перекрытия. На самом деле, некоторые крупные регионы еще отдельные джобы по сайтам/складам используют (т.е. каждое задание хранит свои параметры). Если все это реализовывать в фреймворке, думаю на выходе второй RunBaseBatch получится

Цитата:

Как делаете очистку SalesParm..? Она точно блокирует текущие обработки, т.е. кто-то должен озадачится запуском когда не обрабатываются заказы

Я не припомню проблем связанных с ростом XXXParm таблиц (ну кроме собственно роста БД). Эту очистку не автоматизировал

[trud]

Цитата:

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

На самом деле, некоторые крупные регионы еще отдельные джобы по сайтам/складам используют (т.е. каждое задание хранит свои параметры).

А зачем это делается? Ну т.е. кто-то протестировал и выявил что эти задания совсем не "неплохо" делают свою работу, а все же влияют на производительность(причем конкретного склада), для каждого склада составил свой график запуска(который периодически обновляется) когда нагрузка на складе минимальна?
Это мне видится огромным объемом админ работы, плюс кто-то должен на этим постоянно следить.
Или просто решили делать так?
И о каких объемах тут идет речь, сколько строк удаляется и как долго?
Ну т.е. основная идея, это создать функциональность где не надо будет заниматься такими настройками - для этого как раз понадобится реализация удаления через SQL, это практически не дает нагрузки, плюс ничего не блокирует (но для 2012 реализация конечно будет сложноватой)

[Vadik]

Цитата:

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

Ну batchjobhistory это не особо нагруженная табличка. Из последних примеров - это проект аудита производительности и InventSum на 70млн записей большинство из которых закрыто и работающая 24*7 система

2012 очистку и агрегацию InventSum из коробки уже неплохо сама делает. Фреймворк с хардкодом T-SQL в обход бизнес логики, кэша и виртуальных компаний но с индикацией прогресса (кому на него смотреть) ? Старею наверное, но - спасибо, я пас, будь он хоть на 40, хоть на 400% быстрее

[trud]

Цитата:

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

2012 очистку и агрегацию InventSum из коробки уже неплохо сама делает. Фреймворк с хардкодом T-SQL

Так я же в блоге написал, что InventSum в 2012 делается стандартными классами, они просто запускаются для каждой компании последовательно.
Ну т.е. что удобнее - 20 джобов(которые бы нежелательно запускать вместе) или один?
По факту люди кучу времени тратят на эту настройку если число компаний велико.или вообще забивают на это
По поводу смотреть на лог - он позволит быстро диагностировать проблемы. Из недавнего - клиент пожаловался что очистка InventSum(стандартная) не работает плюс стопит всю систему. Лог выявил что кол-во удаленных записей было больше 2 миллионов(что явно ненормально, это был не первый запуск).
Стандартная процедура на таких объемах довольно сильно притормаживает систему, до состояния пользователи звонят и жалуются(это по поводу вашего коментария что неплохо работает)
Оказалось что кто-то запустил проверку целостности системы, которая как оказалось пересоздает все удаленные InventSum.
Была дана рекомендация этого не делать
Ну т.е. без лога это было бы сложно понять, логи наше все

[mazzy]

Цитата:

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

Ну т.е. что удобнее - 20 джобов(которые бы нежелательно запускать вместе) или один?

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

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

кроме очистки бывают и другие задания, которые надо запускать подобным образом.
на мой взгляд, нет никаких причин, чтобы очистка сама занималась компаниями в обход стандартных механизмов.