Настоящие требования распространяются на тестовые и пользовательские базы данных, с размерами до 300Гб, без повышенных требований к доступности, готовности и надёжности.
Файлы пользовательских баз данных, журналов транзакций, журналов планов обслуживания и других журналов располагаются в стандартной структуре каталогов, используемой вендором. При наличии нескольких дисков (дисковых массивов), системные и серверные каталоги располагаются на диске C (в предлагаемых программой установке каталогах по умолчанию – C:\Program Files\Microsoft SQL Server), файлы данных располагаются на диске D, а файл журнала транзакций (который рекомендуется иметь один для каждой БД) располагаются на диске E. В корне каждого диска создаётся каталог MSSQL, в котором создаются подкаталоги для размещения соответствующих файлов. Для файлов данных создаётся подкаталог DATA, для файлов журналов подкаталог LOG, для файлов резервных копий подкаталог BACKUP. Нежелательно располагать на одном диске файлы с разным типом доступа, например, файлы данных и файл журнала транзакций. Для повышения живучести приложения баз данных, нежелательно располагать файлы резервных копий на одном диске с файлами данных. Например, для трёх дисков возможна такая, типовая конфигурация размещения файлов баз данных:
- C:\Program Files\Microsoft SQL Server\ – фалы сервера баз данных, системные базы данных, журналы планов обслуживания и т.п.
- D:\MSSQL\DATA\ – Файлы данных пользовательских баз данных.
- E:\MSSQL\LOG\ – Файл журнала регистрации транзакций пользовательской базы данных.
- E:\MSSQL\BACKUP\ – Файлы резервных копий пользовательских и системных баз данных.
Параметры создаваемых баз данных желательно выбирать стандартными, предлагаемыми по умолчанию. Каждое изменение стандартных значений параметров должно быть обосновано и документировано (sp_addextendedproperty).
Для размещения пользовательских данных создаётся отдельная файловая группа (группы), которая делается файловой группой по умолчанию. Предлагается называть такую группу: DATAGROUP. Делается это для того, чтобы разнести по разным файлам системные и пользовательские объекты базы данных.
Если дисков для размещения файлов много, желательно в файловой группе DATAGROUP создавать несколько файлов данных (например, по числу установленных в системе сокетов центральных процессоров). В таком случае файлы размещаются на разных дисках, а SQL Server балансирует нагрузку между ними, что повышает производительность операций ввода-вывода.
Для размещения файлов журналов транзакций необходимо использовать защищённые от отказа диска массивы, например RAID1. Для файлов данных пользовательских БД использование защищённых массивов спецификацией требование ACID не является обязательным при условии использования полной модели восстановления и регулярного резервирования не только баз данных, но и журналов регистрации транзакций.
Для размещения файлов баз данных и особенно журналов транзакций нежелательно использовать массивы RAID5x или RAID6x, в силу крайне низкой скорости записи. Эти типы массивов можно использовать для размещения файлов резервных копий или файлов данных с малым процентом операций записи.
Как правило, SQL Server балансирует нагрузку ввода-вывода эффективнее аппаратных решений. Поэтому предпочтительно размещать базу данных на нескольких файлах и помещать файлы на собственные диски, чем размещать базу в одном файле данных и помещать его на массивы типа RAID10 или SAN. Рекомендуется, для принятия решения о целесообразности использования RAID10 или SAN проводить тестирование разных вариантов конфигурации дисковой подсистемы.
Если после создания БД планируется массовая загрузка данных, желательно при создании установить достаточный размер файлам данных и журнала транзакций. Автоматическое приращение файлов является ресурсоёмкой операцией и может существенно увеличить время загрузки данных. Кроме того, если на разделе диска находятся несколько файлов данных, размер которых может изменяться, это становится причиной файловой фрагментации данных и журналов. Для обеспечения высокой производительности работы приложений необходимо дефрагментировать файлы баз данных на регулярной основе. Уменьшение размеров файлов данных крайне не желательно, эта операция может применяться только для сокращения размера файла журнала транзакций, если это стало необходимо (например, после массовой журналируемой загрузки).
