Зависит ли время перестроения индекса от уровня фрагментации?

Зависит ли необходимое время для перестройки индекса от уровня фрагментации?

Требуется ли перестроение фрагментированного индекса на 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 для перестройки индекса, не зависит ни от уровня фрагментации, ни от количества страниц базового индекса.

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

Чтобы учесть возможное влияние изменения количества страниц в индексе после моих обновлений, которое может потребовать больше или меньше времени для перестроения, я вычислил УРОВЕНЬ ФРАГМЕНТАЦИИ * СЧЕТЧИК СТРАНИЦ и использовал это значение во второй диаграмме, которая показывает отношение требуемого времени процессора против фрагментации и количества страниц.

Как видите, это также не означает, что фрагментация зависит от времени, необходимого для восстановления, даже если количество страниц варьируется.

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

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

Требуется ли время для перестроения индекса в зависимости от уровня фрагментации?

Я полагаю, что это не будет основным параметром, который будет определять сервер SQL, и потребуется время для перестройки \ реорганизации индекса:

Существуют различные другие факторы, основанные на «ДАННЫХ», посредством которых он решает, сколько времени это займет:

Фактор 1: размер таблицы

Фактор 2: проблемы с доступностью

Фактор 3: Разделение

Фактор 4: индекс столбцов и уникальность

Если вы хотите узнать больше об этих факторах, вы можете обратиться сюда .

Делает ли перестроение фрагментированного индекса на 80% примерно за 2 минуты, если перестроение фрагментированного индекса с тем же индексом 40% занимает 1 минуту

Опять же ответ может быть, это зависит! Для чисел вам нужно будет протестировать сценарий и посмотреть результаты, как он идет. Отслеживайте такие детали, как для FRAG 80-го уровня, для восстановления потребовалось X часов \ минут / с, а для Frag 40-го уровня для восстановления потребовалось Y часов \ минут / секунд. Рассчитайте и сохраните историю, скажем, в течение 15 дней (зависит от запланированной деятельности по обслуживанию), и вы можете сделать вывод о том, сколько времени на самом деле уходит на сравнение обоих.

Дополнительно:

Вы можете собрать данные \ вычисления по ходу перестройки индекса:

либо используя DMV sys.dm_exec_requests ИЛИ

Если у вас есть планы обслуживания Ola для реиндексации-реорганизации, есть возможность сохранить историю действий, выполненных во время обслуживания, в таблице CommandLog, как объяснено в SQL Server Index and Statistics Maintenance . После сохранения данных вы можете запросить тип команды `ALTER_INDEX - REBUILD 'и разницу между ними в столбцах START TIME и END TIME.

Для всех, кто заинтересовался, я создал диаграмму, показывающую, что индекс REBUILD длительностью около 2500 перестроений индекса в течение нескольких недель, с учетом фрагментации индекса и его размера в страницах.

Эти данные основаны на 10 серверах SQL, множестве таблиц и процедурах оптимизации Олы Хелленгрен . Общий порог восстановления составляет 5% фрагментации.

Я сократил некоторые из самых больших таблиц (10 Mi + Pages) в этой статистике, чтобы сделать ее более удобочитаемой.

Диаграмма показывает требуемое время (продолжительность) в виде размера пузырьков. Самые большие значения пузыря составляют около 220 секунд. Это показывает, что необходимое время для перестройки индекса на самом деле не связано с фрагментацией. Вместо этого это, кажется, больше в зависимости от количества страниц, которые имеет индекс. Также это указывает на то, что низкоуровневая фрагментация занимает больше времени, чем более высокая фрагментация.

Второй график просто увеличен в области <= 200 тыс. Страниц. Это показывает то же самое, это занимает больше времени для больших индексов, а не для большей фрагментации.

REBUILDиндекса не зависит от фрагментации. Он полностью удаляет индекс и создает его с нуля.

REORGANZE index - предназначен для уменьшения фрагментации без перестройки индекса, поэтому не удаляйте и не создавайте.

MS советует использовать Reorganize для 30% фрагментации или менее. Для более высокой фрагментации перестройка является предпочтительной.

Вот статья MSDN по этому вопросу: реорганизация и перестройка индексов

ОБНОВИТЬ

Время, затраченное на выполнение операции, очевидно, зависит от фрагментации индекса. Восстановление сильно фрагментированного индекса займет меньше времени, чем реорганизация; восстановление слегка фрагментированного индекса займет гораздо больше времени. Я бы посоветовал взять руководящие принципы MS в качестве отправной точки и провести несколько тестов на ваших столах. Точка безубыточности с точки зрения фрагментации% будет зависеть от конкретной таблицы, размера индекса и типа данных.

Разве перестройка фрагментированного индекса на 80% занимает приблизительно 2 минуты, если перестройка фрагментированного индекса на 40% с тем же индексом занимает 1 минуту?

Алгоритм REBUILD против REORG отличается. REORG НЕ будет выделять новые экстенты в отличие от REBUILD. REORG будет работать с выделенными в данный момент страницами (выделяет одну случайную страницу размером 8 Кбайт, чтобы она могла перемещать страницы), перемещает их и затем освобождает страницы при необходимости.

Из моих замечаний по внутренним компонентам SQLSkills (ранее IE0) ....

Для REBUILD:

• Он может использовать несколько процессоров - может использовать параллелизм для быстрой работы.
• Для сильно фрагментированных индексов (например, 80%, как в вашем примере) REBUILD будет намного быстрее, чем REORG. REBUILD просто создаст другую копию индекса, а REORG увязнет в удалении фрагментации и, следовательно, будет медленнее. Это причина, по которой Пол Рэндал дал свою общую рекомендацию, что будет хорошо сделать REBUILD с сильно фрагментированным индексом.
• REBUILD позволит вам изменить режим восстановления на BULK_LOGGED для минимального входа в систему, генерируя меньше записей журнала .

Для индекса REORG:

• Это всегда однопоточный. Нет параллелизма.
• Это медленнее для сильно фрагментированных индексов и быстрее для слегка фрагментированных индексов. Стоимость создания индекса по сравнению с выполнением реорганизации слегка фрагментированного индекса выше, и, следовательно, REORG будет быстрее для слегка фрагментированного индекса.
• REORG - это всегда полностью зарегистрированная операция.

Читайте дальше - Примечания - Фрагментация, типы и решения индекса SQL Server

Я знаю, что это старая ветка, но я думаю, что будет полезно поделиться постом Пола Рэндала здесь.

Скорость алгоритма

Перестроение индекса всегда будет создавать новый индекс, даже если нет фрагментации. Продолжительность перестройки зависит от размера индекса, а не от степени фрагментации в нем.

https://www.sqlskills.com/blogs/paul/sqlskills-sql101-rebuild-vs-reorganize/

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

Сколько дольше зависит от фрагментации и от того, насколько ЦП связан весь процесс. Сериализация строк довольно загружает процессор, поэтому может не иметь никакого значения. Или вы можете получать случайные скорости ввода-вывода, как правило, 1,5 МБ / с, что легко в 5-10 раз медленнее, чем быстрая перестройка (зависит от схемы и данных). В зависимости от допущений, которые вы делаете, вы, вероятно, можете сделать что-нибудь между 1x и 100x замедлением.

Разве перестройка фрагментированного индекса на 80% занимает приблизительно 2 минуты, если перестройка фрагментированного индекса на 40% с тем же индексом занимает 1 минуту?

Это не линейные отношения. Метрика фрагментации является очень приблизительным показателем того, сколько времени требуется для сканирования раздела.