Denis Trunin's Blogs: Resolving performance issues caused by parameters sniffing in AX2012 and D365FO

[Blog bot]

Источник: 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/

[Vadik]

Цитата:

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 был включен? Статистики с какой периодичностью обновлялись?

[trud]

Цитата:

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

https://academylive.blob.core.window...-DYN549PAL.pdf

О, это презентация от людей которые рекомендовали везде 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

Т.е. мы сохраняем историю, решаем проблему сейчас, передаем ее техническому специалисту. Если у него есть время(и он вообще есть), то он уже решает в меру своих способностей и что более важно бюджета - ну т.е. лучшее решение это конечно добавить индексы, или менять код

[Vadik]

Цитата:

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

О, это презентация от людей которые рекомендовали везде update_recordset писать(https://denistrunin.com/understanding-sql-blocking/)

Помню, разбирали. Сошлись на том, что не все так однозначно

Цитата:

И они же рекомендуют запускать переиндексацию для борьбы с неправильными планами, это я как-то пропустил

"Переиндексацию для борьбы с неправильными планами" я видимо тоже пропустил - можете дать ссылку на первоисточник? А если не зацикливаться на планах исполнения, то из некоторых сценариев (например, массовые forwarded records) - выходов кроме регулярной перестройки индексов (ну или изменения схемы) в общем-то и нет

Цитата:

В АХ никакие планы не должны меняться от времени

Верно для случая когда версия и схема БД, объем и распределение данных тоже "заморожены", т.е. где-то между "крайне редко" и "никогда" Собственно, поэтому я plan guide-ами стараюсь не злоупотреблять

Цитата:

Вообще их презентация показывает что они сами это никогда не делали

Возможно, Вы просто немного предвзяты

[fed]

Цитата:

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

"Переиндексацию для борьбы с неправильными планами" я видимо тоже пропустил - можете дать ссылку на первоисточник? А если не зацикливаться на планах исполнения, то из некоторых сценариев (например, массовые forwarded records) - выходов кроме регулярной перестройки индексов (ну или изменения схемы) в общем-то и нет

По моим наблюдениям, если перестроение индексов по таблице помогло с кривым планом исполнения, то в 98% случаев это случилось только потому что при перестроении был сброшен план исполнения, а следующий план исполнения был более удачным (то есть - имеем ситуацию неудачного parameters sniffing и plan guide может помочь). И только примерно в 2% случаев, перестроение индексов помогает действительно потому что индекс был фрагментирован или в нем было много ghost records после массового удаления и тп.
То есть - таки да, если кто-то предлагает лечить проблему медленного исполнения запроса перестроением индекса (без предложения проанализировать план запроса, почистить кэш планов хотя бы, обновить статистику и тд и тп), то это для меня - признак сомнительной квалификации автора.
Мне, правда, применение plan guide тоже кажется механизмом последнего шанса, когда систему постоянно глючит на одном и том же запросе и регулярное обновление статистики не помогает, но мои сомнения по поводу рекомендации перестраивать индексы на любой чих это не отменяет.

[Vadik]

Цитата:

Сообщение от 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)

Т.е. мы приписываем автору что-то, чего он не заявлял, и на этом основании строим свои дальнейшие умозаключения. Удобно

[trud]

Цитата:

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

Помню, разбирали.
"Переиндексацию для борьбы с неправильными планами" я видимо тоже пропустил - можете дать ссылку на первоисточник?

Ну ваша презентация, страница 35.

Цитата:

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

Верно для случая когда версия и схема БД, объем и распределение данных тоже "заморожены", т.е. где-то между "крайне редко" и "никогда" Собственно, поэтому я plan guide-ами стараюсь не злоупотреблять

В большинстве случаев то вариантов нет. Ну т.е. как работает сниффинг параметров - предположим у вас 100% статистика, вы только что переиндексировали индексы, включили все возможные флаги. Далее первым прилетает запрос с каким-то уникальным значением параметров(в моем случае идет join с InventDim), для них строится план(верный конкретно для этих параметров, но не верный для всех остальных) и все, система встает

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

[Vadik]

Цитата:

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

Ну ваша презентация, страница 35

Она не "моя", я просто разместил объяву Еще раз посмотрел, нет там рекомендации "перестраивать индексы чтобы исправить планы"

Цитата:

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

А можно сссылку на LinkedIn ? Интересно было бы почитать