Как лучше всего измерить спад фрагментации / производительности базы данных SQLServer и определить, когда дефрагментировать таблицу базы данных SQLServer?
Мне больше всего интересно узнать, какие полезные метрики и какой уровень снижения производительности должен вызвать дефрагментацию.
Я уверен, что на этот вопрос будет несколько интересных ответов, так как существует много разногласий по поводу того, на какие метрики смотреть. Я написал DBCC INDEXDEFRAG, SHOWCONTIG и разработал их замену на 2005 год, а также написал содержание электронной документации, поэтому я выскажу свое мнение и объясню числа в электронной документации и мастера планов обслуживания на 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.
Я думаю, что я переусердствовал, но это одна из моих горячих кнопок. Надеюсь это поможет :-)