ITmarketDA: История одной миграции с SQL Server 2012 на SQL Server 2016+ в системе Microsoft Dynamics AX 2012

[Blog bot]

Источник: https://habr.com/ru/post/525558/
==============

История одной миграции с SQL Server 2012 на SQL Server 2016+ в системе Microsoft Dynamics AX 2012

Всем привет!

На первый взгляд в 2020-ом году тема может показаться не актуальной. Но версия Axapta 2012 еще достаточно популярна, и многие проекты до сих пор активно развиваются на этой версии. Кроме того, информация из топика будет полезна и для тех, кто мигрирует на новейшую версию Dynamics 365 FO.

Читать далее

Источник: https://habr.com/ru/post/525558/

[Vadik]

Классно. "Как" обновлялись из статьи в целом понятно (непонятно правда как тестировали и почему изменения в trace flags и оптимизаторе стали открытием только при переезде продуктива). "Зачем", какие ставились цели (кроме "поиграться с Query Store") и были ли они достигнуты - решительно непонятно. Но если автор проявится в ветке, неистово заплюсую

[sonik]

Цитата:

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

Классно. "Как" обновлялись из статьи в целом понятно (непонятно правда как тестировали и почему изменения в trace flags и оптимизаторе стали открытием только при переезде продуктива). "Зачем", какие ставились цели (кроме "поиграться с Query Store") и были ли они достигнуты - решительно непонятно. Но если автор проявится в ветке, неистово заплюсую

Спасибо. Творчество коллективное. Но я отвечу
Нагрузочный тест проводили на полной копии прода, но железо было чуть слабее. Тест заключался в запуске самых тяжелых пакетников типа разноски накладных за день по всем магазинам, формирование заказов товаров по всем магазинам и т.п.. Но засада с cardinality не выявилась на тестах. Новый оптимизатор вообще как-то очень станно работал. У нас после перехода не сразу начали возникать кривые планы. Т.е. он в целом работает, но как-то не стабильно. Наши DBA как-то не придали значения этому изменению при миграции.
Кстати универсальный DBA и тюининг производительности Аксапты - это вообще отдельная тема для обсуждения. Мое мнение, что действительно стоящих результатов в оптимизации может добиться только сильный Аксаптер с глубоким знанием SQL Server и бизнес логики системы.
Про "поиграться с Query Store" - это вы зря. Query Store - реально полезная штука. Для нагруженных баз мне кажется сейчас мастхэв просто. У нас это была одна из основных целей миграции. Мы, например, благодаря Query Store настроили автоматические алерты на аномально долго выполняющиеся запросы, чтобы привентивно отлавливать узкие места в системе.

[Vadik]

Цитата:

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

Спасибо. Творчество коллективное. Но я отвечу
Нагрузочный тест проводили на полной копии прода, но железо было чуть слабее. Тест заключался в запуске самых тяжелых пакетников типа разноски накладных за день по всем магазинам, формирование заказов товаров по всем магазинам и т.п.. Но засада с cardinality не выявилась на тестах. Новый оптимизатор вообще как-то очень станно работал. У нас после перехода не сразу начали возникать кривые планы. Т.е. он в целом работает, но как-то не стабильно. Наши DBA как-то не придали значения этому изменению при миграции

Но тестовый инстанс же он должны были настроить с теми же trace flags что и в продуктиве? Непонятно

Цитата:

Про "поиграться с Query Store" - это вы зря. Query Store - реально полезная штука. Для нагруженных баз мне кажется сейчас мастхэв просто. У нас это была одна из основных целей миграции. Мы, например, благодаря Query Store настроили автоматические алерты на аномально долго выполняющиеся запросы, чтобы привентивно отлавливать узкие места в системе

Ну это можно было бы и из DynamicsPerf тащить, без апгрейда. Помимо query store, были какие-то позитивные перемены, что-нибудь из этого списка, например в AlwaysOn ?

[trud]

Я кстати тоже встречался с подобным странным поведением нового оптимизатора. У меня был запрос по полю таблицы которое содержало несколько миллионов пустых значений и несколько заполненных. И вот периодически(причем причина так же была непонятна) запрос переставал использовать индекс по этому полю. Причем логики смены плана с хорошего на плохой не было, иногда работало долго, иногда сбивалось быстро
Поиск выявил что Микрософт решал уже подобные проблемы, но у нас была версия новее, текущее предположение было что не до конца пофиксили. В итоге так-же решили сменой Cardinality Estimator на старый

Cumulative Udpate 4 for SQL Server 2016 SP2
https://support.microsoft.com/en-au/...lity-estimator

Цитата:

Assume that you have Microsoft SQL Server 2014, 2016 and 2017 installed. You have a table column that contains many null values, and you execute a query on that table by using the default Cardinality Estimator (CE). In this scenario, you may experience an overestimation in a filter that compares the table column to a value that's unknown at compile time.

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

[trud]

Цитата:

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

Ну это можно было бы и из DynamicsPerf тащить, без апгрейда.

Тут кстати тоже интерестно, как можно настроить алерты на DynamicsPerf, которые показывали что-нибудь полезное. Я тут столкнулся что на нескольких последних проектах сбор статистики DynamicsPerf нагружал систему больше чем сама АХ, да и сам проект похоже заброшен Микрософтом судя по неактивности на гитхабе
https://github.com/PFEDynamics/DynamicsPerf/issues

[Masel]

По поводу QueryStore. Да можно использовать наверное DynamicsPerf, можно вообще свою таблицу сделать и складывать туда джобом результаты системных хранимых процедур. Просто MS предоставляет встроенный (а не прикрученный сбоку) довольно удобный инструмент с графическим интерфейсом.

Там все основное необходимое присутствует в одном окне. Можно менять период для анализа, смотреть сколько раз запрос выполнялся, какое минимальное время, какое максимальное, какое среднее для каждого плана запроса. Можно менять сам анализируемый показатель - процессорное время, общее время, логическое чтение и т.д. Тут же можно взять готовый план, чтобы сделать план гайд. Вообще это предусмотрено одной кнопкой forcePlan в той же форме, но с аксаптой это не работает, приходится делать по старинке.
Основное полезное применение, если запрос сильно тормозит, то можно зайти в эту форму, он наверняка будет в топе, перейти в анализ запроса, посмотреть на большом периоде какие были планы и сколько в среднем выполнялся с ними запрос и выбрать самый быстрый, создать план гайд.

Правда без граблей тут у МС не обошлось. Во-первых на высоконагруженной базе QueryStore очень сильно растет в размерах. Если у вас маленький размер QueryStore, то она заполнится и станет readOnly, перестанет собирать статистику.
Во-вторых при переключении ноды always on субд считает своим долгом и священной обязанностью скопировать queryStore на новую праймари ноду (и это не отключается, по крайней мере раньше так было, давно не изучал вопрос). Пока копируется queryStore основная база не поднимается и надо ждать. Есть вариант выключить или уменьшить размер query store, но это накладывает блокировки на базу и все равно приходится ждать, хотя вроде и поменьше. Если queryStore маленькая по размеру, то ждать не долго. Но читайте п.1, маленький размер приводит к отказу сбора статистики.
Ну и в-третьих когда база большая, то форма с топ запросами очень долго открывается. Это смешно, но нужно прикрутить план гайд из интернета, чтобы она быстрее открывалась. То есть чтобы оптимизировать запросы нужно оптимизировать вначале инструмент.

По поводу уведомлений из QueryStore. Имеются ввиду в первую очередь уведомления на основе раздела regressed queries. То есть можно настроить уведомление, показывающее те запросы, среднее выполнение которых за текущий период сильно хуже, чем среднее выполнение в предыдущий исторический период. Это свидетельствует о том, что выбран не оптимальный план.

По поводу флагов. На тестовых базах тестировались сами операции. Наличие флагов никто не тестировал, т.к. никто не подумал, что они могут быть просто удалены с сервера. Об этом вообще должны были подумать админы БД, а не аксаптеры, но не подумали. Ошибки бывают. Статья для тех, кто хочет сделать аналогичный переход, чтобы не совершить ошибок.

По поводу расчета кардинальности На сколько я помню там было очень много странных планов, и пришлось много план гайдов сделать, чтобы снять "пожар" начальный. Больше всего такое удивляло. Есть запрос к таблице в 100 тысяч строк с единственным фильтром по полю из некластерного индекса. Тут даже без статистики понятно, что оптимизатор должен сделать index seek по этому полю и далее по результату lookup на кластерный. Но оптимизатор ищет по кластерному. Пересчитываешь статикику фулсканом, ставишь конкретные значения параметров, все равно кластерный индекс. Поведение такое, как будто там 10 строк. При переключении на старый алгоритм все эти странности пропадают.

[Vadik]

Цитата:

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

Имеются ввиду в первую очередь уведомления на основе раздела regressed queries

Это какие-то кастомные отчеты ? Стандартный query store уведомлений ведь не рассылает?

[sonik]

Цитата:

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

Это какие-то кастомные отчеты ? Стандартный query store уведомлений ведь не рассылает?

Да, это не query store. Мы аутсорсим этот сервис у одной компании, которая консульирует нас по администрированию скуля.
По сути это заббикс, который дергает какие-то хранимки. Все потроха нам пока не доступны.
Но это не какой-то грааль. Мы уже общались с несколькими конторами с рынка, которые специализируетсчя на аутсорсе DBA. В том или ином виде такой мониторинг с алертами есть у всех из них. Там еще есть много полезных алертов, типа аномально долгих блокировок, запросов которые выжирают tempDB или долго висящие открытые транзакции.
Причем под нас этот мониторинг докрутили, и он вместе с кодом сессии скуля присылает аксаптовый код сессии и юзера. А если это пакетная задача - название пакетной задачи.

[Logger]

Цитата:

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

Я кстати тоже встречался с подобным странным поведением нового оптимизатора. У меня был запрос по полю таблицы которое содержало несколько миллионов пустых значений и несколько заполненных. И вот периодически(причем причина так же была непонятна) запрос переставал использовать индекс по этому полю. Причем логики смены плана с хорошего на плохой не было, иногда работало долго, иногда сбивалось быстро
Поиск выявил что Микрософт решал уже подобные проблемы, но у нас была версия новее, текущее предположение было что не до конца пофиксили. В итоге так-же решили сменой Cardinality Estimator на старый

Cumulative Udpate 4 for SQL Server 2016 SP2
https://support.microsoft.com/en-au/...lity-estimator

Интересно, что в статье от MS указано про null values, а в аксапте обычно пустые строки или 0 в числовых столбцах. Видимо для такого случая то же самое.