У меня есть ночная процедура sp_updatestats в производственной базе данных, которая, похоже, работает нормально, за исключением одного конкретного хранимого процесса, у которого возникают проблемы с производительностью после обновления.
Команда разработчиков в настоящее время работает над исправлением процесса (некоторые новые индексы и некоторая реорганизация запроса, которую я рекомендовал), но в настоящее время единственный обходной путь - это сделать
UPDATE STATISTICS [SuperGiantTable]
WITH FULLSCAN
Итак, вопрос в том, могу ли я заставить sp_ updatestats использовать параметр «с полным сканированием»? Я хотеть к? Если нет, то я, вероятно, просто добавлю эту команду выше UPDATE STATISTICS для запуска сразу после sp_updatestats.
SQL 2000, кстати.
Это действительно зависит ...
Сколько баз данных?
Насколько велики базы данных?
Сколько активности?
sp_updatestats (по умолчанию) обновляет статистику с частотой выборки по умолчанию. Вы можете попробовать использовать опцию повторной выборки, но она будет работать только в том случае, если автоматическое обновление не произошло с момента последнего обновления статистики (автоматическое обновление также использует частоту дискретизации по умолчанию).
Когда вы перестраиваете индекс, статистика обновляется при полном сканировании, и большинство людей видят хорошую производительность после перестроения индекса.
Лишь в редких случаях люди отключают функции автоматической статистики. Я бы рекомендовал оставить его включенным.
Имейте задание, которое выполняется с подходящим интервалом (который зависит от ваших шаблонов изменения данных для каждой таблицы) и выполняет обновление статистики вручную с использованием полного сканирования или какой-либо другой высокой частоты дискретизации.
Обычно я бы сказал следующее:
Если это большая база данных - ежечасное резервное копирование журнала транзакций.
- Ежедневное дифференциальное резервное копирование. - Ежедневная дефрагментация. - Ежедневное обновление статистики.
- Переиндексировать раз в неделю. - Полное резервное копирование раз в неделю.
Многое зависит от базы данных и транзакций.
Как сказал KPWINC: «Это действительно зависит от обстоятельств».
Есть еще несколько пунктов, которые влияют на ответ на ваш вопрос, и общий ответ может быть неуместным.
В Microsoft MSDN есть записи для sp_updatestats (http://msdn.microsoft.com/en-us/library/aa260337(SQL.80).aspx) и «ОБНОВЛЕНИЕ СТАТИСТИКИ» (http://msdn.microsoft.com/en-us/library/aa260645(SQL.80).aspx)
Чтобы сначала ответить на ваши последние вопросы:
Вам необходимо перечитать запись SQLServerPedia. В частности:
Перестроение индекса автоматически обновит статистику для индекса (с размером выборки 100%, что обычно лучше, чем то, что вы получаете при использовании sp_updatestats). После завершения перестройки индекса вы можете использовать процедуру sp_updatestats для обновления другой статистики, требующей внимания. (2005+).
В документации UPDATE STATISTICS (2000) говорится следующее для выборки:
Примечание. По умолчанию выполняется пробное сканирование целевой таблицы или индексированного представления. SQL Server автоматически вычисляет требуемый размер выборки.
Кимберли Трипп собрала несколько записей в блоге о статистике, индексах и планах обслуживания баз данных (http://www.sqlskills.com/BLOGS/KIMBERLY/category/Statistics.aspx). Хотя информация может быть использована или не может быть использована вами напрямую, руководство каждой записи в блоге должно быть таким, и ссылки на сайты, вероятно, будут полезны.
Еще одна вещь, которую следует иметь в виду, заключается в том, что автоматически вычисляемая частота дискретизации может привести к тому, что сгенерированная гистограмма и вектор плотности не будут должным образом учитывать любой перекос данных, который у вас может быть, с которым работает sproc.
Знаете ли вы разницу в планах запросов между sproc после обновления выборки статистики и обновления статистики полного сканирования?
Еще одна вещь - будьте осторожны с планами обслуживания, которые перестраивают индексы, а затем обновляют ту же статистику, которая была обновлена как побочный эффект перестройки - вы можете в конечном итоге ХУЖЕ статистика тогда, если бы вы просто оставили в покое rebuild-updated-stats.
Спасибо