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

[trud]

Тут сотрудник поддержки запостил интерестную статью

SQL Server Trace Flag 2371 for Dynamics AX ( http://blogs.msdn.com/b/axinthefield...namics-ax.aspx)

по сути он предлагает флагом сократить интервалы автосбора статистики.

не считаете ли вы что эффект будет негативным(в середине дня запустится какое-нибудь обновление InventTrans). кроме того интерестно, видел ли кто нибудь планы которые действительно менялись от устаревшей менее чем на 20% статистики. (граница авто пересчета когда включен автосбор статистики)

[fed]

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

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

[Vadik]

Цитата:

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

не считаете ли вы что эффект будет негативным

нет

Цитата:

(в середине дня запустится какое-нибудь обновление InventTrans)

а кто ж ему даст запуститься-то днем? я всегда отключаю автообновление на больших инстансах, обновляю принудительно

20% - это очень много при наличии длинной истории (например транзакции за пять лет). Например, в системе постится по 10 миллионов INVENTTRANS в год в течение пяти лет, последний раз статистика была "автообновлена" 31.12.2012. Согласно ей, в 2013 у нас в 2013 году пусто (а это далеко не так), а сиквел узнает что это не так когда она в следующий раз она решит обновиться (31.12.2013). Что для запросов с "больше-меньше" условиями по финановой или физической дате согласитесь не очень здорово.

Цитата:

кроме того интерестно, видел ли кто нибудь планы которые действительно менялись от устаревшей менее чем на 20% статистики. (граница авто пересчета когда включен автосбор статистики)

да

[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 будут уходить литералами, а не параметрами.

[trud]

Цитата:

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

нет
20% - это очень много при наличии длинной истории (например транзакции за пять лет). Например, в системе постится по 10 миллионов INVENTTRANS в год в течение пяти лет, последний раз статистика была "автообновлена" 31.12.2012. Согласно ей, в 2013 у нас в 2013 году пусто (а это далеко не так), а сиквел узнает что это не так когда она в следующий раз она решит обновиться (31.12.2013). Что для запросов с "больше-меньше" условиями по финановой или физической дате согласитесь не очень здорово.

Не понял почему не здорово. в вашем примере селективность даты в 2012 и в 2013 не меняется, по идее на планы это никак не должно сказаться

[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. Поставил просто нужный флажек и все проблемы решились сами...

[Vadik]

Цитата:

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

Не понял почему не здорово. в вашем примере селективность даты в 2012 и в 2013 не меняется, по идее на планы это никак не должно сказаться

Потому что статистика хранится в виде гистограммы ({Набор значений} -> Количество записей) и (согласно устаревшей статистике) в 2013 году количество записей равно 0.

20% от терабайтной БД - это до 200 GB данных о распределении которых отпимизатор ничего не знает. Согласитесь, перелопачивать их каждый раз с неудачным планом исполнения как-то не очень здорово