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