В душе я разработчик, но время от времени у клиента нет достойного администратора баз данных для решения этих проблем, поэтому меня вызывают, чтобы решить ...
Каковы ваши стратегии / лучшие практики, когда дело доходит до работы с базой данных SQL Server разумного размера (что-либо больше, чем Northwind или AdventureWorks; примерно 2-4 ГБ данных плюс индексы и т. Д.) - вы используете несколько файлов / файловых групп?
Если да: сколько? И почему?
Каковы ваши критерии, чтобы решить, когда отойти от подхода «одна файловая группа для всего»:
* database size?
* database complexity?
* availability / reliability requirements?
* what else?
Если вы используете несколько групп файлов, сколько из них вы используете? Один для данных, один для индекса, один для журнала? Несколько (сколько) для данных? Каковы причины вашего выбора - почему вы используете именно такое количество файловых групп :-)
Спасибо за любые подсказки, указатели, мысли!
Привет, Марк
Основное практическое правило - разделять файлы на разные тома, чтобы избежать конфликтов, однако общий выигрыш в производительности сильно варьируется в зависимости от подсистемы ввода-вывода и рабочей нагрузки. Например, несколько файлов на одном физическом шпинделе будут отстойными с точки зрения производительности, но такая же договоренность с томом, находящимся на SAN LUN с несколькими сотнями дисков из массивов RAID 10, может быть вполне приемлемой. Счетчики длины дисковой очереди - ваш друг, поскольку это самый простой способ определить, есть ли у вас узкое место ввода-вывода.
Вы смотрите на шаблоны ввода-вывода в базах данных - только для чтения, в основном для чтения, для чтения-записи, в основном для записи, только для записи - и основываете все на этом. Вам также необходимо выбрать правильный уровень RAID и убедиться, что смещения разделов вашего диска, размер полосы RAID и размер единицы распределения NTFS установлены правильно. Некоторым людям нравится разделять некластеризованные индексы в отдельную файловую группу, но прирост производительности здесь зависит от того, как я объяснил выше.
Помимо производительности, вы должны учитывать управляемость и восстанавливаемость. Наличие одного монолитного файла данных для базы данных объемом 100 ГБ означает, что единицей восстановления является этот файл. Разделение его на 4 файловые группы по 25 ГБ означает, что вы можете использовать частичную доступность базы данных и частичное восстановление, чтобы восстановить только одну файловую группу в случае ее повреждения. Разделив таблицы и индексы на несколько файловых групп, вы также можете ограничить, на какие части базы данных влияют операции обслуживания (например, удаление фрагментации индекса).
Tempdb - это совершенно особый случай, и я покажу вам сообщение в моем блоге, в котором все объясняется, почему и как разделить tempdb - существует множество неправильных представлений.
Не давая вам здесь рекомендаций по «широкому обобщению», я укажу вам на кучу официальных документов и сообщений в блогах, которые вы должны прочитать:
Белая бумага: Частичная доступность базы данных
Сообщение блога: Заблуждения относительно TF 1118 (макет tempdb)
Надеюсь, это вам поможет!
Решение о разделении базы данных на разные файловые группы следует принимать после анализа текущего размера и будущего роста ваших таблиц. На мой взгляд, если у вас нет большой базы данных или таблиц с миллионами строк, вам следует внимательно рассмотреть плюсы и минусы, поскольку в конечном итоге вы можете создать больше проблем с производительностью, чем исправить.
Есть несколько сценариев, которые могут быть интересны при определенных условиях:
Вы должны проанализировать свою среду, чтобы решить, помогут ли файловые группы удовлетворить ваши потребности в росте, использовании и производительности SQL Server.
Некоторые ключевые индикаторы для перехода в несколько файловых групп (из Эта статья):
Если вы обнаружите, что файловые группы могут улучшить производительность вашей базы данных, напишите код и протестируйте процесс в промежуточной среде, прежде чем вносить изменения на свои производственные серверы. Перед внесением изменений подготовьте несколько измерений и сравните их до и после. Поскольку эти процессы могут быть очень ресурсоемкими и требующими много времени, выполняйте эти процедуры в период обслуживания.
Не забывайте, что при создании новых объектов (таблиц и индексов) убедитесь, что объекты созданы в правильной файловой группе, чтобы гарантировать ожидаемую производительность, и периодически проверяйте, что объекты базы данных находятся в правильных файловых группах, и исправляйте их по мере необходимости.