|
31.10.2020, 21:03 | #1 |
Участник
|
Цитата:
Сообщение от Vadik
Классно. "Как" обновлялись из статьи в целом понятно (непонятно правда как тестировали и почему изменения в trace flags и оптимизаторе стали открытием только при переезде продуктива). "Зачем", какие ставились цели (кроме "поиграться с Query Store") и были ли они достигнуты - решительно непонятно. Но если автор проявится в ветке, неистово заплюсую
Нагрузочный тест проводили на полной копии прода, но железо было чуть слабее. Тест заключался в запуске самых тяжелых пакетников типа разноски накладных за день по всем магазинам, формирование заказов товаров по всем магазинам и т.п.. Но засада с cardinality не выявилась на тестах. Новый оптимизатор вообще как-то очень станно работал. У нас после перехода не сразу начали возникать кривые планы. Т.е. он в целом работает, но как-то не стабильно. Наши DBA как-то не придали значения этому изменению при миграции. Кстати универсальный DBA и тюининг производительности Аксапты - это вообще отдельная тема для обсуждения. Мое мнение, что действительно стоящих результатов в оптимизации может добиться только сильный Аксаптер с глубоким знанием SQL Server и бизнес логики системы. Про "поиграться с Query Store" - это вы зря. Query Store - реально полезная штука. Для нагруженных баз мне кажется сейчас мастхэв просто. У нас это была одна из основных целей миграции. Мы, например, благодаря Query Store настроили автоматические алерты на аномально долго выполняющиеся запросы, чтобы привентивно отлавливать узкие места в системе. |
|
|
За это сообщение автора поблагодарили: sukhanchik (10), Vadik (63), trud (5), novic (1), AlGol (2), gl00mie (5). |
31.10.2020, 23:06 | #2 |
Модератор
|
Цитата:
Сообщение от sonik
Спасибо. Творчество коллективное. Но я отвечу
Нагрузочный тест проводили на полной копии прода, но железо было чуть слабее. Тест заключался в запуске самых тяжелых пакетников типа разноски накладных за день по всем магазинам, формирование заказов товаров по всем магазинам и т.п.. Но засада с cardinality не выявилась на тестах. Новый оптимизатор вообще как-то очень станно работал. У нас после перехода не сразу начали возникать кривые планы. Т.е. он в целом работает, но как-то не стабильно. Наши DBA как-то не придали значения этому изменению при миграции Цитата:
Про "поиграться с Query Store" - это вы зря. Query Store - реально полезная штука. Для нагруженных баз мне кажется сейчас мастхэв просто. У нас это была одна из основных целей миграции. Мы, например, благодаря Query Store настроили автоматические алерты на аномально долго выполняющиеся запросы, чтобы привентивно отлавливать узкие места в системе
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: trud (2). |
01.11.2020, 07:11 | #3 |
Участник
|
Тут кстати тоже интерестно, как можно настроить алерты на DynamicsPerf, которые показывали что-нибудь полезное. Я тут столкнулся что на нескольких последних проектах сбор статистики DynamicsPerf нагружал систему больше чем сама АХ, да и сам проект похоже заброшен Микрософтом судя по неактивности на гитхабе
https://github.com/PFEDynamics/DynamicsPerf/issues |
|
Теги |
alwayson, ax2012r2, cardinality, cbo, legacy_cardinality_estimation, sql server 2016 |
|
|