Прослушивание параметров SQL Dax

[gkochkin]

Коллеги, добрый день!
Вопрос весьма общий, но все же попрошу по возможности ответить опытных.
Часта ли проблема прослушивания параметров в связке SQL Server 2008 R2 и Dax 2009?
Периодически, довольно часто на серваке бывают зависоны при том, что в работе в этот момент стандартные вещи. ПРоблема уходит (предположительно) после обновления статистик одной или нескольких ключевых таблиц - inventdim, inventtrans и тд. Поэтому, я предположил, что имеет место прослушивание параметров.
Прошу дать свои методы устранения подобных ситуаций или опровергнуть мои предположения.

[Logger]

А вы вот это применяли ?
emeadaxsupport: How to proactively avoid parameter sniffing step-by-step
говорят помогает.

[trud]

Цитата:

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

Прошу дать свои методы устранения подобных ситуаций или опровергнуть мои предположения.

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

вообще это очень хорошо описано в статье

https://www.brentozar.com/archive/20...in-sql-server/

возможные решения
https://www.brentozar.com/blitzcache...eter-sniffing/

[gl00mie]

Цитата:

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

Вопрос весьма общий, но все же попрошу по возможности ответить опытных.

"Неоптыным просьба не беспокоиться"

Цитата:

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

Часта ли проблема прослушивания параметров в связке SQL Server 2008 R2 и Dax 2009?

Если речь не о внедрении с несколькими компаниями, то, мне кажется, частота возникновения такой проблемы обратно пропорциональна частоте обновления статистики.

Цитата:

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

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

Чтобы не гадать, есть масса готовых инструментов:

• штатная трассировка "длинных" SQL-запросов, включаемая в параметрах пользователей AX (можно смело включать с апертурой от 5000 для всех)
• DynamicsPerf
• Extended Events для трассировки в самом SQL Server, правда, в 2008 R2 с ними может быть не так удобно работать, как в последующих версиях.

Но, как уже упоминалось, сначала нужно локализовать проблему, а пока вы воочию не увидите тормозящие запросы, любые решения будут танцами с бубном.

[gkochkin]

Цитата:

Если речь не о внедрении с несколькими компаниями, то, мне кажется, частота возникновения такой проблемы обратно пропорциональна частоте обновления статистики.

Спасибо.
То есть для внедрений с одной компанией решение, описанное @Logger не подойдет?
Мы часто обновляем статистику для некоторых таблиц,да. Это ведь как раз говорит, что проблема прослушивания параметров вероятна!?

[Vadik]

Цитата:

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

Мы часто обновляем статистику для некоторых таблиц,да. Это ведь как раз говорит, что проблема прослушивания параметров вероятна!?

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

[gkochkin]

Спасибо!
Я читал статьи Brent Ozar, в том числе и рекомендованную.
Буду знакомиться с ней ближе.

[Vadik]

Цитата:

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

Если речь не о внедрении с несколькими компаниями, то, мне кажется, частота возникновения такой проблемы обратно пропорциональна частоте обновления статистики.

Да как сказать - бывает что у складов \ товаров по частоте и характеру использования случается большой разброс. Иногда приходится forceliterals в коде навязывать. Не очень красиво (overlayering так его ), но изменения минимальные и работают

[gl00mie]

Предложенное выше решение относится к DataAreaId и в меньшей степени к Partition (которого нет в AX 2009), так что для внедрений с одной компанией в базе AX оно не подойдет.
Виной ли именно прослушивание параметров в ваших проблемах, я судить не берусь, причин тормозов может быть очень много. Может, у вас выгрузка данных в кубы стартует невовремя, или autoshrink базы включен, или кто-то заходит на СУБД и сбрасывает кэш планов исполнения запросов, мало ли. Сначала надо локализовать проблему, а потом уже думать, как ее лечить.

[Logger]

К слову о фиксе в аксапте по проблеме Parameters sniffing.
Почему они (MS) применили такой подход с включением литералов только для DataareaId и PartitionID?
Ведь в базе есть еще куча полей с неравномерно распределенными значениями. Например, любое поле с енумом, обозначающим какой-то статус - уже кандидат на эту проблему. Или еще любят в коде накладную от платежа отличать по заполненности поля CustTrans.Invoice и.т.п.

Почему бы не дать возможность для директивы forceLiterals действовать только на определенный список полей или зашить его в настроечной табличке типа SqlStorage ? Или в свойстве табличного поля в AOT такое свойство сделать. Получился бы гибкий, универсальный инструмент.

[Vadik]

Цитата:

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

Почему бы не дать возможность для директивы forceLiterals действовать только на определенный список полей или зашить его в настроечной табличке типа SqlStorage ? Или в свойстве табличного поля в AOT такое свойство сделать. Получился бы гибкий, универсальный инструмент

А кто такую гибкую конфигурацию на 2000+ таблиц поддерживать будет - консультанты ? А как быть если таблиц и статусов в запросе участвует более одного?
Нунафиг, лучше уж на уровне приложения и запроса. Placeholders с одним планом на компанию (продуктивов с несколькими partition не видел пока) в большинстве случаев работают приемлемо (не зря же за SQL Server с его оптимизатором денег просят), и пилюли в виде forceliterals можно только в самых запущенных случаях прописывать

[Logger]

Цитата:

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

А кто такую гибкую конфигурацию на 2000+ таблиц поддерживать будет - консультанты ? А как быть если таблиц и статусов в запросе участвует более одного?

А в чем проблема ? Поддерживать будут программисты и админы. Смотря кому ближе. Тем более что никто не заставляет все значения заполнять - можно вообще не заполнять. Если ничего не заполнено - то обычное поведение, а дальше по желанию - для тех кто хочет заморочиться.
Сейчас ведь тоже можно настраивать хранение табличек и индексов по тейблспейсам в SqlStorage. Никому это не мешает - наоборот очень удобно и гибко. Кому надо - настроили. кому не надо - он про это и не помнит.

Кстати, в свете предстоящих запретов оверлеить приложение - это тоже было бы удобной настройкой. Зачем править исходный код, искать кучу мест где табличка может возникнуть в запросе (пойди их еще найди - не всегда это просто), затем мучайся и пиши extensions, когда можно в одном месте подправить настроечную табличку - и как по волшебству во всех запросах фильтру по указанному полю пойдут с литералами - красота !

По-моему, это было бы очень удобно и эффективно.

[skuull]

Цитата:

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

По-моему, это было бы очень удобно и эффективно.

Добавте предложение на connect, а мы с радостью проголосуем

[gkochkin]

Цитата:

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

Ведь в базе есть еще куча полей с неравномерно распределенными значениями.

Буду благодарен за подробности про возможные поля с неравномерно распределенными значениями, я хотел бы их исследовать на своей системе..

[Logger]

Цитата:

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

Буду благодарен за подробности про возможные поля с неравномерно распределенными значениями, я хотел бы их исследовать на своей системе..

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

Например:
InventTrans.statusIssue
InventTrans.statusReceipt
CustTrans.invoice
VendTrans.invoice
Как правило еще InventDim.InventLocationId
90 % значений ходит по 1-2 складам.

[trud]

Не надо ничего создавать, все уже давно создано
16 голосов ждут с 19/06/2015

https://connect.microsoft.com/dynami...etails/1449788

[Logger]

Цитата:

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

Не надо ничего создавать, все уже давно создано
16 голосов ждут с 19/06/2015

https://connect.microsoft.com/dynami...etails/1449788

Ух ты ! Прикольно, как мысли у разных людей сходятся.
Проголосовал.

[Logger]

Цитата:

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

Не надо ничего создавать, все уже давно создано
16 голосов ждут с 19/06/2015

https://connect.microsoft.com/dynami...etails/1449788

Цитата:

Posted by trud on 12.01.2017 at 1:47
I also suggest adding ability to specify OPTIMIZE FOR UNKNOWN hint per query basis. in some cases when we have not equal data distribution it also can solve a lot of issues regarding query sniffing parameters

Наш DBA извернулся так, что грохнул статистику по полю dataareaid во всех табличках. Оптимизатор перестал делать различия между компаниями. Получился некий аналог OPTIMIZE FOR UNKNOWN по Dataareaid

[Vadik]

Цитата:

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

Наш DBA извернулся так, что грохнул статистику по полю dataareaid во всех табличках. Оптимизатор перестал делать различия между компаниями. Получился некий аналог OPTIMIZE FOR UNKNOWN по Dataareaid

А чем OPTIMIZE FOR UNKNOWN лучше DATAAREALITERAL и отдельного плана исполнения на компанию?

[Logger]

Цитата:

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

А чем OPTIMIZE FOR UNKNOWN лучше DATAAREALITERAL и отдельного плана исполнения на компанию?

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