AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 10.03.2021, 15:11   #1  
Blog bot is offline
Blog bot
Участник
 
25,459 / 846 (79) +++++++
Регистрация: 28.10.2006
Denis Trunin's Blogs: Implementing Dynamics AX 2009/2012 database cleanup
Источник: https://denistrunin.com/ax2012-sqldelete/
==============

Describes a custom framework for performing a periodic database cleanup

Источник: https://denistrunin.com/ax2012-sqldelete/
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
Старый 10.03.2021, 21:37   #2  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Я бы не стал такой способ применять. Ну во-первых где наши DeleteActions и где фильтрация по компаниям? Во вторых, код на голом SQL всегда сулит проблемы, если что-то сделать неаккуратно. Далее - где обработка эксепшенов и повторов, если что-то залочилось чем-то и нужно повторить? Если проблема блокировок есть, то уровень SQL может усугубить.
Что мешает сделать то же самое на X++? Если правильно приготовить код, то из AX он удаляется ничуть не хуже (отключить логи, отключить DeleteActions и обработать их отдельным шагом?). А ведь DeleteActions как раз таки одна из главных проблем при удалении parent tebles. А где выполняется логика из метода Delete()?

В общем случае задача быстрого удаления голым SQL не решается. Каждую удаляемую сущность нужно анализировать индивидуально, разбивать на последовательные логические шаги. В этом основная сложность и только такой подход применим.
В конечном итоге, если вы удаляете исторические записи с критерием по дате, то проблемы перформанса могут наблюдаться при первом запуске. Далее, если систематично удалять на ежедневной основе, то не вижу особых проблем с производительностью. Как-то так.
За это сообщение автора поблагодарили: mazzy (2), skuull (2).
Старый 10.03.2021, 21:49   #3  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Как-то встретил код, простой как грабли. Стояла задача удалить исторические записи, их там было под десяток миллионов. Товарищи не заморачивались: обычный WhileSeleсt выбирал и удалял порциями по, условно, 100 записей. Потом пауза пару секунд и новая порция. Удаляло оно несколько недель, круглосуточно. Но никто даже не заметил. На реализацию потратили наверное часа пол. А то, что оно удаляло неделями - не особо кого-то интересовало. Опять же, если это запускать ежедневно батчем, то и хлам копиться не будет.
За это сообщение автора поблагодарили: Vadik (1).
Старый 10.03.2021, 23:56   #4  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от DSPIC Посмотреть сообщение
Я бы не стал такой способ применять.
а вот поддержу своим +1

Цитата:
Сообщение от DSPIC Посмотреть сообщение
обычный WhileSeleсt выбирал и удалял порциями по, условно, 100 записей.
и тут даже не то, что код простой,
а то, что на ПРОДе скорее всего включен RecoveryModel=Full

и изменяя много записей быстро
есть огромная вероятность переполнить диск на котором лежит TransactionLog
и остановить фсё нафик. а потом получить многочасовой rollback.

или подобраться к самой границе ресурсов и получить бэкап из которого невозможно восстановить.

полностью согласен, что удалять надо порциями, сообразуясь с размерами дисков, политикой бэкапов и резервов под transaction log
__________________
полезное на axForum, github, vk, coub.
Старый 11.03.2021, 00:19   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Blog bot Посмотреть сообщение
Describes a custom framework for performing a periodic database cleanup
т.е. для periodic cleanup лучше удалять понемножку из самой аксапты со всеми delete action, validate и прочими бизнес-проверками (для надежности). скорость удаления ограничена не скокростью языка, а объемами дисков и памяти на SQL.

но есть случай, когда процедуру действительно приходится писать на T-SQL.
это ВНЕЗАПНЫЙ cleanup.
это когда "не было никогда и вот опять" база выросла и ВНЕЗАПНО заполнила ВСЁ.
в этом случае, нужно сохранить 1-5% от всех записей в логах, а остальное грохнуть как можно скорее.

в этом случае стоит попросить технологическое окно в несколько часов,
сделать stop world,
перевести базу в монопольный режим и (возможно) в Simple model.

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

затем вернуть базу из монополного режима в нормальный.
__________________
полезное на axForum, github, vk, coub.
Старый 11.03.2021, 04:04   #6  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Ну идея была как раз в том, чтобы не удалять неделями и выполнять удаление без остановки. А так да, если это устраивает(плюс десятки разных джобов в разных компаниях), то это и не надо.
Какой-то обработки исключений осознано нет, если они случились, пакет должен падать, т.е. исключение при удалении данных показывает что что-то явно пошло не так.
По "DeleteActions" - предполагается что должен быть анализ который выявит таблицы и связи между ними. Я об этом написал. Да и в принципе даже если что-то останется, это можно доудалить
К тому же если посмотрите примеры, там миксуются подходы, т.е. для таблиц со сложной структурой используется стандартный while select delete, т.е. опять же надо смотреть что лучше подходит
Т.е. данный framework позволит вам решать разные задачи, если взять ваш пример когда оно работало неделю, вы также можете написать класс в данном стиле, при этом получите базовый интерфейся для запуска и возможность отобразить прогресс, чтобы понять работает ваш джоб или нет, объем кода по сути вырастет незначительно.

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

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

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

Последний раз редактировалось trud; 11.03.2021 в 04:40.
Старый 11.03.2021, 09:43   #7  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Я хотел тоже про delete actions, но успели до меня. Хочется ещё добавить про код который могут дописать в делиты и прочий код который вы радостно игнорируете потенциально разваливая данные и ваш анализ не особо поможет если код допишут после анализа или его допишет вендор, который ваш код анализировать не будет
Старый 11.03.2021, 09:56   #8  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Процесс построен немного по другому - т.е. вы когда анализуете что удалять, вы обычно не хотите никаких delete action и тем более выполнения кода на delete методах. Иначе это как бы станно получается, а если эти данные которые допишет вендор не надо удалять? Т.е. мы же говорим о чистке базы, а не о какой-то пользовательской операции.
Т.е. представьте что кто-то добавит метод интеграции на очищаемую таблицу (к примеру в delete), и вы получите много интерестных сообщений

Большинство стандартных методов сделано с игнорированием delete action(и это как бы правильно на мой взгляд), т.е. тут ничего не развалится
Нажмите на изображение для увеличения
Название: DeleteAction.png
Просмотров: 328
Размер:	38.1 Кб
ID:	13132

Последний раз редактировалось trud; 11.03.2021 в 10:08.
За это сообщение автора поблагодарили: EVGL (2).
Старый 11.03.2021, 12:04   #9  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Удаление напрямую через SQL имеет одно большое преимущество: Можно просто использовать оператор типа
X++:
DELETE TOP(10000) FROM [dbo].[batchjobhistory]
WHERE enddatetime < Dateadd(day, -30, Getdate())
Старый 11.03.2021, 13:53   #10  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Так тоже можно, но без индекса по enddatetime будет блокировка всей таблицы. Можно конечно сделать индексов, но можно и без этого, только выбирать по enddatetime, а удаление делать по кластерным ключам

Последний раз редактировалось trud; 11.03.2021 в 13:56.
Старый 11.03.2021, 13:58   #11  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от trud Посмотреть сообщение
Так тоже можно, но без индекса по enddatetime будет блокировка всей таблицы. Можно конечно сделать индексов, но можно и без этого, только выбирать по enddatetime, а удаление деать по кластерным ключам
Ты знаешь - я тупо поэкспериментировал с числом удаляемых записей. Если его увеличить, действительно начинает явно конфликтовать с нормальным батч-процессом. Но при небольшом количестве, оно похоже что успевает отобрать эти 2-3-5-10 тысяч записей быстрее чем основной батч-процесс захочет чего-то записать.
Хотя да - в общем случае ты прав, если объем большой - то стоит подумать над индексами. У меня у одного клиента так чистятся история батчей, AIFMessageLog, EventCUD и inventLogSumTTS (там не мной была сделана доработка, которая записи не удаляет, а помечает к удалению, а ночной батч их потом чистит).

Последний раз редактировалось fed; 11.03.2021 в 15:51.
Старый 11.03.2021, 14:21   #12  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Ну batchjobhistory это не особо нагруженная табличка. Из последних примеров - это проект аудита производительности и InventSum на 70млн записей большинство из которых закрыто и работающая 24*7 система.
Ну т.е. альтернатива это то что написал mazzy, останавливать систему, переливать данные. Но на практике такое довольно сложно сделать.
С описанным подходом удаляло где-то полдня, нагрузку особо не давало и ничего не блокировало.
Ну и получилось продолжить проект, решая уже другие проблемы
Старый 11.03.2021, 15:53   #13  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Blog bot Посмотреть сообщение
Describes a custom framework for performing a periodic database cleanup
Цитата:
Сообщение от trud Посмотреть сообщение
Ну batchjobhistory это не особо нагруженная табличка. Из последних примеров - это проект аудита производительности и InventSum на 70млн записей большинство из которых закрыто и работающая 24*7 система.
Тут либо крестик, либо трусы.
Либо таки "periodic database cleanup", либо внезапно "70млн записей большинство из которых закрыто"

__________________
полезное на axForum, github, vk, coub.
Старый 11.03.2021, 15:54   #14  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от trud Посмотреть сообщение
Ну batchjobhistory это не особо нагруженная табличка. Из последних примеров - это проект аудита производительности и InventSum на 70млн записей большинство из которых закрыто и работающая 24*7 система
2012 очистку и агрегацию InventSum из коробки уже неплохо сама делает. Фреймворк с хардкодом T-SQL в обход бизнес логики, кэша и виртуальных компаний но с индикацией прогресса (кому на него смотреть) ? Старею наверное, но - спасибо, я пас, будь он хоть на 40, хоть на 400% быстрее
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 11.03.2021 в 15:57.
За это сообщение автора поблагодарили: mazzy (2).
Старый 11.03.2021, 16:50   #15  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Vadik Посмотреть сообщение
2012 очистку и агрегацию InventSum из коробки уже неплохо сама делает. Фреймворк с хардкодом T-SQL
Так я же в блоге написал, что InventSum в 2012 делается стандартными классами, они просто запускаются для каждой компании последовательно.
Ну т.е. что удобнее - 20 джобов(которые бы нежелательно запускать вместе) или один?
По факту люди кучу времени тратят на эту настройку если число компаний велико.или вообще забивают на это
По поводу смотреть на лог - он позволит быстро диагностировать проблемы. Из недавнего - клиент пожаловался что очистка InventSum(стандартная) не работает плюс стопит всю систему. Лог выявил что кол-во удаленных записей было больше 2 миллионов(что явно ненормально, это был не первый запуск).
Стандартная процедура на таких объемах довольно сильно притормаживает систему, до состояния пользователи звонят и жалуются(это по поводу вашего коментария что неплохо работает)
Оказалось что кто-то запустил проверку целостности системы, которая как оказалось пересоздает все удаленные InventSum.
Была дана рекомендация этого не делать
Ну т.е. без лога это было бы сложно понять, логи наше все
Старый 11.03.2021, 17:13   #16  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от trud Посмотреть сообщение
Ну т.е. что удобнее - 20 джобов(которые бы нежелательно запускать вместе) или один?
конечно один, который запускает в указанных компаниях (все, группы компаний, все в текущей виртуальной, еще как)

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

кроме очистки бывают и другие задания, которые надо запускать подобным образом.
на мой взгляд, нет никаких причин, чтобы очистка сама занималась компаниями в обход стандартных механизмов.
__________________
полезное на axForum, github, vk, coub.
Старый 11.03.2021, 17:45   #17  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от mazzy Посмотреть сообщение
Тут либо крестик, либо трусы.
Идея состояла в том, чтобы сделать что-то универальное. т.е. класс очистки состоит из пустого метода execute, переданной таблицы с параметрами и режима запуска.
что туда писать это дело разработчика. Ну т.е. хочешь удаление со всеми методами и delete actions, которое работает неделю - пишешь так, плюс в базом классе есть некоторые вспомогательные методы для логирования промежуточного прогресса. Согласись что смотреть на джоб который работает неделю не понимая что он делает и сполько осталось довольно сложно?
Хочешь быстрый SQL - пишешь быстрый SQL, опять же некоторые хелперы есть
Знаешь что уже есть стандартный класс, который "работает неплохо" и хочешь использовать его, используешь его.
Требования раздельного удаления по компаниям я не видел, но даже если и будет - никто не мешает реализовать, структура очень базовая, поэтому и гибкая
За это сообщение автора поблагодарили: mazzy (2), sukhanchik (6).
Старый 12.03.2021, 12:39   #18  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от trud Посмотреть сообщение
Идея состояла в том, чтобы сделать что-то универальное
Странно, мне казалось весь блог был про то насколько T-SQL быстрее архаичного X++, ну да ладно. Чем фреймворк отличается от batch job с множественными batch tasks - тоже решительно непонятно.

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

Цитата:
Требования раздельного удаления по компаниям я не видел, но даже если и будет - никто не мешает реализовать, структура очень базовая, поэтому и гибкая
Это как мне кажется базовое требование для бизнеса с операциями в нескольких странах / регионах. И, повторюсь - зачем реализовывать второй RunBaseBatch, стандартный вроде не так уж плох ?
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 12.03.2021 в 12:41.
Старый 12.03.2021, 13:40   #19  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Vadik Посмотреть сообщение
Это как мне кажется базовое требование для бизнеса с операциями в нескольких странах / регионах. И, повторюсь - зачем реализовывать второй RunBaseBatch, стандартный вроде не так уж плох ?
А как вы делаете очистку InventSum. Там 3 джоба(агрегирование, wms, on-hadn), которые нужно запускать в каждой компании. Ну т.е. если много компаний запускаете много джобов? в одно и тоже время или разбиваете?
Как делаете очистку SalesParm..? Она точно блокирует текущие обработки, т.е. кто-то должен озадачится запуском когда не обрабатываются заказы
Я не работал с разными регионами в одной системе, у них что разные параметры для заданий очистки в зав-ти от компании?
Т.е. вот так это выглядит в предложенном решении, одна форма настройки на все, один batch job на все, статистика в разрезе по задаче
Нажмите на изображение для увеличения
Название: OnHandCleanup.png
Просмотров: 86
Размер:	28.4 Кб
ID:	13134
Т.е. основная задача которая решается - реализовать периодическую очистку и убедиться что она работает как ожидается, не входит в конфликт с существующими процессами в системе

Последний раз редактировалось trud; 12.03.2021 в 13:53.
За это сообщение автора поблагодарили: gl00mie (5).
Старый 13.03.2021, 16:15   #20  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от trud Посмотреть сообщение
Я не работал с разными регионами в одной системе, у них что разные параметры для заданий очистки в зав-ти от компании?
Разные временные зоны и разные рабочие календари (например, в заливе - воскресенье-четверг, прочие страны понедельник-пятница)

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


Цитата:
Как делаете очистку SalesParm..? Она точно блокирует текущие обработки, т.е. кто-то должен озадачится запуском когда не обрабатываются заказы
Я не припомню проблем связанных с ростом XXXParm таблиц (ну кроме собственно роста БД). Эту очистку не автоматизировал
__________________
-ТСЯ или -ТЬСЯ ?
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: Calling AX 2012 Business Logic from SSIS Using a Script Task and Custom Web Service Blog bot DAX Blogs 0 12.11.2015 03:48
emeadaxsupport: AX Performance Troubleshooting Checklist Part 1B [Application and AOS Configuration] Blog bot DAX Blogs 0 05.09.2014 21:11
Dynamics AX на Convergence 2012 Blog bot Microsoft и системы Microsoft Dynamics 0 13.01.2012 10:52
DynamicsAxSCM: Visualizing Security in Microsoft Dynamics AX 2012 Blog bot DAX Blogs 0 29.08.2011 13:11
german_nav_developer: Buildnummern-Übersicht Microsoft Dynamics NAV 2009 Blog bot Dynamics CRM: Blogs 0 04.06.2010 13:21
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 02:01.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.