|
Рискну предположить следующее:
У вас очень неравномерно распределены остатки по номенклатуре. Допустим есть парочка номенклатур, для которых включен номер партии, соответственно на них приходиться процентов 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. Если оно от торможения поможет - значит моя гипотеза верна. Если не поможет - значит у вас и вправду статистика как-то неимоверно быстро устаревает и кроме ее регулярного сбора вас ничто не спасет.
|