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

[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

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

Это большой и достаточно нагруженный бизнес на нескольких континентах, работающий 24x7, и несколько часов (4-5) в неделю на обслуживание когда активность в приложении низкая, склад при этом полностью не останавливается. в 2020 у них было порядка 50М в InventDim / InventSum, некоторые склады в течение дня генерят несколько десятков тысяч резервирований в сутки, сейчас должно быть больше. Некоторые склады начинают работать раньше, сильнее нагружены и приоритетнее (если до них очередь не дойдет несколько недель подряд, жди беды). Если бы был один простой сетап с 5-10 последовательными шагами которые отрабатывают за минуту-две, они бы его сделали на тех же batch task-ах и забыли про него. Но почему-то не получается, поэтому да, следят