Как узнать, когда пришло время дефрагментировать мою базу данных SQLServer?
Какова наилучшая практика для измерения фрагментации / снижения производительности базы данных SQLServer и определения, когда нужно дефрагментировать таблицу базы данных SQLServer?
Меня больше всего интересует, что такое полезные метрики и какой уровень снижения производительности должен вызывать дефрагментацию.
1 ответ
Я уверен, что будут некоторые интересные ответы на это, поскольку есть много разногласий относительно того, на какие метрики смотреть. Я написал DBCC INDEXDEFRAG, SHOWCONTIG и разработал их замену для 2005 года, а также написал содержание Books Online, поэтому я изложу свое мнение и объясню цифры в Books Online и мастере плана обслуживания на 2005 год, который я выбрал.
Два лучших показателя для фрагментации индекса: 1) (2005 г.) средняя фрагментация в процентах / (2000 г.) фрагментация логического сканирования 2) (2005 г.) средняя плотность страниц / (2000 г.) среднее количество байт на страницу бесплатно.
Они в равной степени относятся к кластерным и некластеризованным индексам.
1 измеряет, сколько существует логической фрагментации. Это когда логический порядок страниц на уровне листа индекса не соответствует физическому порядку. Это препятствует эффективному чтению подсистемой хранилища во время сканирования диапазона. Таким образом, #1 влияет на производительность сканирования диапазона, а не на производительность поиска одиночного.
2 показывает, сколько тратится свободного места на каждой странице на уровне листа индекса. Потерянное пространство означает, что вы используете больше страниц для хранения записей, что означает больше дискового пространства для хранения индекса, больше операций ввода-вывода для чтения индекса и больше памяти для хранения страниц в памяти в пуле буферов.
Пороги? Мое общее правило - фрагментация менее 10%, ничего не делайте. 10-30%, выполнить ALTER INDEX ... REORGANIZE (2005) / DBCC INDEXDEFRAG (2000). Более 30% делают ALTER INDEX ... REBUILD (2005) / DBCC DBREINDEX (2000). Это полные обобщения, и пороговые значения для вас будут разными.
Чтобы найти свои пороговые значения, выполните некоторое отслеживание производительности рабочей нагрузки в зависимости от уровней фрагментации и решите, когда снижение производительности слишком велико. На этом этапе вам понадобится решить проблему фрагментации. Существует баланс между жизнью с фрагментацией и использованием ресурса, удаляющего его.
Я не коснулся здесь компромиссов между двумя методами удаления фрагментации, такими как FILLFACTOR/PADINDEX, чтобы попытаться смягчить фрагментацию и сделать меньше дефрагментации, изменениями схем / схем доступа для облегчения фрагментации или различными видами планов обслуживания.,
О, кстати, я всегда рекомендую не беспокоиться о фрагментации в индексах с менее чем 1000 страниц. This is because the index is probably mostly memory resident (and because people asked for a number and I had to come up with one).
You can read more on this in my TechNet Magazine article on database maintenance at http://technet.microsoft.com/en-us/magazine/cc671165.aspx, in the 2000-based whitepaper on index defrag best practices I helped write at http://technet.microsoft.com/en-us/library/cc966523.aspx, and on my blog under the Fragmentation category at http://www.sqlskills.com/BLOGS/PAUL/category/Fragmentation.aspx.
Я, кажется, переусердствовал, но это одна из моих горячих кнопок. Надеюсь это поможет:-)