Я только что узнал, что компания-клиент, в которой я работаю, решила не включать параметры статистики автоматического обновления для некоторых из своих SQL-серверов, а администраторы баз данных вручную устраняли проблемы с производительностью при их возникновении.
Тем не менее, этот вид не имеет смысла для меня. Почему вы хотите предотвратить обновление статистики?
Ответы:
Мой совет:
sp_updatestatsобновит всю статистику для всех таблиц в базе данных для вас, но это также приведет к перекомпиляции хранимых процедур, поэтому тщательно выбирайте время (т. е. sp_updatestatsпрямо перед тем, как ваши отчеты на конец месяца будут, вероятно, неоптимальными).Частота запуска статистики обслуживания / перестройки индекса зависит от нагрузки на вашу базу данных, особенно от того, как часто ваши данные изменяются (т.е. INSERT/ UPDATE/ DELETE). Если вы изменяете данные по всему шоу (т.е. промежуточную таблицу для еженедельного пакетного процесса), вы, вероятно, захотите обновлять статистику / реорганизовывать индексы по ночам. Если ваши данные более статичны, вы можете сделать это еженедельным или двухнедельным графиком.
Я только однажды видел это с плохим приложением, которое плохо индексировало кучу и имело тяжелый ETL.
Это был мусор и, к счастью, не мой.
В противном случае нет причин.
Если вы получаете обновления статистики в неподходящее время, это означает, что вы выполняете неправильное обслуживание индекса / статистики или выполняете массовые удаления / загрузки, которые достигают порогового значения.
С SQL Server 2005+ вы можете в любом случае отложить обновление статистики.
См. «Когда использовать синхронные или асинхронные обновления статистики»
Было бы интересно посмотреть, какую статью они читали или читали, чтобы сделать этот выбор ...
В старые времена (SQL Server 2000) установка статистики автоматического обновления могла приводить к большим «паузам» в приложениях OLTP, когда SQL решил обновить статистику.
Начиная с SQL Server 2005 и далее существует асинхронная опция, которая не приведет к «паузе», когда статистика устарела и впоследствии перекомпилирована. Статистика будет перекомпилирована асинхронно в следующий раз, когда она потребуется.
Однако имейте в виду, что необходимо соблюдать баланс - для больших наборов данных может потребоваться, чтобы текущий запрос учитывал самые последние статистические данные, поскольку запрос может занять экспоненциально больше времени при неэффективном плане запроса.
Вы также можете отслеживать количество перекомпиляций в секунду и другие важные показатели производительности, используя счетчики перфмонов , которые публикуются SQL Server, как говорится, доказательство в пудинге.
Насколько активны системы?
Если они в основном считывающие системы, вы можете обойтись без обновления, если это произойдет вручную, когда они изменяют данные (вставка, обновление, удаление).
Однако для лучшей практики рекомендуется придерживаться, потому что я думаю, что это будет редкостью для производительности. Я бы, наверное, отправил им статьи и пост в блоге с предложением оставить его включенным. Кимберли Трипп имеет несколько хороших.
Хотя я никогда не буду ни противоречить, ни преднамеренно отвергать MrDenny (слишком большое уважение к его знаниям и вкладу в сообщество), я заметил документацию MS, рекомендующую отключить статистику автоматического обновления.
При планировании и настройке емкости хранилища и SQL Server (SharePoint Server 2010) MS рекомендует отключить его.
Я также прочитал ту же рекомендацию MS для более ранних версий SP, но сейчас не могу найти ссылки.
Но я НЕ специалист по БД SP Expert, поэтому вы можете также узнать, что Чун Лю, полевой инженер MS Permier, говорит об этом в Chun Liu на SharePoint, или просто проигнорировать этот пост и оставить его включенным .
Вы обычно отключаете их, только если у вас есть метод их обновления самостоятельно. Я делаю это все время, так как нам нужна лучшая или просто другая выборка, чем будет делать автостатистика. Это довольно распространенное явление, но вы не просто выключите его и не сделаете ничего другого.