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 тоже кажется механизмом последнего шанса, когда систему постоянно глючит на одном и том же запросе и регулярное обновление статистики не помогает, но мои сомнения по поводу рекомендации перестраивать индексы на любой чих это не отменяет.

[trud]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

[Vadik]

Цитата:

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

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

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

Цитата:

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

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

[trud]

Так а как по вашему надо решать сниффинг параметров?

Один из комментов, это собственно все, гугл ничего не ищет по этому поводу

Цитата:

I had a discussion about APRC feature with MS and they confirmed the feature is activated in production environments since October 2019 and some plans are automatically forced based on certain conditions. To reset forced planned, I was advised to update statistics or make schema modification (new index, field, index rebuild, and so on).

[fed]

Цитата:

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

Ну так где рекомендация-то? Я вижу список вещей которые можно попробовать, но никак не пошаговый план действий

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)

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

Понимаешь, на самом деле надо не пробовать, а для начала посмотреть кэш планов запросов и для самых тяжелых запросов посмотреть на сами планы запросов и попытаться понять что там не так. После этого уже можно принимать осмысленные решения - сам запрос менять, дополнительные индексы строить, попробовать статистику обновлять или еще чего-то делать.
Сам по себе подход "можно попробовать", наводит на мысль что этот документ родился из алгоритма так называемого "checklist tuner". Это такой персонаж, туповатый, но самоуверенный, и как правильно титульной (для микрософта) национальности, который "разбирается" с твоими проблемами производительности, заставляя тебя выполнять все шаги из его чеклиста. И попытки ему как-то объяснить что в случае проблем со сводным планированием чистить таблицы SalesParm*/PurchParm* несколько странно, к особым результатам не приводят. (Кстати -даже странно что рекомендация чистить таблицы параметров пропущена из этого замечательного документа). Соответственно - отношение ко всем этим чеклистам у меня исключительно скептическое (даже если отдельные пункты чеклиста сами по себе разумны и для каких-то случаев применимы).

[Vadik]

Цитата:

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

Так а как по вашему надо решать сниффинг параметров?

"Прямо сейчас" - обновление статистики (сбросив закешированный план), сохранить план и в фоне разбираться с тем, что протухло. Чинить - в AOT (индекс который должен подбираться даже при тестировании с "плохим" значением параметра, либо код). Если будут рецидивы в процессе починки, можно создать plan guide (после починки - снести). По крайней мере, так не будет пасхалок в виде "в UAT работает не так как в продуктиве", "работает в пяти компаниях из десяти" и т.п.

Я возможно повторюсь сейчас. Я не против plan guides как таковых и пользуюсь ими периодически. Но так как они блокируют оптимизатор, отношусь к ним как ко временным надстройкам (костылям). Поставить клиента со сломанной ногой на костыли можно быстро и с ними ему даже будет какое-то время удобнее (чем без них). Заставлять с ними жить вечно и добавлять новые (с этими - на дачу, с этими - в магазин) - на мой взгляд, уже неправильно

Цитата:

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

Понимаешь, на самом деле надо не пробовать, а для начала посмотреть кэш планов запросов и для самых тяжелых запросов посмотреть на сами планы запросов и попытаться понять что там не так. После этого уже можно принимать осмысленные решения - сам запрос менять, дополнительные индексы строить, попробовать статистику обновлять или еще чего-то делать.

Я людям которые не понимают того, что надо сделать чтобы понять в чем проблема, вообще поостерегся бы какие-то рекомендации давать

Цитата:

Сам по себе подход "можно попробовать", наводит на мысль что этот документ родился из алгоритма так называемого "checklist tuner". Это такой персонаж, туповатый, но самоуверенный, и как правильно титульной (для микрософта) национальности, который "разбирается" с твоими проблемами производительности, заставляя тебя выполнять все шаги из его чеклиста. И попытки ему как-то объяснить что в случае проблем со сводным планированием чистить таблицы SalesParm*/PurchParm* несколько странно, к особым результатам не приводят. (Кстати -даже странно что рекомендация чистить таблицы параметров пропущена из этого замечательного документа). Соответственно - отношение ко всем этим чеклистам у меня исключительно скептическое (даже если отдельные пункты чеклиста сами по себе разумны и для каких-то случаев применимы)

Это уже где-то в нетехнической плоскости. У любого персонажа с саппорте в подписи есть контакты его менеджера. Можешь не объяснять а попросить (аргументированно) о замене. Возможно, с новым тебе повезет больше

[trud]

Цитата:

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

"Прямо сейчас" - обновление статистики (сбросив закешированный план), сохранить план и в фоне разбираться с тем, что протухло. Чинить - в AOT (индекс который должен подбираться даже при тестировании с "плохим" значением параметра, либо код).

В целом да, это собственно совпадает с тем что я написал. Кстати для тестирования очень рекомендую утилиту Дениса Сухотина - https://github.com/denissukhotin/MSS...ToSpExecuteSql, незаменимая вещь
Но join с InventDim как правило невозможно починить индексами или кодом без глобальных переделок, тут сама архитектура такая. Возьмите пример из поста - что тут можно проиндексировать? по всем полям в WHERE уже есть индексы, InventDim большая таблица

SELECT A.* FROM INVENTITEMPRICE A WHERE ((A.DATAAREAID=@P1) AND (((A.ITEMID=@P2) AND (A.PRICETYPE=@P3)) AND (A.ACTIVATIONDATE>@P4))) AND EXISTS (SELECT ''x'' FROM INVENTDIM B WHERE ((B.DATAAREAID=@P5) AND ((B.INVENTDIMID=A.INVENTDIMID) AND (B.INVENTSITEID=@P6)))) ORDER BY A.DATAAREAID,A.ACTIVATIONDATE,A.CREATEDDATETIME DESC

[Vadik]

Цитата:

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

Возьмите пример из поста - что тут можно проиндексировать? по всем полям в WHERE уже есть индексы, InventDim большая таблица

Не знаю на какой Вы версии (возможно 2009). В D365 (10.0.10) напрашивается индекс на InventItemPrice(ItemId, PriceType, ActivationDate, InventDimId)

Я бы даже создал два: {ItemId, PriceType, ActivationDate, InventDimId} и {ItemId, ActivationDate, PriceType, InventDimId}, задеплоил в sandbox и посмотрел статистику использования через пару дней

P.S. Сайтов у нас один или больше одного?
P.P.S. Кстати, хороший пример того как распределение данных и соответственно планы исполнения вполне себе могут меняться со временем. InventItemPrice ("активная" + "неактивная" себестоимость) может расти достаточно быстро (быстрее InventDim), а по стандартным индексам SEEK по "активной" ее части невозможен. Так что возможно в данном случае "классического" parameter sniffing и нет как такового, просто индексация кривая и это рано или поздно всплыло бы

[trud]

Цитата:

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

Не знаю на какой Вы версии (возможно 2009). В D365 (10.0.10) напрашивается индекс на InventItemPrice(ItemId, PriceType, ActivationDate, InventDimId)

Я бы даже создал два: {ItemId, PriceType, ActivationDate, InventDimId} и {ItemId, ActivationDate, PriceType, InventDimId}, задеплоил в sandbox и посмотрел статистику использования через пару дней

Там порядка 5 сайтов, у каждого по 5-10 цен
Я описывал 2009, но схема данных на первый взгляд такая же. Индекс ItemIdx кластерный, поэтому врядли другие в этом случае будут браться, т.е. надо менять именно его(передвигать InventDimId). При этом я не поручусь что это не затронет чего-то другого(т.е. опять надо наблюдать)
Ну т.е. в целом да, это оптимальный способ действий, если у вас есть актуальная копия рабочей бд и возможность смотреть пару дней.
В консалтинге это будет сложно продать
Совсем неправильный путь - это к примеру запустить сбор статистики или переиндексацию и сказать что все нормально