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


16

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

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

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

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

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

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

Ответы:


10

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

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

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

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

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

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

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

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

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


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

1
@dev_etter: я перечислил только несколько факторов; Есть много других. Главное - это самое первое предложение. Если вы будете помнить об этом, обдумывая свое окружение, оно будет правильно направлять ваше решение. Все проистекает из этого. (Кроме того, все это предполагает, что SSD не задействованы.)
Джон Зигель

Впрочем, я что-то упустил полностью - фактический сценарий на шаге задания (а не источник) был настроен для адресации каждого индекса с минимальным процентом фрагментации, равным 1. Я увеличил его до 15, а также увеличил порог перестройки с 30 35. Теперь работа длится чуть более 3 часов, а не 8. Ваше предложение быть менее агрессивным было правильным. Моя вина заключалась в том, что я думал, что работа уже выполнена менее агрессивной. Этот подход, вероятно, лучше для нас, все еще трогай и уходи, но он уже ослабил некоторую боль.
dev_etter

@JonSeigel Я полностью согласен с этим ответом. В своих путешествиях я вижу, что большинство администраторов баз данных совместно используют один пул или, по крайней мере, массив одного уровня RAID. У меня были администраторы базы данных в 3 часа ночи 24 часа в сутки, просто для того, чтобы дефрагментировать отдельные файловые группы из 100+ ТБ баз данных ... и для чего именно? У нас был абсолютно случайный ввод-вывод на дисках, и задержка составила 15 мс. В этот момент я должен просто указать 15мс и сказать разработчикам оставить меня в покое.
ooutwire

2

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

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


Наша ближайшая стратегия состоит в том, чтобы сделать именно это - мы собираемся настроить параметры переменных minFragmentation и rebuildThreshold в этом сценарии: sqlfool.com/2011/06/index-defrag-script-v4-1
dev_etter

0

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

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

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

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


2
Вы, вероятно, хотите избежать категорического высказывания "Ответ ДА!" к проблемным пространствам, которые подробно обсуждались другими авторами. Хотя это может быть правдой, что иногда ответ «Да», как показал Брент Озар в своем блоге, это не всегда так.
Макс Вернон
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.