Когда некластерные индексы должны храниться в отдельных файловых группах?

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

Когда целесообразно хранить некластеризованные индексы в отдельной файловой группе и на диске? Какие свидетельства Perfmon / Profiler приведут меня к такому выводу? Играет ли роль оборудование в принятии решения (используется ли RAID / SAN для одного диска)?

Самая медленная часть системы БД - это дисководы. Устранение узких мест на уровне дисков повысит производительность. Когда данные ищутся и используется индекс, сначала ищется индекс, а затем выбираются соответствующие данные. Если и индекс, и данные находятся на одних и тех же дисках, возникает конфликт. Принимая во внимание, что если данные были на другом (физическом) диске, то происходит более быстрый ввод-вывод, что повышает производительность. Основная часть, на которую следует обратить внимание, состоит в том, что данные или индекс находятся на отдельных физических дисках или LUN.

Вы должны использовать такой сценарий, если вам нужно повысить производительность вашей системы, если у вас есть диски. Для вашего PERFMON счетчиков можно использовать Physical Disk – Avg. Disk sec/Read, Physical Disk – Avg. Disk sec/Write, Physical Disk – Disk Reads/sec, Physical Disk – Disk Writes/secчтобы иметь до и после сравнения изменений.

Несомненно, распределение одновременного ввода-вывода между различными дисками повысит производительность - это не миф. Это миф, что если сделать это дважды, это снова улучшит производительность.

Если вы ЖЕ , то разделение массива на два раздела и размещение индексов в одном и таблиц в другом - пустая трата времени.

Разделение индексов от данных на отдельные файловые группы = повышение производительности является весьма спорным. Повышение производительности «может» произойти, если у вас есть базовое оборудование для его поддержки, но только благодаря тому факту, что разделение их на разные файловые группы не дает вам повышения производительности. И это также не легко измерить повышение производительности из-за этого.

Ссылка: http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA-Monkey.aspx

Вы должны сначала задать вопрос. Зачем тебе это нужно?

1. Вы хотите повысить производительность резервного копирования, НЕ включая индексы?
2. Вы хотите улучшить производительность операций чтения и записи по этим индексам?
3. Вы делаете это для лучшей управляемости размещения базовых объектов?
4. У вас есть большие объемы данных, которые имеют различные потребности в производительности?
5. Вы хотите использовать SSD для некластеризованных индексов для повышения производительности и т. Д ...

Я посмотрел на эту задачу, чтобы поддержать необходимость № 5 в приведенном выше списке, и это кажется мне хорошим предложением, хотя мы еще не приняли этого.

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

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

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

Что касается производительности, мы не увидели ничего необычного после переезда. Но это большая коробка хранения SAN, где все хранится вместе :-).

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

Однако это также в значительной степени зависит от хранилища . Например; Если у вас есть сервер с хорошим Fushion ioDrive (или что-то подобное), а также имеет отдельные вращающиеся диски. Может быть более выгодно хранить все на ioDrive (если пространство не ограничено). Есть и другие вещи, которые необходимо учитывать - конфигурация RAID, конфигурация сетевого хранилища.

Выполните некоторое тестирование производительности либо на тестовом сервере с аналогичным оборудованием, либо (только если дополнительный сервер не доступен) в часы без пиковой нагрузки с временными данными. Ссылка DBA-Monkey от Sankar выше - хорошая пища для размышлений.