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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.05.2020, 16:11   #1  
Blog bot is offline
Blog bot
Участник
 
25,459 / 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,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Vadik Посмотреть сообщение
"Переиндексацию для борьбы с неправильными планами" я видимо тоже пропустил - можете дать ссылку на первоисточник? А если не зацикливаться на планах исполнения, то из некоторых сценариев (например, массовые forwarded records) - выходов кроме регулярной перестройки индексов (ну или изменения схемы) в общем-то и нет
По моим наблюдениям, если перестроение индексов по таблице помогло с кривым планом исполнения, то в 98% случаев это случилось только потому что при перестроении был сброшен план исполнения, а следующий план исполнения был более удачным (то есть - имеем ситуацию неудачного parameters sniffing и plan guide может помочь). И только примерно в 2% случаев, перестроение индексов помогает действительно потому что индекс был фрагментирован или в нем было много ghost records после массового удаления и тп.
То есть - таки да, если кто-то предлагает лечить проблему медленного исполнения запроса перестроением индекса (без предложения проанализировать план запроса, почистить кэш планов хотя бы, обновить статистику и тд и тп), то это для меня - признак сомнительной квалификации автора.
Мне, правда, применение plan guide тоже кажется механизмом последнего шанса, когда систему постоянно глючит на одном и том же запросе и регулярное обновление статистики не помогает, но мои сомнения по поводу рекомендации перестраивать индексы на любой чих это не отменяет.
Старый 12.05.2020, 09:54   #6  
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:38   #7  
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, 10:52   #8  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от trud Посмотреть сообщение
Ну ваша презентация, страница 35
Она не "моя", я просто разместил объяву Еще раз посмотрел, нет там рекомендации "перестраивать индексы чтобы исправить планы"

Цитата:
На самом деле в линкед ин откомментили что для всех продакшн баз включена автокоррекция планов(SQL Automatic plan correction), т.е. теперь эту работу будет делать электронный алгоритм
Я с этим еще правда не встречался, интерестно проверить как это будет работать на практике
А можно сссылку на LinkedIn ? Интересно было бы почитать
__________________
-ТСЯ или -ТЬСЯ ?
Старый 12.05.2020, 10:55   #9  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Так а как по вашему надо решать сниффинг параметров?

Один из комментов, это собственно все, гугл ничего не ищет по этому поводу
Цитата:
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).
Старый 12.05.2020, 11:27   #10  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от 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* несколько странно, к особым результатам не приводят. (Кстати -даже странно что рекомендация чистить таблицы параметров пропущена из этого замечательного документа). Соответственно - отношение ко всем этим чеклистам у меня исключительно скептическое (даже если отдельные пункты чеклиста сами по себе разумны и для каких-то случаев применимы).
Старый 12.05.2020, 19:09   #11  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от trud Посмотреть сообщение
Так а как по вашему надо решать сниффинг параметров?
"Прямо сейчас" - обновление статистики (сбросив закешированный план), сохранить план и в фоне разбираться с тем, что протухло. Чинить - в AOT (индекс который должен подбираться даже при тестировании с "плохим" значением параметра, либо код). Если будут рецидивы в процессе починки, можно создать plan guide (после починки - снести). По крайней мере, так не будет пасхалок в виде "в UAT работает не так как в продуктиве", "работает в пяти компаниях из десяти" и т.п.

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

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

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

Последний раз редактировалось Vadik; 12.05.2020 в 19:24.
Старый 13.05.2020, 01:34   #12  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Vadik Посмотреть сообщение
"Прямо сейчас" - обновление статистики (сбросив закешированный план), сохранить план и в фоне разбираться с тем, что протухло. Чинить - в AOT (индекс который должен подбираться даже при тестировании с "плохим" значением параметра, либо код).
В целом да, это собственно совпадает с тем что я написал. Кстати для тестирования очень рекомендую утилиту Дениса Сухотина - https://github.com/denissukhotin/MSS...ToSpExecuteSql, незаменимая вещь
Но join с InventDim как правило невозможно починить индексами или кодом без глобальных переделок, тут сама архитектура такая. Возьмите пример из поста - что тут можно проиндексировать? по всем полям в WHERE уже есть индексы, InventDim большая таблица
X++:
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
За это сообщение автора поблагодарили: Logger (3).
Старый 13.05.2020, 11:21   #13  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от 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 и нет как такового, просто индексация кривая и это рано или поздно всплыло бы
Изображения
 
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 13.05.2020 в 12:02.
Старый 13.05.2020, 13:06   #14  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от 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). При этом я не поручусь что это не затронет чего-то другого(т.е. опять надо наблюдать)
Ну т.е. в целом да, это оптимальный способ действий, если у вас есть актуальная копия рабочей бд и возможность смотреть пару дней.
В консалтинге это будет сложно продать
Совсем неправильный путь - это к примеру запустить сбор статистики или переиндексацию и сказать что все нормально
Теги
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, время: 23:23.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.