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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 29.10.2020, 13:11   #1  
Blog bot is offline
Blog bot
Участник
 
24,301 / 817 (76) +++++++
Регистрация: 28.10.2006
ITmarketDA: История одной миграции с SQL Server 2012 на SQL Server 2016+ в системе Microsoft Dynamics AX 2012
Источник: 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/
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
Старый 29.10.2020, 14:15   #2  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,587 / 1757 (66) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Классно. "Как" обновлялись из статьи в целом понятно (непонятно правда как тестировали и почему изменения в trace flags и оптимизаторе стали открытием только при переезде продуктива). "Зачем", какие ставились цели (кроме "поиграться с Query Store") и были ли они достигнуты - решительно непонятно. Но если автор проявится в ветке, неистово заплюсую
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 29.10.2020 в 15:29.
Старый 31.10.2020, 21:03   #3  
sonik is offline
sonik
Участник
 
29 / 103 (4) +++++
Регистрация: 11.06.2002
Цитата:
Сообщение от 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).
Старый 31.10.2020, 23:06   #4  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,587 / 1757 (66) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от sonik Посмотреть сообщение
Спасибо. Творчество коллективное. Но я отвечу
Нагрузочный тест проводили на полной копии прода, но железо было чуть слабее. Тест заключался в запуске самых тяжелых пакетников типа разноски накладных за день по всем магазинам, формирование заказов товаров по всем магазинам и т.п.. Но засада с cardinality не выявилась на тестах. Новый оптимизатор вообще как-то очень станно работал. У нас после перехода не сразу начали возникать кривые планы. Т.е. он в целом работает, но как-то не стабильно. Наши DBA как-то не придали значения этому изменению при миграции
Но тестовый инстанс же он должны были настроить с теми же trace flags что и в продуктиве? Непонятно

Цитата:
Про "поиграться с Query Store" - это вы зря. Query Store - реально полезная штука. Для нагруженных баз мне кажется сейчас мастхэв просто. У нас это была одна из основных целей миграции. Мы, например, благодаря Query Store настроили автоматические алерты на аномально долго выполняющиеся запросы, чтобы привентивно отлавливать узкие места в системе
Ну это можно было бы и из DynamicsPerf тащить, без апгрейда. Помимо query store, были какие-то позитивные перемены, что-нибудь из этого списка, например в AlwaysOn ?
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: trud (2).
Старый 01.11.2020, 07:05   #5  
trud is offline
trud
Участник
Лучший по профессии 2017
 
990 / 1402 (48) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Я кстати тоже встречался с подобным странным поведением нового оптимизатора. У меня был запрос по полю таблицы которое содержало несколько миллионов пустых значений и несколько заполненных. И вот периодически(причем причина так же была непонятна) запрос переставал использовать индекс по этому полю. Причем логики смены плана с хорошего на плохой не было, иногда работало долго, иногда сбивалось быстро
Поиск выявил что Микрософт решал уже подобные проблемы, но у нас была версия новее, текущее предположение было что не до конца пофиксили. В итоге так-же решили сменой 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 и как это помогло решить хоть какие-то проблемы, я видел что на больших базах это работало плохо
За это сообщение автора поблагодарили: Vadik (1).
Старый 01.11.2020, 07:11   #6  
trud is offline
trud
Участник
Лучший по профессии 2017
 
990 / 1402 (48) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Vadik Посмотреть сообщение
Ну это можно было бы и из DynamicsPerf тащить, без апгрейда.
Тут кстати тоже интерестно, как можно настроить алерты на DynamicsPerf, которые показывали что-нибудь полезное. Я тут столкнулся что на нескольких последних проектах сбор статистики DynamicsPerf нагружал систему больше чем сама АХ, да и сам проект похоже заброшен Микрософтом судя по неактивности на гитхабе
https://github.com/PFEDynamics/DynamicsPerf/issues
Старый 01.11.2020, 16:17   #7  
Masel is offline
Masel
Участник
 
25 / 418 (14) +++++++
Регистрация: 19.09.2007
По поводу QueryStore. Да можно использовать наверное DynamicsPerf, можно вообще свою таблицу сделать и складывать туда джобом результаты системных хранимых процедур. Просто MS предоставляет встроенный (а не прикрученный сбоку) довольно удобный инструмент с графическим интерфейсом.

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

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

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

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

По поводу расчета кардинальности На сколько я помню там было очень много странных планов, и пришлось много план гайдов сделать, чтобы снять "пожар" начальный. Больше всего такое удивляло. Есть запрос к таблице в 100 тысяч строк с единственным фильтром по полю из некластерного индекса. Тут даже без статистики понятно, что оптимизатор должен сделать index seek по этому полю и далее по результату lookup на кластерный. Но оптимизатор ищет по кластерному. Пересчитываешь статикику фулсканом, ставишь конкретные значения параметров, все равно кластерный индекс. Поведение такое, как будто там 10 строк. При переключении на старый алгоритм все эти странности пропадают.
Миниатюры
Нажмите на изображение для увеличения
Название: QueryStore.jpg
Просмотров: 289
Размер:	193.6 Кб
ID:	12979  
За это сообщение автора поблагодарили: Vadik (63), sukhanchik (40), trud (10), AlexeyS (11), sonik (2), AlGol (3).
Старый 01.11.2020, 20:29   #8  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,587 / 1757 (66) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Masel Посмотреть сообщение
Имеются ввиду в первую очередь уведомления на основе раздела regressed queries
Это какие-то кастомные отчеты ? Стандартный query store уведомлений ведь не рассылает?
__________________
-ТСЯ или -ТЬСЯ ?
Старый 03.11.2020, 17:08   #9  
sonik is offline
sonik
Участник
 
29 / 103 (4) +++++
Регистрация: 11.06.2002
Цитата:
Сообщение от Vadik Посмотреть сообщение
Это какие-то кастомные отчеты ? Стандартный query store уведомлений ведь не рассылает?
Да, это не query store. Мы аутсорсим этот сервис у одной компании, которая консульирует нас по администрированию скуля.
По сути это заббикс, который дергает какие-то хранимки. Все потроха нам пока не доступны.
Но это не какой-то грааль. Мы уже общались с несколькими конторами с рынка, которые специализируетсчя на аутсорсе DBA. В том или ином виде такой мониторинг с алертами есть у всех из них. Там еще есть много полезных алертов, типа аномально долгих блокировок, запросов которые выжирают tempDB или долго висящие открытые транзакции.
Причем под нас этот мониторинг докрутили, и он вместе с кодом сессии скуля присылает аксаптовый код сессии и юзера. А если это пакетная задача - название пакетной задачи.
Теги
alwayson, ax2012r2, cardinality, cbo, legacy_cardinality_estimation, sql server 2016

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: AX Performance Troubleshooting Checklist Part 2 Blog bot DAX Blogs 0 09.09.2014 16:11
emeadaxsupport: AX Performance Troubleshooting Checklist Part 1A [Introduction and SQL Configuration] Blog bot DAX Blogs 0 05.09.2014 21:11
crminthefield: Podcast and Overview: Microsoft Dynamics CRM 2011 Update Rollup 17 Blog bot Dynamics CRM: Blogs 0 10.05.2014 06:30
crminthefield: Podcast and Overview: Microsoft Dynamics CRM 2011 Update Rollup 11 Blog bot Dynamics CRM: Blogs 0 06.10.2012 05:27
CRM DE LA CREME! Configuring Microsoft Dynamics CRM 4.0 for Internet-facing deployment Blog bot Dynamics CRM: Blogs 0 18.08.2009 11:05
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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