Зависит ли необходимое время для перестройки индекса от уровня фрагментации?
Требуется ли перестроение фрагментированного индекса на 80% приблизительно за 2 минуты, если перестроение фрагментированного индекса с тем же индексом 40% занимает 1 минуту?
Я прошу РАБОТУ (например, в секундах), которая может потребоваться для выполнения требуемого действия, а не о том, какое действие требуется в какой конкретной ситуации. Мне известны основные рекомендации, когда необходимо выполнить переоценку индекса или перестроение / обновление статистики.
Этот вопрос НЕ задает вопрос о REORG и разнице между REORG и REBUILD.
Предыстория: в связи с настройкой различных заданий обслуживания индекса (каждую ночь тяжелая работа в выходные дни) я подумала, лучше ли выполнять ежедневное «легкое интенсивное» обслуживание индекса OFFLINE для фрагментированных индексов с низким и средним уровнем, чтобы сохранить малое время простоя - или это не имеет значения, и перестроение на фрагментированном индексе на 80% может занять такое же время простоя, как и та же операция с фрагментированным индексом на 40%.
Я последовал советам и попытался выяснить, что происходит. Моя экспериментальная установка: на тестовом сервере, который больше НИЧЕГО не делает и не используется кем-то или чем-либо еще, я создал таблицу с кластеризованным индексом в столбце первичного ключа уникального идентификатора с некоторыми дополнительными столбцами и различными типами данных [2 числа, 9 дата-время и 2 varchar (1000)] и просто добавленные строки. Для представленного теста я добавил около 305 000 строк.
Затем я использовал команду обновления и случайно обновил диапазон фильтрации строк по целочисленному значению и заменил один из столбцов VarChar изменяющимся строковым значением для создания фрагментации. После этого я проверил текущий avg_fragmentation_in_percentуровень в sys.dm_db_index_physical_stats. Всякий раз, когда я создавал «новую» фрагментацию для своего теста, я добавлял это значение, включая physical_page_countзначение к моим записям, из которых сделана следующая диаграмма.
Затем я побежал: Alter index ... Rebuild with (online=on);
и схватил CPU time, используя STATISTICS TIME ONв моих записях.
Мои ожидания: я ожидал увидеть хотя бы указание на вид линейной кривой, которая показывает зависимость между уровнем фрагментации и временем процессора.
Это не вариант. Я не уверен, что эта процедура действительно подходит для хорошего результата. Может быть, количество строк / страниц слишком мало?
Однако результаты показывают, что ответ на мой оригинальный вопрос определенно был бы НЕТ . Похоже, что время, необходимое SQL Server для перестройки индекса, не зависит ни от уровня фрагментации, ни от количества страниц базового индекса.
На первом графике показано время процессора, необходимое для перестройки индекса по сравнению с предыдущим уровнем фрагментации. Как вы можете видеть, средняя линия относительно постоянна, и нет никакой связи между фрагментацией и требуемым временем процессора.
Чтобы учесть возможное влияние изменения количества страниц в индексе после моих обновлений, которое может потребовать больше или меньше времени для перестроения, я вычислил УРОВЕНЬ ФРАГМЕНТАЦИИ * СЧЕТЧИК СТРАНИЦ и использовал это значение во второй диаграмме, которая показывает отношение требуемого времени процессора против фрагментации и количества страниц.
Как видите, это также не означает, что фрагментация зависит от времени, необходимого для восстановления, даже если количество страниц варьируется.
После этих утверждений я полагаю, что моя процедура должна быть неправильной, потому что время процессора, необходимое для перестройки огромного и сильно фрагментированного индекса, может зависеть только от количества строк - и я не очень верю в эту теорию.
Итак, поскольку я действительно и определенно хочу это выяснить сейчас, любые дальнейшие комментарии и рекомендации приветствуются .
