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

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