Достаточно ли обновить статистику после загрузки данных, только по явно используемым индексам

добавлено: 28 янв 11
понравилось:0
просмотров: 3416
комментов: 4

теги:

Автор: SomewhereSomehow

Периодически возникает задача загрузить какую-то порцию данных в уже имеющуюся таблицу, чтобы потом, например, построить по ним отчет или выполнить еще какие-то действия.

Иногда, после загрузки большой (относительно количества уже имеющихся данных в таблице) порции данных, запрос, который используется для построения отчета, может начать "тормозить" при первом выполнении. И хотя потом все начинает работать так же быстро, как и до загрузки, хотелось бы избавиться от этого первоначального "торможения".

Причина в первоначальном торможении заключается в том, что при изменении большого количества данных статистика и план выполнения становятся неактуальными, поэтому оптимизатор вынужден автоматически обновлять статистику (если конечно у вас включена соответствующая опция) и пытаться найти новый план выполнения.
Этого можно избежать, если после операции загрузки вручную обновить статистику. Как правило, пользователя легче убедить в том, почему он должен ждать когда данные загружаются, чем в том почему он должен ждать когда отчет строится по готовым данным.

При обновлении статистики, может возникнуть соблазн уменьшить время обновления, обновляя только необходимую статистику. Например, если в запросе используется только один индекс, то на первый взгляд было бы логично обновить статистику только по этому индексу, экономя ресурсы сервера. Но на самом деле не все так очевидно. Посмотрим, что делает оптимизатор на примере.
читать дальше...

Комментарии


  • возможно в части "Теперь проведем финальную часть эксперимента." вы отключили опцию AUTO_CREATE_STATISTICS?

    проблема которую вы описали кажется мне актуальной, у нас большая база и каждую ночь бегут два джоба, первый делает rebuild indexes, второй update statistics на все таблицы. Как вы считаете отключение AUTO_CREATE_STATISTICS увеличит быстродействие запросов? Запросы, в основном - это репорты, по датам и многим другим параметрам.

  • 02 марта 2011, 08:50 SomewhereSomehow

    Добрый день. Все как раз наоборот. Дело в том что статистика обновляется/создается не в момент когда данные изменяются, а в момент, когда вы выполняете запрос по данным. И задержка при первом запросе происходит как раз из-за этого.
    Выполняя принудительное обновление статистики вы заставляете сервер не ждать того момента, когда потребуется пересоздание или обновление статистики, а выполнить это действие сразу после загрузки данных.
    Что касается отключение опции AUTO_CREATE_STATISTICS - ее лучше оставить, т.к. если вы ее отключите, то лишите тем самым оптимизатор возможности автоматически создавать необходимую статистику и возьмете эту функцию на себя. Если вы знаете лучше оптимизатора какая статистика нужна вашим запросам - то вперед, отключайте=)
    Что касается опции AUTO_UPDATE_STATISTICS - возможны варианты... И опять же если вы четко знаете все моменты времени когда статистика становится неактуальной, то можете отключить эту опцию и обновлять все руками, если вы не можете гарантировать это - то опцию лучше оставить.

  • Почитал по вашей ссылке BOL, вроде бы разобрался. Действительно AUTO_CREATE_STATISTICS, в большинстве случаев вещь необходимая. В моем случае, возможно, имеет смысл отключить AUTO_UPDATE_STATISTICS. Таблицы, по которым производятся запросы относительно небольшие 10-150 миллионов строк. Их рост прогнозируем, 2-4% в сутки. Плотность значений по столбцам почти не меняется. Каждую ночь проводится полная перестройка индексов (занимает около часа), и полное обновление статистик (тоже около часа). Впрочем, для начала можно не "лихачить" и попробовать использовать AUTO_UPDATE_STATISTICS_ASYNC вместо AUTO_UPDATE_STATISTICS.
    зы. спасибо за статью, кстати в заголовке опечатка "достаточно"

  • 05 марта 2011, 09:02 SomewhereSomehow

    спасибо, поправлю!



Необходимо войти на сайт, чтобы оставлять комментарии