Есть ли какая-либо польза от дефрагментации индексов SQL в среде SAN?

Наш SQL-сервер живет в сети SAN. Он содержит десятки баз данных OLTP, некоторые с несколькими таблицами, содержащими более 1 млн записей.

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

Затем следует статья Брента Озара, в которой он говорит перестать беспокоиться об индексах SQL :

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

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

Какой окончательный вердикт? Стоит ли дефрагментировать индексы SQL в сети хранения данных с учетом нагрузки, связанной с выполнением еженедельных заданий обслуживания?

Стратегии дефрагментации помогают повысить скорость сканирования с диска .

Большое разнообразие мнений объясняется тем, что идеальная стратегия дефрагментации среды должна зависеть от множества различных факторов. Есть также несколько потенциальных слоев фрагментации в игре.

Сказать, что ваши базы данных хранятся в сети SAN, недостаточно. Например:

• Файлы базы данных хранятся в отдельных физических группах RAID или в одной группе RAID? Какие другие процессы активны на том же устройстве? Ваши резервные файлы тоже там заканчиваются? Возможно, вам придется запросить эту информацию у администратора SAN, потому что она не всегда прозрачна.

• Каковы шаблоны доступа к базам данных? OLTP обычно использует произвольный доступ, но иногда приложение удовлетворяет требованиям сканирования таблицы, и вы не можете изменить его поведение (приложение ISV). Приложения в основном для чтения, для записи или где-то посередине?

• Существуют ли соглашения об уровне производительности во время периода восстановления / отработки отказа ?

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

Если обслуживание индекса является обременительным, подумайте о том, чтобы делать это менее агрессивно, и / или амортизировать стоимость в течение недели (т. Е. Проводить легкое обслуживание один раз в день вместо интенсивного обслуживания один раз в неделю).

Вы также можете включить SortInTempdbопцию, чтобы потенциально уменьшить объем ведения журнала в пользовательских базах данных.

В идеале вы должны реорганизовать / переиндексировать ТОЛЬКО те индексы, которые требуют внимания, в противном случае вы тратите ресурсы и потенциально вызываете другие проблемы.

Вам необходимо установить базовый уровень производительности, и всякий раз, когда вы вносите изменения, сравнивайте изменение производительности с базовым уровнем, чтобы определить, стоит ли вносить эти изменения.

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

Приближенный подход заключается в том, что производительность при извлечении данных из базы данных и базы данных OLTP улучшится, если индексы будут фрагментированы или перестроены. Ответ ДА! Тем не менее, важно отметить, что фрагментация диска также является фактором.

Самая низкая "стоимость" в целом? Сделайте обслуживание вашей базы данных. Во-вторых, самая низкая стоимость: отсоедините базу данных, переместите ее в другое место, переформатируйте диски и следуйте рекомендациям по выравниванию разделов диска http://msdn.microsoft.com/en-us/library/dd758814.aspx . И последнее, но не менее важное: используйте сторонний усовершенствованный дефрагментатор, например Diskkeeper.

Имейте в виду, что это ТОЛЬКО рекомендуется для хранилищ типа NTFS (например, ОС Windows), и это не является одобрением для какого-либо продукта, а также я не связан с Condusiv Technologies или ее дочерними компаниями.