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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 23.09.2010, 16:15   #13  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,913 / 5736 (197) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Рискну предположить следующее:
У вас очень неравномерно распределены остатки по номенклатуре. Допустим есть парочка номенклатур, для которых включен номер партии, соответственно на них приходиться процентов 80 от таблицы inventSum.
Затем вспоминаем, что начиная с версии SQL 2005, SQL использует так называемый parameter sniffing. Под этим заковыристым словом подразумевается механизм, при котором план исполнения параметризованного запроса генерируется для первого встреченного набора параметров запроса, и затем повторно используется для всех остальных значений параметров.
Теперь представим себе что сегодня у вашего сервера неудачный день, и первый пришедший запрос, запрашивает остатки по той самой парочке номенклатур. Сервер, поднапрягшись, генерирует план с full scan и parallelism (поскольку для той номенклатуры, которая эдак процентов 40-50 от inventSum занимает это и вправду нормально). Затем приходят нормальные легкие запросы. Но план исполнения-то сохранен. Значит сервер даже простенькие запросы из серии "Просумировать 5 записей" исполняет через full scan и parallelism.
Потом, после того как вы статистику пересобираете, сервер сбрасывает сохраненный план исполнения (поскольку он это делает каждый раз когда меняется статистика по некой таблице/индексу и данный сохраненный план эту таблицу использует).

Чего в такой ситуации делать:
1. Можно попробовать залезть в inventSum.findSumJoin() и вручную засунуть туда хинт forceLiterals, чтобы параметризация не использовалась и план запроса каждый раз перегенерировался бы. Правда - в этом случае у вас весьма нехило возрастет нагрузка на процессор сервера БД. Так что если вы этим советом попробуете воспользоваться, помониторьте нагрузку на сервер денька 2-3. Может оказаться что лекарство будет тяжелее болезни.
2. Вместо долгого и мучительного сбора статистики при торможении, можно просто отдать SQL-серверу простую комманду DBCC FREEPROCCACHE. Эта комманда заставит сервер забыть все сохраненные планы исполнения запросов и сгенерировать, при надобности, заново. Нагрузка на процессор сервера возрастет, но не очень сильно и только на следующие минут 10-15.

В общем - попробуйте насчет DBCC Freeproccache. Если оно от торможения поможет - значит моя гипотеза верна. Если не поможет - значит у вас и вправду статистика как-то неимоверно быстро устаревает и кроме ее регулярного сбора вас ничто не спасет.
За это сообщение автора поблагодарили: mazzy (2), ziva (2), aidsua (2), MikeR (4).
Теги
sql server, производительность

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Размер БД и производительность skof DAX: Прочие вопросы 17 25.06.2010 18:02
Производительность InventSum, InventDim AlexeyBP DAX: Администрирование 20 13.05.2007 12:58
Производительность БД при смене Recovery Model polygris DAX: Администрирование 7 19.01.2007 18:43
Аксапта. Производительность. Эпизод n+1-й Falcon DAX: Функционал 48 15.05.2006 00:03
Хранимые процедуры и производительность vey DAX: Администрирование 13 17.06.2005 10:56

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 20:51.