SQL Server 2005/2008 - несколько файлов / файловых групп - сколько? Почему?

11

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

Каковы ваши стратегии / лучшие практики, когда дело доходит до работы с базой данных SQL Server разумного размера (чем-то большим, чем Northwind или AdventureWorks; примерно 2-4 ГБ данных плюс индексы и т. Д.) - используете ли вы несколько файлов / файловых групп?

Если так: сколько? И почему?

По каким критериям вы решаете отойти от подхода «одна файловая группа для всего»:

* database size?
* database complexity?
* availability / reliability requirements?
* what else?

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

Спасибо за любые подсказки, указатели, мысли!

Ура, Марк

marc_s
источник

Ответы:

16

Основное правило состоит в том, чтобы разделить файлы на разные тома, чтобы избежать конфликтов, однако величина увеличения производительности, которую вы получаете, сильно варьируется в зависимости от подсистемы ввода-вывода и рабочей нагрузки. Например, несколько файлов на одном физическом шпинделе будут отстойными с точки зрения производительности, но та же схема, что и для тома, находящегося на SAN LUN с несколькими сотнями дисков из массивов RAID 10, может быть просто идеальной. Счетчики длины очереди на диске - ваш друг, самый простой способ узнать, есть ли у вас узкое место ввода / вывода.

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

Как и производительность, вы должны учитывать управляемость и возможность восстановления. Наличие одного файла монолитных данных для базы данных объемом 100 ГБ означает, что ваша единица восстановления - это файл. Разделение его на 4 файловых группы по 25 ГБ означает, что вы можете использовать частичную доступность базы данных и частичное восстановление, чтобы восстановить только одну файловую группу в случае ее повреждения. Разделив таблицы и индексы по нескольким файловым группам, вы также можете ограничить, какие части базы данных подвержены операциям обслуживания (например, удаление фрагментации индекса).

Tempdb - это особый случай, и я укажу вам на мой пост в блоге, который объясняет все, почему и как разделить tempdb - существует множество заблуждений.

Не давая вам рекомендации «широкого обобщения», я укажу вам на несколько статей и постов в блоге, которые вы можете прочитать:

Надеюсь, это поможет вам!

Пол Рэндал
источник
+1 большое спасибо, Пол - отличный пост, отличные ссылки - отлично
marc_s
Великий ответ Paul -> Я пытался найти некоторые ранее заданные вопросы SqlServer и дизайн жесткого диска (например , TempDB на Bus1_Disk1, my_db на Bus2_Disk1, и т.д ...) .. Время читать ....
Pure.Krome
4

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

Есть несколько сценариев, которые могут быть интересны при определенных условиях:

  • 2 файловые группы: данные и индекс
  • 3 файловые группы: таблицы только для чтения, таблицы для чтения и записи, индексы
  • несколько файловых групп: только чтение, чтение-запись, индекс, таблица ключей 1, таблица ключей 2, ...

Вы должны проанализировать свою среду, чтобы решить, помогут ли файловые группы с вашими потребностями роста, использования и производительности SQL Server.

Некоторые ключевые показатели для перемещения в несколько файловых групп (из этой статьи ):

  • Когда организация очереди на диске вызывает проблемы приложения и взаимодействия с пользователем
    • Если это так, рассмотрите возможность использования дополнительных дисков с новыми файловыми группами, в которых размещены таблицы с интенсивным вводом-выводом.
  • Когда конкретные таблицы составляют 10% или более от базы данных
    • Если это так, рассмотрите возможность перемещения этих особенно больших таблиц в отдельные файловые группы на отдельных дисках.
    • В зависимости от размера таблицы пропорционально остальным таблицам, рассмотрите возможность создания файловой группы для отдельных таблиц.
  • Когда некластерный индекс и пространство данных равны в больших таблицах
    • Если это так, рассмотрите возможность отделения данных и кластеризованного индекса от некластеризованных индексов.
  • Когда в базе данных существует почти равный процент данных только для чтения и чтения-записи
    • Если это так, рассмотрите возможность разделения данных только для чтения в отдельной файловой группе как данные для чтения и записи.
  • Когда недостаточно времени для обслуживания базы данных
    • Если это так, рассмотрите возможность разделения больших таблиц на отдельные файловые группы на разных дисках и выполняйте обслуживание параллельно.
  • Когда бизнес или приложение будут значительно меняться, а данные будут расти гораздо быстрее
    • Если это так, рассмотрите возможность работы с пользователями, чтобы понять потенциальный рост
  • Когда архивированные данные находятся в той же базе данных, что и производственные данные
    • Если это так, рассмотрите отдельные файловые группы или один или несколько методов из этого совета - Архивация данных в SQL Server

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

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

splattne
источник
+1 отличный пост - спасибо за подсказки и ссылки!
marc_s