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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.05.2020, 16:11   #1  
Blog bot is offline
Blog bot
Участник
 
25,475 / 846 (79) +++++++
Регистрация: 28.10.2006
Denis Trunin's Blogs: Resolving performance issues caused by parameters sniffing in AX2012 and D365FO
Источник: https://denistrunin.com/performance-sniffing/
==============

The blog post compares ways how to solve SQL performance problems caused by parameters sniffing for AX2009/AX2012 and cloud version Dynamics 365 for Finance and Operations

Источник: https://denistrunin.com/performance-sniffing/
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
За это сообщение автора поблагодарили: raz (5), Logger (3).
Старый 07.05.2020, 17:27   #2  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Don't: Use plan guides as first mitigation step
https://academylive.blob.core.window...-DYN549PAL.pdf



Цитата:
Probably recently they created a new location, and this new location was the first parameter for this query and SQL Server based on the current statistics decided to start the plan with InventDim(that was probably OK for this new location with no data), the plan was cached and caused a performance problem for all other locations
Trace flag 2371 на SQL Server был включен? Статистики с какой периодичностью обновлялись?
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 07.05.2020 в 19:10.
За это сообщение автора поблагодарили: trud (1), raz (5).
Старый 08.05.2020, 05:51   #3  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
О, это презентация от людей которые рекомендовали везде update_recordset писать(https://denistrunin.com/understanding-sql-blocking/)
И они же рекомендуют запускать переиндексацию для борьбы с неправильными планами, это я как-то пропустил, спасибо за ссылку
У Брента есть отличное видео по этому поводу
https://www.youtube.com/watch?v=iEa6_QnCFMU
Цитата:
Сообщение от Vadik Посмотреть сообщение
Trace flag 2371 на SQL Server был включен? Статистики с какой периодичностью обновлялись?
Так пост как раз и том, что не надо этого делать. Более частый сбор статистики никак не решит проблему, у вас просто будет система то быстее, то медленнее работать.Плюс больше нагружаться этим самым сбором статистики. В АХ никакие планы не должны меняться от времени
Вообще их презентация показывает что они сами это никогда не делали, к примеру, вам звонит клиент, вы подключаетесь и видите проблемы, разберем советы которые они дают

As a first step... try to tune expensive code / queries
Add/change indexes - т.е. у клиента все тормозит, и мы прямо на рабочей будем добавлять индексы? Хотя как разбор итогов, это правильный совет
•Increase selectivity - этот совет я не понял. "Надо писать правильный код, а неправильный писать не надо". Сложно спорить
Add hints - в АХ2012 к примеру index_hints не работает. К тому же куда их добавлять то
Rebuild indexes - так делать точно не надо
Update statistics - и так тоже
Apply other code changes (e.g. change pattern) - опять непонятный совет. пишите производительный код, ну ок
Т.е. более правильный порядок разрешения
Цитата:
Run a top SQL query and copy results to Excel(you can copy all columns except the last one - "query_plan")
Click on the last column - "query_plan" for the first 3-5 rows
Save them to separate files with .sqlplan extension
Try to clear the SQL cache with DBCC FREEPROCCACHE command
Т.е. мы сохраняем историю, решаем проблему сейчас, передаем ее техническому специалисту. Если у него есть время(и он вообще есть), то он уже решает в меру своих способностей и что более важно бюджета - ну т.е. лучшее решение это конечно добавить индексы, или менять код

Последний раз редактировалось trud; 08.05.2020 в 06:04.
За это сообщение автора поблагодарили: Logger (5).
Старый 12.05.2020, 09:14   #4  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от trud Посмотреть сообщение
О, это презентация от людей которые рекомендовали везде update_recordset писать(https://denistrunin.com/understanding-sql-blocking/)
Помню, разбирали. Сошлись на том, что не все так однозначно
Цитата:
И они же рекомендуют запускать переиндексацию для борьбы с неправильными планами, это я как-то пропустил
"Переиндексацию для борьбы с неправильными планами" я видимо тоже пропустил - можете дать ссылку на первоисточник? А если не зацикливаться на планах исполнения, то из некоторых сценариев (например, массовые forwarded records) - выходов кроме регулярной перестройки индексов (ну или изменения схемы) в общем-то и нет
Цитата:
В АХ никакие планы не должны меняться от времени
Верно для случая когда версия и схема БД, объем и распределение данных тоже "заморожены", т.е. где-то между "крайне редко" и "никогда" Собственно, поэтому я plan guide-ами стараюсь не злоупотреблять
Цитата:
Вообще их презентация показывает что они сами это никогда не делали
Возможно, Вы просто немного предвзяты
__________________
-ТСЯ или -ТЬСЯ ?
Старый 12.05.2020, 09:36   #5  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,894 / 5650 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Vadik Посмотреть сообщение
"Переиндексацию для борьбы с неправильными планами" я видимо тоже пропустил - можете дать ссылку на первоисточник? А если не зацикливаться на планах исполнения, то из некоторых сценариев (например, массовые forwarded records) - выходов кроме регулярной перестройки индексов (ну или изменения схемы) в общем-то и нет
По моим наблюдениям, если перестроение индексов по таблице помогло с кривым планом исполнения, то в 98% случаев это случилось только потому что при перестроении был сброшен план исполнения, а следующий план исполнения был более удачным (то есть - имеем ситуацию неудачного parameters sniffing и plan guide может помочь). И только примерно в 2% случаев, перестроение индексов помогает действительно потому что индекс был фрагментирован или в нем было много ghost records после массового удаления и тп.
То есть - таки да, если кто-то предлагает лечить проблему медленного исполнения запроса перестроением индекса (без предложения проанализировать план запроса, почистить кэш планов хотя бы, обновить статистику и тд и тп), то это для меня - признак сомнительной квалификации автора.
Мне, правда, применение plan guide тоже кажется механизмом последнего шанса, когда систему постоянно глючит на одном и том же запросе и регулярное обновление статистики не помогает, но мои сомнения по поводу рекомендации перестраивать индексы на любой чих это не отменяет.
Старый 12.05.2020, 10:38   #6  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от fed Посмотреть сообщение
По моим наблюдениям, если перестроение индексов по таблице помогло с кривым планом исполнения, то в 98% случаев это случилось только потому что при перестроении был сброшен план исполнения, а следующий план исполнения был более удачным (то есть - имеем ситуацию неудачного parameters sniffing и plan guide может помочь). И только примерно в 2% случаев, перестроение индексов помогает действительно потому что индекс был фрагментирован или в нем было много ghost records после массового удаления и тп.
Согласен

Цитата:
Мне, правда, применение plan guide тоже кажется механизмом последнего шанса, когда систему постоянно глючит на одном и том же запросе и регулярное обновление статистики не помогает, но мои сомнения по поводу рекомендации перестраивать индексы на любой чих это не отменяет
Ну так где рекомендация-то? Я вижу список вещей которые можно попробовать, но никак не пошаговый план действий

As a first step… try to tune expensive code / queries
• Add/change indexes
• Increase selectivity
• Add hints
• Rebuild indexes
• Update statistics
• Apply other code changes (e.g. change pattern)

Т.е. мы приписываем автору что-то, чего он не заявлял, и на этом основании строим свои дальнейшие умозаключения. Удобно
__________________
-ТСЯ или -ТЬСЯ ?
Старый 12.05.2020, 09:54   #7  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Vadik Посмотреть сообщение
Помню, разбирали.
"Переиндексацию для борьбы с неправильными планами" я видимо тоже пропустил - можете дать ссылку на первоисточник?
Ну ваша презентация, страница 35.

Цитата:
Сообщение от Vadik Посмотреть сообщение
Верно для случая когда версия и схема БД, объем и распределение данных тоже "заморожены", т.е. где-то между "крайне редко" и "никогда" Собственно, поэтому я plan guide-ами стараюсь не злоупотреблять
В большинстве случаев то вариантов нет. Ну т.е. как работает сниффинг параметров - предположим у вас 100% статистика, вы только что переиндексировали индексы, включили все возможные флаги. Далее первым прилетает запрос с каким-то уникальным значением параметров(в моем случае идет join с InventDim), для них строится план(верный конкретно для этих параметров, но не верный для всех остальных) и все, система встает

На самом деле в линкед ин откомментили что для всех продакшн баз включена автокоррекция планов(SQL Automatic plan correction), т.е. теперь эту работу будет делать электронный алгоритм
Я с этим еще правда не встречался, интерестно проверить как это будет работать на практике.

Последний раз редактировалось trud; 12.05.2020 в 10:10.
За это сообщение автора поблагодарили: Vadik (1).
Старый 12.05.2020, 10:52   #8  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от trud Посмотреть сообщение
Ну ваша презентация, страница 35
Она не "моя", я просто разместил объяву Еще раз посмотрел, нет там рекомендации "перестраивать индексы чтобы исправить планы"

Цитата:
На самом деле в линкед ин откомментили что для всех продакшн баз включена автокоррекция планов(SQL Automatic plan correction), т.е. теперь эту работу будет делать электронный алгоритм
Я с этим еще правда не встречался, интерестно проверить как это будет работать на практике
А можно сссылку на LinkedIn ? Интересно было бы почитать
__________________
-ТСЯ или -ТЬСЯ ?
Теги
ax2009, parameter sniffing, sql server

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Обсуждение стоимости владения D365FO и AX2012 fed Microsoft и системы Microsoft Dynamics 121 28.11.2019 16:59
Denis Trunin's Blogs: Working with Financial dimensions in D365FO Blog bot DAX Blogs 0 05.03.2019 20:11
Консультант D365FO на европейский проект (шанс для консультантов AX2012) Bestick Рынок труда Microsoft Dynamics 0 14.01.2019 16:54
Denis Trunin's Blogs: How to setup Financial reporting on D365FO local One box VM Blog bot DAX Blogs 1 13.01.2019 20:11
d365technext: List of Tables X++ D365FO, AX7 and AX2012 Blog bot DAX Blogs 0 10.09.2018 18:11

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

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

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