Основное правило состоит в том, чтобы разделить файлы на разные тома, чтобы избежать конфликтов, однако величина увеличения производительности, которую вы получаете, сильно варьируется в зависимости от подсистемы ввода-вывода и рабочей нагрузки. Например, несколько файлов на одном физическом шпинделе будут отстойными с точки зрения производительности, но та же схема, что и для тома, находящегося на SAN LUN с несколькими сотнями дисков из массивов RAID 10, может быть просто идеальной. Счетчики длины очереди на диске - ваш друг, самый простой способ узнать, есть ли у вас узкое место ввода / вывода.
Вы смотрите на шаблоны ввода-вывода в базах данных - только для чтения, в основном для чтения, для чтения-записи, в основном для записи, только для записи - и основываетесь на этом. Вам также необходимо выбрать правильный уровень RAID и убедиться, что смещения дисковых разделов, размер полосы RAID и размер единицы размещения NTFS установлены правильно. Некоторым людям нравится разделять некластеризованные индексы в отдельной файловой группе, но прирост производительности здесь варьируется, как я объяснил выше.
Как и производительность, вы должны учитывать управляемость и возможность восстановления. Наличие одного файла монолитных данных для базы данных объемом 100 ГБ означает, что ваша единица восстановления - это файл. Разделение его на 4 файловых группы по 25 ГБ означает, что вы можете использовать частичную доступность базы данных и частичное восстановление, чтобы восстановить только одну файловую группу в случае ее повреждения. Разделив таблицы и индексы по нескольким файловым группам, вы также можете ограничить, какие части базы данных подвержены операциям обслуживания (например, удаление фрагментации индекса).
Tempdb - это особый случай, и я укажу вам на мой пост в блоге, который объясняет все, почему и как разделить tempdb - существует множество заблуждений.
Не давая вам рекомендации «широкого обобщения», я укажу вам на несколько статей и постов в блоге, которые вы можете прочитать:
Надеюсь, это поможет вам!
Решение о разделении базы данных на разные файловые группы должно быть принято после анализа текущего размера и будущего роста ваших таблиц. По моему мнению, если у вас нет большой базы данных или таблиц с миллионами строк, вы должны тщательно обдумать плюсы и минусы, поскольку в итоге вы можете создать больше проблем с производительностью, чем исправить.
Есть несколько сценариев, которые могут быть интересны при определенных условиях:
Вы должны проанализировать свою среду, чтобы решить, помогут ли файловые группы с вашими потребностями роста, использования и производительности SQL Server.
Некоторые ключевые показатели для перемещения в несколько файловых групп (из этой статьи ):
Если вы обнаружите, что файловые группы могут улучшить производительность вашей базы данных, напишите код и протестируйте процесс в промежуточной среде, прежде чем вносить изменения на своих производственных серверах. Подготовьте некоторые измерения, прежде чем вносить изменения, и сравните их до / после. Поскольку эти процессы могут быть очень ресурсоемкими и длительными, выполняйте эти процедуры в течение периода обслуживания.
Не забывайте, что при создании новых объектов (таблиц и индексов) убедитесь, что объекты создаются в правильной файловой группе, чтобы обеспечить ожидаемую производительность и периодически проверять, что объекты базы данных находятся в правильных файловых группах и корректируются по мере необходимости.
источник