Наш SQL-сервер живет в сети SAN. Он содержит десятки баз данных OLTP, некоторые с несколькими таблицами, содержащими более 1 млн записей.
Мы еженедельно запускаем сценарии обслуживания индекса Олы Хелленгрен , и каждый раз они работают по несколько часов. Исходя из порога фрагментации, скрипт будет либо реорганизовывать, либо переиндексировать индекс. Мы наблюдали, что во время переиндексации файлы журнала становятся большими, что приводит к чрезмерному потреблению пропускной способности во время доставки журналов.
Затем следует статья Брента Озара, в которой он говорит перестать беспокоиться об индексах SQL :
Ваши жесткие диски используются совместно с другими серверами, которые также отправляют запросы на диски одновременно, поэтому диски всегда будут перепрыгивать повсюду для получения данных. Дефрагментация ваших индексов - это просто бессмысленная занятая работа.
Погугление этого вопроса приводит к различным мнениям, большинство из которых подтверждается аргументами, которые кажутся слишком краткими или слабыми. Наш предварительный план состоит в том, чтобы настроить порог фрагментации в нашем сценарии обслуживания так, чтобы он реорганизовывался гораздо чаще, чем переиндексирует.
Какой окончательный вердикт? Стоит ли дефрагментировать индексы SQL в сети хранения данных с учетом нагрузки, связанной с выполнением еженедельных заданий обслуживания?