В нашей базе данных в настоящее время есть только одна FileGroup, PRIMARY, которая содержит примерно 8 ГБ данных (строки таблицы, индексы, полнотекстовый каталог).
Когда лучше разбить это на вторичные файлы данных? Какие критерии мне следует знать?
Этот вопрос состоит из двух частей: когда добавлять новую FILEGROUP и когда добавлять новый FILE в файловую группу. Сначала поговорим о теории:
Марк прав в том, что главная причина - производительность.
Вторая причина - аварийное восстановление. В SQL Server 2005 и новее вы можете выполнять восстановление файловых групп. В случае аварии вы можете сначала восстановить только свою основную файловую группу и частично перевести базу данных в оперативный режим для запросов. Пользователи могут выполнять запросы, пока вы восстанавливаете другие файловые группы. Это полезно для баз данных с большим объемом исторических данных, которые могут не потребоваться сразу, или хранилищ данных, которым необходимо загружать данные в текущие таблицы без необходимости доступа к историческим данным.
Другая причина - это профиль чтения / записи групп данных. Если у вас есть данные, в которые выполняется постоянная запись, и другие данные, которые интенсивно читают, вы можете создать различные типы хранилищ для удовлетворения этих потребностей. Вы можете поместить тяжелые записи в рейд 10, а те, которые смещены на чтение, оставить в более дешевом рейде 5.
Теперь давайте поговорим о файлах и файловых группах. Когда вы размещаете объекты в SQL Server, вы должны размещать их на уровне файловой группы. Вы можете поместить таблицу или индекс в файловую группу, но не можете выбрать конкретный файл. Итак, все, что мы обсуждали до сих пор, касалось того, когда добавлять файловую группу - но когда вы добавляете файл?
Если вы разрабатываете хранилище и у вас 80 жестких дисков, есть несколько способов его разбить:
Различные подсистемы хранения имеют разные профили производительности. Я работал с некоторыми сетями SAN, которые лучше всего работали с массивами из 12–16 дисков, и все, что было больше, не улучшало производительность. Другой пример - сети SAN с несколькими путями: если у вас есть несколько HBA, соединяющих ваш сервер с вашим хранилищем, и если ваше программное обеспечение для работы с несколькими путями на самом деле не активно / активно, вам может понадобиться один массив на каждый путь для распределения нагрузки. Четыре пути, четыре пула дисков улучшат производительность на этих типах дисков.
В этих случаях вы получаете четыре разных массива, четыре разных диска под Windows (если вы не используете точки монтирования и даже тогда это разные папки), и вам понадобятся четыре отдельных файла в SQL Server. Эти отдельные файлы могут находиться в одной файловой группе.
Основная причина - производительность. Когда у вас заканчивается емкость IOPS на диске вашей основной файловой группы, вам необходимо развернуть ее на вторую файловую группу, чтобы разделить IOPS на несколько дисков / LUN в зависимости от конфигурации хранилища.
EDIT: Брэд Уилсон сделал хороший комментарий относительно SSD. Если вы используете составную систему хранения SSD / SATA / FC, вы можете иметь разные файловые группы на разных типах хранилищ. Затем вы можете поместить свои таблицы экстремальных требований к IOPS в файловую группу SSD, в то время как таблицы истории / статистики могут храниться в дешевых файловых группах SATA.
Я также хотел бы указать, что в этом вопросе также есть аспект восстанавливаемости / доступности данных. Используя несколько групп файлов и не помещая какие-либо определенные пользователем объекты в основную группу файлов, вы получаете большую гибкость при включении восстановления в оперативном режиме. это позволяет частичное восстановление на уровне файловой группы.
Оперативное восстановление доступно в версиях SQL Server Enterprise и Developer после 2005 года.
Еще одна мысль, которая приходит в голову, - отделить статические справочные данные только для чтения от транзакционных данных. Для более крупных баз данных это могло бы сократить время и / или пространство, необходимое для выполнения резервного копирования.