Периодичность сбора статистики

[fed]

По моим наблюдениям, в 85% случаев, кривые планы лечаться командой DBCC FREEPROCCACHE(), которая кэш планов очищает. Только в оставшихся 15% случаев реально нужен пересбор статистики. Обычно, кривой план исполнения является результатом использования parameters sniffing. План запроса строится для первой попавшейся комбинации параметров запроса и потом достаточно долго повторно используется (там есть критерии устаревания плана, но скорее всего, план просто будет выкинут из кэша из за того что на одной из используемых в нем таблиц случилось автоматическое обновление статистики). Так что - возможно что этот флаг на самом деле помогает не потому что статистик чаще обновляется, а потому что более частый автоматический сбор статистики сокращает среднее время жизни закэшированного плана запроса, снижая шансы на то что кривой план будет повторно использоваться недельку-другую.
Так что я подопечных админов учу так: Если какая-то из форм начала внезапно сильно тормозить, то просто очистите план запроса. Ну и каждую ночь с субботы на воскресенье - пересбор статистики по всем таблицам и всем записям таблицы. Да - возможно это несколько избыточно, но обычно времени за ночь хватает на пересбор и очень большой дополнительной нагрузки на сервер это не создает. (По крайней мере - пользователи не жалуются).

Единственное исключение - таблицы сводного планирования (reqTrans/ReTransCov/ReqPo). Просто при регенерации плана (каждую ночь обычно), система сносит содержание одного из планов (а их обычно не так много 2-3-4) и перегенерирует данные заново. В этой ситуации, мы просто поставили батч на пересчет плана на 18:00 и maintanance plan в SQL Server на обновление статистики по этим таблица - на 18:40. Просто эмпирически выяснили что где-то в 19:00 регенерация плана начинает тормозить и ей можно здорово помочь обновлением статистики...

[gl00mie]

Цитата:

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

Обычно, кривой план исполнения является результатом использования parameters sniffing. План запроса строится для первой попавшейся комбинации параметров запроса и потом достаточно долго повторно используется

Небольшой offtopic на счет parameter sniffing, его отключения и разгромного объяснения, почему оно не поможет: тихой сапой в ядре AX 2012 R2 CU6 добавили фишку, позволяющую побороть генерацию кривых планов запросов, зависящих от того, в какой компании в первый раз выполнился запрос, - см. Overcoming parameter sniffing issue in Microsoft Dynamics AX 2012 R2 CU6:

Цитата:

When you installed AX2012 R2 CU6, it would have created 2 new records in SYSGLOBALCONFIGURATION with names ( 'DATAAREAIDLITERAL', 'PARTITIONLITERAL'). To turn the feature ON you need to update these records and set the value to 1. Following update will enable the feature on all the AOS. Note: This feature is turned OFF by default.

После включения новой фичи в запросах значения полей DATAAREAID и/или PARTITION будут уходить литералами, а не параметрами.

[fed]

Цитата:

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

Небольшой offtopic на счет parameter sniffing, его отключения и разгромного объяснения, почему оно не поможет:

Кстати - после того как где-то в микрософтовских блогах появилась ОСТОРОЖНАЯ рекомендация отключать parameters sniffing (флаг 4136), клиентские админы начали его бездумно включать. В результате - начинаются жуткие тормоза при обработках запросов по inventTrans вида select inventTrans where inventTrans==_inventTransId && StatusIssue==x && StatusReceipt==y. В реальной базе у 95% записей в полях статусов стоит Purchased/Sold/None. Тем не менее оптимизатор с этим флагом считает что распределение примерно равное и подобный запрос, с большой вероятностью, будет отработан по индексу по статусам, а не по индексу по inventTransId.
P.S. Вообще умиляет вера заметной части админов в то, что во всех микрософтовских продуктах есть God Mode. Поставил просто нужный флажек и все проблемы решились сами...