|
По моим наблюдениям, в 85% случаев, кривые планы лечаться командой DBCC FREEPROCCACHE(), которая кэш планов очищает. Только в оставшихся 15% случаев реально нужен пересбор статистики. Обычно, кривой план исполнения является результатом использования parameters sniffing. План запроса строится для первой попавшейся комбинации параметров запроса и потом достаточно долго повторно используется (там есть критерии устаревания плана, но скорее всего, план просто будет выкинут из кэша из за того что на одной из используемых в нем таблиц случилось автоматическое обновление статистики). Так что - возможно что этот флаг на самом деле помогает не потому что статистик чаще обновляется, а потому что более частый автоматический сбор статистики сокращает среднее время жизни закэшированного плана запроса, снижая шансы на то что кривой план будет повторно использоваться недельку-другую.
Так что я подопечных админов учу так: Если какая-то из форм начала внезапно сильно тормозить, то просто очистите план запроса. Ну и каждую ночь с субботы на воскресенье - пересбор статистики по всем таблицам и всем записям таблицы. Да - возможно это несколько избыточно, но обычно времени за ночь хватает на пересбор и очень большой дополнительной нагрузки на сервер это не создает. (По крайней мере - пользователи не жалуются).
Единственное исключение - таблицы сводного планирования (reqTrans/ReTransCov/ReqPo). Просто при регенерации плана (каждую ночь обычно), система сносит содержание одного из планов (а их обычно не так много 2-3-4) и перегенерирует данные заново. В этой ситуации, мы просто поставили батч на пересчет плана на 18:00 и maintanance plan в SQL Server на обновление статистики по этим таблица - на 18:40. Просто эмпирически выяснили что где-то в 19:00 регенерация плана начинает тормозить и ей можно здорово помочь обновлением статистики...
|