Какова оптимальная практика для измерения фрагментации / снижения производительности базы данных SQLServer и определения, когда нужно дефрагментировать таблицу базы данных SQLServer?
Меня больше всего интересует, что такое полезные метрики и какой уровень снижения производительности должен вызывать дефрагментацию.
Ответы:
Я уверен, что будут некоторые интересные ответы на это, поскольку есть много разногласий относительно того, на какие метрики смотреть. Я написал 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 страниц. Это потому, что индекс, вероятно, в основном резидентный (и потому, что люди спрашивали номер, а мне пришлось его придумать).
Вы можете прочитать больше об этом в моей статье TechNet Magazine об обслуживании баз данных по адресу http://technet.microsoft.com/en-us/magazine/cc671165.aspx , в техническом документе 2000 года о лучших методах дефрагментации индекса, который я помог написать на http://technet.microsoft.com/en-us/library/cc966523.aspx и в моем блоге в разделе «Фрагментация» по адресу http://www.sqlskills.com/BLOGS/PAUL/category/Fragmentation.aspx .
Я, кажется, переусердствовал, но это одна из моих горячих кнопок. Надеюсь это поможет :-)