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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 21.03.2017, 11:04   #1  
gkochkin is offline
gkochkin
Участник
 
29 / 7 (1) +
Регистрация: 10.03.2017
Прослушивание параметров SQL Dax
Коллеги, добрый день!
Вопрос весьма общий, но все же попрошу по возможности ответить опытных.
Часта ли проблема прослушивания параметров в связке SQL Server 2008 R2 и Dax 2009?
Периодически, довольно часто на серваке бывают зависоны при том, что в работе в этот момент стандартные вещи. ПРоблема уходит (предположительно) после обновления статистик одной или нескольких ключевых таблиц - inventdim, inventtrans и тд. Поэтому, я предположил, что имеет место прослушивание параметров.
Прошу дать свои методы устранения подобных ситуаций или опровергнуть мои предположения.
Старый 21.03.2017, 12:38   #2  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
А вы вот это применяли ?
emeadaxsupport: How to proactively avoid parameter sniffing step-by-step
говорят помогает.
Старый 22.03.2017, 02:40   #3  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от gkochkin Посмотреть сообщение
Прошу дать свои методы устранения подобных ситуаций или опровергнуть мои предположения.
единого универсального метода нет, вам надо понять что происходит, и в зав-ти от этого выбрать решение.

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

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

возможные решения
https://www.brentozar.com/blitzcache...eter-sniffing/
За это сообщение автора поблагодарили: dn (1), Logger (1), alex55 (1), Vadik (1).
Старый 22.03.2017, 10:28   #4  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от gkochkin Посмотреть сообщение
Вопрос весьма общий, но все же попрошу по возможности ответить опытных.
"Неоптыным просьба не беспокоиться"
Цитата:
Сообщение от gkochkin Посмотреть сообщение
Часта ли проблема прослушивания параметров в связке SQL Server 2008 R2 и Dax 2009?
Если речь не о внедрении с несколькими компаниями, то, мне кажется, частота возникновения такой проблемы обратно пропорциональна частоте обновления статистики.
Цитата:
Сообщение от gkochkin Посмотреть сообщение
Периодически, довольно часто на серваке бывают зависоны при том, что в работе в этот момент стандартные вещи. ПРоблема уходит (предположительно) после обновления статистик одной или нескольких ключевых таблиц - inventdim, inventtrans и тд. Поэтому, я предположил, что имеет место прослушивание параметров.
Чтобы не гадать, есть масса готовых инструментов:
  • штатная трассировка "длинных" SQL-запросов, включаемая в параметрах пользователей AX (можно смело включать с апертурой от 5000 для всех)
  • DynamicsPerf
  • Extended Events для трассировки в самом SQL Server, правда, в 2008 R2 с ними может быть не так удобно работать, как в последующих версиях.
Но, как уже упоминалось, сначала нужно локализовать проблему, а пока вы воочию не увидите тормозящие запросы, любые решения будут танцами с бубном.
За это сообщение автора поблагодарили: Logger (1).
Старый 22.03.2017, 10:49   #5  
gkochkin is offline
gkochkin
Участник
 
29 / 7 (1) +
Регистрация: 10.03.2017
Цитата:
Если речь не о внедрении с несколькими компаниями, то, мне кажется, частота возникновения такой проблемы обратно пропорциональна частоте обновления статистики.
Спасибо.
То есть для внедрений с одной компанией решение, описанное @Logger не подойдет?
Мы часто обновляем статистику для некоторых таблиц,да. Это ведь как раз говорит, что проблема прослушивания параметров вероятна!?
Старый 22.03.2017, 11:23   #6  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Предложенное выше решение относится к DataAreaId и в меньшей степени к Partition (которого нет в AX 2009), так что для внедрений с одной компанией в базе AX оно не подойдет.
Виной ли именно прослушивание параметров в ваших проблемах, я судить не берусь, причин тормозов может быть очень много. Может, у вас выгрузка данных в кубы стартует невовремя, или autoshrink базы включен, или кто-то заходит на СУБД и сбрасывает кэш планов исполнения запросов, мало ли. Сначала надо локализовать проблему, а потом уже думать, как ее лечить.
Старый 22.03.2017, 11:24   #7  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Если речь не о внедрении с несколькими компаниями, то, мне кажется, частота возникновения такой проблемы обратно пропорциональна частоте обновления статистики.
Да как сказать - бывает что у складов \ товаров по частоте и характеру использования случается большой разброс. Иногда приходится forceliterals в коде навязывать. Не очень красиво (overlayering так его ), но изменения минимальные и работают
__________________
-ТСЯ или -ТЬСЯ ?
Старый 22.03.2017, 11:31   #8  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от gkochkin Посмотреть сообщение
Мы часто обновляем статистику для некоторых таблиц,да. Это ведь как раз говорит, что проблема прослушивания параметров вероятна!?
То что Вы статистику пересчитываете само по себе не говорит ни о чем, ее надо пересчитывать. Если Вы пересчет статистики или перестройку индексов регулярно используете как средство борьбы с тормозами, и это помогает - то инструмент решения проблем выбран неверно. Об этом, если мне память не изменяет, пост на который trud дал ссылку, почитайте его вдумчиво
__________________
-ТСЯ или -ТЬСЯ ?
Старый 22.03.2017, 15:16   #9  
gkochkin is offline
gkochkin
Участник
 
29 / 7 (1) +
Регистрация: 10.03.2017
Спасибо!
Я читал статьи Brent Ozar, в том числе и рекомендованную.
Буду знакомиться с ней ближе.
Старый 22.03.2017, 17:46   #10  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
К слову о фиксе в аксапте по проблеме Parameters sniffing.
Почему они (MS) применили такой подход с включением литералов только для DataareaId и PartitionID?
Ведь в базе есть еще куча полей с неравномерно распределенными значениями. Например, любое поле с енумом, обозначающим какой-то статус - уже кандидат на эту проблему. Или еще любят в коде накладную от платежа отличать по заполненности поля CustTrans.Invoice и.т.п.

Почему бы не дать возможность для директивы forceLiterals действовать только на определенный список полей или зашить его в настроечной табличке типа SqlStorage ? Или в свойстве табличного поля в AOT такое свойство сделать. Получился бы гибкий, универсальный инструмент.
Старый 22.03.2017, 17:57   #11  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Logger Посмотреть сообщение
Почему бы не дать возможность для директивы forceLiterals действовать только на определенный список полей или зашить его в настроечной табличке типа SqlStorage ? Или в свойстве табличного поля в AOT такое свойство сделать. Получился бы гибкий, универсальный инструмент
А кто такую гибкую конфигурацию на 2000+ таблиц поддерживать будет - консультанты ? А как быть если таблиц и статусов в запросе участвует более одного?
Нунафиг, лучше уж на уровне приложения и запроса. Placeholders с одним планом на компанию (продуктивов с несколькими partition не видел пока) в большинстве случаев работают приемлемо (не зря же за SQL Server с его оптимизатором денег просят), и пилюли в виде forceliterals можно только в самых запущенных случаях прописывать
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 22.03.2017 в 18:11.
Старый 22.03.2017, 21:52   #12  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Vadik Посмотреть сообщение
А кто такую гибкую конфигурацию на 2000+ таблиц поддерживать будет - консультанты ? А как быть если таблиц и статусов в запросе участвует более одного?
А в чем проблема ? Поддерживать будут программисты и админы. Смотря кому ближе. Тем более что никто не заставляет все значения заполнять - можно вообще не заполнять. Если ничего не заполнено - то обычное поведение, а дальше по желанию - для тех кто хочет заморочиться.
Сейчас ведь тоже можно настраивать хранение табличек и индексов по тейблспейсам в SqlStorage. Никому это не мешает - наоборот очень удобно и гибко. Кому надо - настроили. кому не надо - он про это и не помнит.

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

По-моему, это было бы очень удобно и эффективно.
Старый 23.03.2017, 07:00   #13  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от Logger Посмотреть сообщение
По-моему, это было бы очень удобно и эффективно.
Добавте предложение на connect, а мы с радостью проголосуем
Старый 23.03.2017, 08:11   #14  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Не надо ничего создавать, все уже давно создано
16 голосов ждут с 19/06/2015

https://connect.microsoft.com/dynami...etails/1449788
За это сообщение автора поблагодарили: Logger (3).
Старый 23.03.2017, 09:16   #15  
gkochkin is offline
gkochkin
Участник
 
29 / 7 (1) +
Регистрация: 10.03.2017
Цитата:
Сообщение от Logger Посмотреть сообщение
Ведь в базе есть еще куча полей с неравномерно распределенными значениями.
Буду благодарен за подробности про возможные поля с неравномерно распределенными значениями, я хотел бы их исследовать на своей системе..
Старый 23.03.2017, 09:25   #16  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от trud Посмотреть сообщение
Не надо ничего создавать, все уже давно создано
16 голосов ждут с 19/06/2015

https://connect.microsoft.com/dynami...etails/1449788
Ух ты ! Прикольно, как мысли у разных людей сходятся.
Проголосовал.
Старый 23.03.2017, 11:36   #17  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от gkochkin Посмотреть сообщение
Буду благодарен за подробности про возможные поля с неравномерно распределенными значениями, я хотел бы их исследовать на своей системе..
Таких полей много.
Я думаю имеет смысл что-то для них менять только если явно есть подозрение на проблемы.

Например:
InventTrans.statusIssue
InventTrans.statusReceipt
CustTrans.invoice
VendTrans.invoice
Как правило еще InventDim.InventLocationId
90 % значений ходит по 1-2 складам.
Старый 23.03.2017, 11:40   #18  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от 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
Старый 23.03.2017, 11:46   #19  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Logger Посмотреть сообщение
Наш DBA извернулся так, что грохнул статистику по полю dataareaid во всех табличках. Оптимизатор перестал делать различия между компаниями. Получился некий аналог OPTIMIZE FOR UNKNOWN по Dataareaid
А чем OPTIMIZE FOR UNKNOWN лучше DATAAREALITERAL и отдельного плана исполнения на компанию?
__________________
-ТСЯ или -ТЬСЯ ?
Старый 23.03.2017, 11:51   #20  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Vadik Посмотреть сообщение
А чем OPTIMIZE FOR UNKNOWN лучше DATAAREALITERAL и отдельного плана исполнения на компанию?
Я этого не говорил, что лучше.
Просто пока старое ядро стоит, для которого невозможно включить DATAAREALITERAL - применяется такой способ.
Ну и плюс я подумал, что если есть другие проблемные поля, для которых проблема актуальна, то можно попробовать этот финт для них. За неимением ничего лучшего.
Теги
dax, parameter sniffing, sql 2008, troubleshooting, tuning

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Dax 2009. SQL не в домене. Wamr DAX: Администрирование 7 18.04.2011 23:27
DAX 2009 SP1 + MS SQL Server 2008 xshaman DAX: Администрирование 7 10.12.2008 12:26
gatesasbait: Dynamics Ax SQL statements (SQL Strings in DAx) Blog bot DAX Blogs 1 16.04.2008 06:55
Dynamics AX: SQL Server, Heart of Dynamics AX Blog bot DAX Blogs 0 13.07.2007 18:00
aEremenko: Диагностика проблем при установке Microsoft Dynamics Ax 4.0 на Microsoft SQL Server 2005 Blog bot DAX Blogs 0 28.10.2006 16:01
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 16:18.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.