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

[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]

Цитата:

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

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

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