Урок 1: Физическая структура базы данных

Урок 1: Физическая структура базы данных

 

В рамках этого урока будут рассмотрены следующие вопросы

} Что такое база данных?

} Принципы организации хранения данных в БД

} Что такое файловые группы?

} Физическая структура файлов базы данных

} Что такое журнал транзакций?

} Принципы ведения журнала транзакций

} Как используется журнал транзакций для восстановления?

Файлы и файловые группы

 

База данных - это некоторый набор перманентных (постоянно хранимых) данных, используемых прикладными программными системами какого-либо предприятия.

 

Базы данных MS SQL Server хранятся на жестком диске в виде файлов. Существуют три типа файлов баз данных MS SQL Server - это первичные файлы, вторичные файлы и журналы транзакций. База данных должна содержать первичный файл данных и, по крайней мере, один файл журнала транзакций. При необходимости можно создать один или несколько вторичных файлов данных и дополнительные файлы журналов транзакций.

 

· Первичные файлы

Первичный файл данных содержит сведения, необходимые для запуска базы данных, и ссылки на другие файлы в базе данных. Первичные файлы также могут содержать данные пользовательских таблиц и индексов. Данные и объекты пользователя могут храниться в данном файле или во вторичном файле данных. В каждой базе данных имеется один первичный файл данных. Для имени первичного файла данных рекомендуется расширение MDF.

· Вторичные файлы

Вторичные файлы данных не являются обязательными; это пользовательские файлы, в которых хранятся данные пользователя. Вторичные файлы могут быть использованы для распределения данных на несколько дисков, в этом случае каждый файл записывается на отдельный диск. Кроме того, если размер базы данных превышает максимальный размер для одного файла Windows, можно использовать вторичные файлы данных, таким образом база данных сможет расти дальше. Для имени вторичного файла данных рекомендуется расширение NDF.

· Журналы транзакций

В этих файлах содержатся данные журнала - информация об операциях, произведенных над базой данных. Протоколирование производимых операций необходимо для обеспечения возможности восстановления базы данных после сбоев или неверных изменений данных. В каждой базе данных должен быть, как минимум, один файл журнала транзакций, а может быть и несколько таких файлов. Для файлов журнала транзакций рекомендуется расширение LDF.

 

По умолчанию и данные, и журналы транзакций помещаются на один и тот же диск и имеют один и тот же путь. Это сделано для поддержки однодисковых систем, но для производственных сред это может быть неоптимальным решением.

 

Рекомендуется помещать данные и файлы журнала на разные физические диски. Таким образом, число перемещений и время на позиционирование пишущей головки жесткого диска будет минимизировано. Например, файл журнала транзакций на отдельном физическом диске может писаться параллельно с файлами данных не требуя дополнительного позиционирования пишущей головки, так как файл журнала транзакций пишется последовательно.

Файлы данных MS SQL Server объединены в файловые группы. Данные внутри файловой группы распределяются по файлам пропорционально свободному месту в файлах. Например, если в файле f1 свободно 100 МБ, а в файле f2 - 200 МБ, то в файл f1 будет записана одна часть данных, а в файл f2- две части, при этом оба файла будут заполнены примерно в одно и то же время.

Как только заполняются все файлы в группе, компонент Database Engine перебирает файлы файловой группы в поисках файла для которого разрешено автоматическое увеличение. Увеличение размера происходит циклически по одному файлу за раз. Например, файловая группа состоит из трех файлов, для всех разрешено автоматическое увеличение. Когда свободное пространство во всех файлах группы закончится, будет расширен только первый файл. Когда заполнится первый файл и в файловую группу снова нельзя будет записывать новые данные, будет расширен второй файл. Когда заполнится второй файл и в файловую группу опять нельзя будет записывать новые данные, будет расширен третий файл. Когда заполнится третий файл и в файловую группу нельзя будет записывать новые данные, будет снова расширен первый файл и т. д.

Используя этот механизм распределения данных по файлам, можно увеличить производительность доступа к данным, разместив файлы файловой группы на разных физических носителях (при таком размещении данные могут писаться параллельно, образуя подобие чередующегося дискового массива RAID). Например, три файла f1, f2 и f3, могут быть созданы на трех дисках соответственно и отнесены к файловой группе fgroup1. Можно создать таблицу размещенную на файловой группе fgroup1. В этом случае, запросы данных из таблицы будут распределены по трем дискам, что несколько улучшит производительность. Подобного улучшения производительности можно достичь и с помощью одного файла, созданного на чередующемся наборе дискового массива RAID. Тем не менее, файлы и файловые группы позволяют без труда добавлять новые файлы на новые диски.

 

Все файлы данных хранятся в файловых группах, перечисленных в следующей таблице.

Файловая группа	Описание
Первичная	Файловая группа, содержащая первичный файл. Все системные таблицы размещены в первичной файловой группе.
Определяемая пользователем	Любая файловая группа, созданная пользователем при создании или изменении базы данных.

 

У каждой базы данных есть первичная файловая группа. Эта файловая группа содержит первичный файл данных и все вторичные файлы, не входящие в другие файловые группы. Пользовательские файловые группы могут создаваться для удобства администрирования, распределения и размещения данных.

 

Например, для больших баз данных возможно резервное копирование отдельных файловых групп, что занимает значительно меньше времени, чем полное резервное копирование базы данных. Также файловая группа может быть целиком помечена как доступная только для чтения.

Файловая группа по умолчанию

Если в базе данных создаются объекты без указания файловой группы, к которой они относятся, они назначаются файловой группе по умолчанию. В любом случае только одна файловая группа создается как файловая группа по умолчанию. Файлы в файловой группе по умолчанию должны быть достаточно большими, чтобы вмещать новые объекты, не назначенные другим файловым группам.

Файловая группа PRIMARY является группой по умолчанию, если только она не была изменена инструкцией ALTER DATABASE.

Системные объекты и таблицы распределяются внутри первичной файловой группы, а не внутри файловой группы по умолчанию. В случае если произошло заполнение всех файлов внутри первичной файловой группы до максимального размера, создание новых объектов и таблиц будет невозможно. Поэтому, при проектировании базы, очень важно учитывать возможный размер первичной файловой группы.

Изическая структура файлов данных

 

Основной единицей хранилища данных в SQL Server является страница. Место на диске, предоставляемое для размещения файла данных (MDF- или NDF-файл) в базе данных, логически разделяется на страницы с непрерывным перечислением от 0 до n. Дисковые операции ввода-вывода выполняются на уровне страницы - SQL Server считывает или записывает целые страницы данных, что при правильной организации структур хранения позволяет минимизировать количество операций ввода-вывода (данные объектов, которые часто запрашиваются вместе при правильной организации будут располагаться на одной странице).

 

Файлы журнала не содержат страниц, в них содержится последовательность записей журнала.

Страницы

В SQL Server размер страницы составляет 8 КБ. Это значит, что в одном мегабайте базы данных SQL Server содержится 128 страниц. Каждая страница начинается с 96-байтового заголовка, который используется для хранения системных данных о странице. Эти данные включают номер страницы, тип страницы, объем свободного места на странице и идентификатор единицы распределения объекта, которому принадлежит страница.

 

В следующей таблице представлены типы страниц, используемые в файлах данных базы данных SQL Server.

 

Тип страницы	Содержимое
Данные	Строки данных со всеми данными, кроме данных типа text,ntext, image, nvarchar(max), varchar(max) и varbinary(max), а также данными типа xml, когда параметр текст в строке установлен в значение ON.
Индекс	Записи индекса.
Текст/изображение	Типы данных больших объектов: text,ntext, image, nvarchar(max), varchar(max), varbinary(max) и xml.   Столбцы переменной длины, когда строки данных превышают размер 8 КБ: varchar, nvarchar, varbinary и sql_variant.
Глобальная карта распределения, общая глобальная карта распределения	Сведения о том, размещены ли экстенты.
Свободное место на страницах	Сведения о размещении страниц и доступном на них свободном месте.
Карта распределения индекса	Сведения об экстентах, используемых таблицей или индексом для единицы распределения.
Схема массовых изменений	Сведения об экстентах, измененных массовыми операциями со времени последнего выполнения инструкции BACKUP LOG для единицы распределения.
Схема разностных изменений	Сведения об экстентах, измененных с момента последнего выполнения инструкции BACKUP DATABASE для единицы распределения.

 

 

Поддержка больших строк

Максимальный объем данных и служебного кода, содержащихся в одной строке на странице, составляет 8 КБ. Это ограничение может быть нарушено только в двух случаях:

· если строка содержит данные типа varchar(max), nvarchar(max) или varbinary (max) - размер этих данных не учитывается. Такие данные будут храниться в виде последовательности страниц типа «Текст/изображение», а в странице содержащей строку будет храниться только указатель на начало этой последовательности.

· если строка содержит данные переменной длины типа varchar(не max), nvarchar(не max) varbinary (не max) или sql_variant, то как только общий размер строки превысит предел в 8 060 байт, SQL Server динамически перемещает один или несколько столбцов переменной длины на отдельные страницы, начиная со столбца с наибольшим размером. Когда происходит перемещение столбца на отдельную страницу, на исходной странице сохраняется только указатель. Если при последующей операции размер строки уменьшается, SQL Server динамически перемещает столбцы обратно на исходную страницу данных. Важно отметить, что в данном случае предел в 8 060 байт может превышать только общий размер строки данных, при этом размер каждого поля строки не может быть больше размера страницы.

 

Экстенты

Экстенты являются основными единицами организации пространства и используются для эффективного управления страницами. Экстент - это коллекция, состоящая из восьми физически непрерывных страниц.

 

SQL Server поддерживает два типа экстентов.

· Однородные экстенты принадлежат одному объекту; все восемь страниц в кластере могут быть использованы только этим владеющим объектом.

· Смешанные экстенты могут находиться в общем пользовании у не более восьми объектов. Каждая из восьми страниц в экстенте может находиться во владении разных объектов.

 

 

Использование смешанных экстентов позволяет сделать распределение места более эффективным, поскольку SQL Server не размещает целые экстенты для таблиц с небольшим объемом данных.

 

Новая таблица или индекс - это обычно страницы, выделенные из смешанных экстентов. При увеличении размера таблицы или индекса до восьми страниц эти таблица или индекс переходят на использование однородных экстентов для последовательных единиц распределения. При создании индекса для существующей таблицы, в которой содержится достаточно строк, чтобы сформировать восемь страниц в индексе, все единицы распределения для индекса находятся в однородных экстентах.

FILESTREAM

На практике при создании приложений часто приходится хранить большие объемы неструктурированных данных, например, текстовые документы, изображения и видеоролики. Хранение множества таких объектов в реляционной базе данных может привести к падению производительности SQL Server Database Engine, поскольку для их кэширования будет использоваться буферный пул SQL Server. Поэтому обычно такие неструктурированные данные хранятся за пределами базы данных отдельно от структурированных данных. Подобное разделение как правило приводит к усложнению логики приложения. Либо, если данные связаны со структурированным хранилищем, могут быть ограничены возможности файловых потоков и производительность.

В SQL Server 2008 был добавлен новый тип хранения больших двоичных объектов (BLOB) FILESTREAM, который объединяет компонент Database Engine с файловой системой NTFS, размещая данные больших двоичных объектов (BLOB) типа varbinary(max) в файловой системе в виде файлов. Манипулирование данными, хранящимися в FILESTREAM осуществляется при помощи инструкций Transact-SQL, что позволяет использовать оптимизированное хранилище без изменения логики приложений его использующих. Интерфейсы файловой системы Windows также обеспечивают потоковый доступ к этим данным.

Для кэширования данных файлов в хранилище FILESTREAM используется системный кэш NT, что позволяет снизить возможное влияние данных FILESTREAM на производительность компонента Database Engine, поскольку буферный пул SQL Server не используется и память доступна для обработки запросов.

В SQL Server 2008 большие двоичные объекты (BLOB) могут храниться двумя способами:

· данные стандартного типа varbinary(max), данные которых хранятся в таблице

· объекты FILESTREAM типа varbinary(max), данные которых хранятся в файловой системе

 

Выбор в качестве хранилища базы данных или файловой системы определяется размером и назначением данных. Объекты FILESTREAM следует использовать в следующих случаях:

· средний размер сохраняемых объектов превышает 1 МБ, поскольку при работе с объектами меньшего размера сохранение больших двоичных объектов (BLOB) типа varbinary(max) в базе данных часто позволяет добиться лучшей производительности потоков;

· важен быстрый доступ для чтения;

Хранилище FILESTREAM реализовано в виде столбца типа varbinary(max), данные которого хранятся в файловой системе как большие двоичные объекты (BLOB). Стандартное ограничение типа varbinary(max), согласно которому размер файла не должен превышать 2 ГБ, не применяется к объектам BLOB, сохраняемым в файловой системе - размеры объектов ограничены только размером тома файловой системы.

Данные FILESTREAM могут сохраняться только в файловых группах FILESTREAM. Файловая группа FILESTREAM представляет собой особый тип файловой группы, в которой вместо файлов базы данных содержатся системные каталоги файлов. Эти системные каталоги файлов называются контейнерами данных, и являются интерфейсом между хранилищем компонента Database Engine и хранилищем файловой системы.

Урок 2: Опции базы данных

 

В рамках этого урока будут рассмотрены следующие вопросы

} Основные категории параметров базы данных

} Ключевые опции базы данных

} Как модель восстановления базы данных влияет на поведение журнала транзакций?

} Из каких источников можно получить информацию о состоянии и настройках БД?

 

Опции базы данных

 

Все опции базы данных можно разделить на следующие категории:

Автоматические

Автоматическое закрытие (AUTO_CLOSE)

Будет ли база данных полностью закрываться и освобождать ресурсы после выхода последнего пользователя. Допустимые значения - ON и OFF. Если значение равно ON, база данных закрывается полностью и освобождает ресурсы после того, как из системы выходит последний пользователь. Параметр AUTO_CLOSE полезен для настольных баз данных, поскольку он позволяет управлять файлами базы данных так же, как обычными файлами. Они могут быть перемещены, скопированы для создания резервной копии или даже отосланы по электронной почте другим пользователям.

Автоматическое сжатие (AUTO_SHRINK)

И файлы данных, и файлы журналов могут быть автоматически сжаты, то есть может быть уменьшено количество неиспользуемого пространства внутри файлов. При включенном параметре AUTO_SHRINK файлы будут сжаты, если более 25 процентов файла содержит неиспользуемое пространство. Файл будет сжат до размера, в котором 25 процентов файла — неиспользуемое пространство, или до того размера, который был у файла при создании, каким бы большим он ни был. AUTO_SHRINK уменьшает размер журнала транзакций только в том случае, если выбрана простая модель восстановления базы данных или была создана резервная копия журнала. Если этот параметр установлен в состояние OFF, файлы базы данных не будут автоматически сжиматься при периодической проверке на неиспользуемое пространство.

Автоматическое создание статистики (AUTO_CREATE_STATISTICS)

Исполнению запроса компонентом Database Engine предшествует его анализ оптимизатором запросов, с целью определения наиболее эффективного для конкретного условия фильтра способа извлечения запрошенных данных. Помимо самого запроса оптимизатором запросов используется схема базы данных (определения таблиц и индексов) и статистики базы данных.

Для оценки количества строк в результатах запроса и как следствие нагрузки на вычислительные ресурсы оптимизатор запросов полагается на статистику распределения. Статистика - это объект, содержащие статистические сведения о распределении значений в одном или нескольких столбцах таблицы. Например, оптимизатор запросов может использовать оценочное количество элементов, чтобы выбрать метод для обращения к данным в таблице.

Каждый объект статистики создается для списка из одного или нескольких столбцов таблицы и содержит гистограмму, в которой отображается распределение значений в первом столбце. Объекты статистики для нескольких столбцов также хранят статистические сведения о корреляции значений между столбцами. Эти статистические данные корреляции называются значениями плотности и получаются из числа уникальных строк значений столбцов.

Данный параметр определяет, будет ли база данных автоматически создавать отсутствующие статистические данные оптимизации. Допустимые значения - ON и OFF. Оптимизатор запросов в случае необходимости создает статистику по отдельным столбцам в предикатах запросов, чтобы улучшить планы запросов и повысить производительность запросов. Значение по умолчанию - ON. Для большинства баз данных рекомендуется использовать значение по умолчанию. Если значение равно ON, во время оптимизации автоматически формируются все отсутствующие статистические данные, необходимые запросу для оптимизации.

Автоматическое обновление статистики (AUTO_UPDATE_STATISTICS)

Указывает, что оптимизатор запросов обновляет статистику, если она используется в запросе и может оказаться устаревшей. Статистика становится устаревшей, после того как операции вставки, обновления, удаления или слияния изменяют распределение данных в таблице. Оптимизатор запросов определяет, когда статистика может оказаться устаревшей, подсчитывая операции изменения данных с момента последнего обновления статистики и сравнивая количество изменений с пороговым значением. Пороговое значение основано на количестве строк в таблице или индексированном представлении. Допустимые значения ON и OFF. Если значение равно ON, во время оптимизации автоматически формируются все устаревшие статистические данные, необходимые запросу для оптимизации.

Асинхронное автоматическое обновление статистики (AUTO_UPDATE_STATISTICS_ASYNC)

При значении ON запросы, которые запускают автоматическое обновление устаревшей статистики, не будут ожидать обновления статистики перед компиляцией. Последующие запросы будут использовать обновленную статистику, когда она будет доступна.

При значении OFF запросы, которые запускают автоматическое обновление устаревшей статистики, будут ожидать, пока обновленная статистика не будет использоваться в плане оптимизации запроса.

Установка данного параметра в значение ON имеет смысл только в том случае, если параметр Автоматическое обновление статистики также имеет значение ON.

Курсор

Закрывать курсор при разрешении фиксации (CURSOR_CLOSE_ON_COMMIT)

Будет ли курсор закрываться после фиксации транзакции, открывшей этот курсор. Допустимые значения — True и False. Если значение равно True, закрываются все курсоры, открытые при фиксации или откате транзакции. Если значение равно False, при фиксации транзакции такие курсоры остаются открытыми. Если значение равно False, откат транзакции закрывает все курсоры, за исключением определенных как INSENSITIVE или STATIC.

Курсор по умолчанию (CURSOR_DEFAULT)

Поведение курсора по умолчанию. Если значение равно LOCAL, курсор объявляется по умолчанию как LOCAL и область видимости курсора будет локальна по отношению к пакету, хранимой процедуре или триггеру, в которых он был создан. Имя курсора действительно только внутри этой области. Если значение равно GLOBAL, курсоры языка Transact-SQL по умолчанию объявляются как глобальные.

Разное

ANSI NULL по умолчанию (ANSI_NULL_DEFAULT)

Поведение по умолчанию операторов сравнения «равно» (=) и «не равно» (<>) при использовании со значениями NULL. Допустимые значения — True (вкл.) и False (выкл.).

Включены ANSI NULL (ANSI_NULLS)

Поведение операторов сравнения «равно» (=) и «не равно» (<>) при использовании со значениями NULL. Допустимые значения - True (вкл.) и False (выкл.). Если значение равно True, всем сравнениям со значениями NULL присваивается значение UNKNOWN. Если значение равно False, сравнения значений, отличных от Юникода, со значениями NULL получают значение True, если оба они равны NULL.

Включено заполнение ANSI (ANSI_PADDING)

Включено ли заполнение ANSI. Допустимые значения — True (вкл.) и False (выкл.).

Включены предупреждения ANSI (ANSI_WARNINGS)

Поведение по стандарту ISO для некоторых условий возникновения ошибок. Если значение равно True, формируется предупреждающее сообщение, если в статистических функциях (таких как SUM, AVG, MAX, MIN, STDEV, STDEVP, VAR, VARP или COUNT) появляются значения NULL. Если значение равно False, предупреждающее сообщение не выдается.

Доверенная БД (TRUSTWORTHY)

При значении True этот параметр указывает, что SQL Server разрешает доступ к ресурсам вне базы данных в рамках контекста олицетворения, установленного для базы данных. Контекст олицетворения для базы данных можно установить при помощи пользовательской инструкции EXECUTE AS или предложения EXECUTE AS в модулях базы данных.

Это свойство также разрешает создание и выполнение небезопасных и внешних сборок в базе данных. Владелец базы данных должен задать для этого свойства значение True. В дополнение к этому, он должен обладать разрешением EXTERNAL ACCESS ASSEMBLY или UNSAFE ASSEMBLY на уровне сервера.

По умолчанию для всех пользовательских и системных баз данных (за исключением MSDB) это свойство установлено в значение False. Оно не изменяется для баз данных model и tempdb.

Восстановление

Проверка страниц (PAGE_VERIFY)

Обнаруживает поврежденные страницы базы данных, вызванные ошибками дискового ввода-вывода. Ошибки дискового ввода-вывода могут быть причиной повреждения базы данных и обычно происходят при сбоях питания или сбоях оборудования диска, происходящих во время записи страницы на диск.

· CHECKSUM

Вычисляет контрольную сумму по содержимому целой страницы и сохраняет полученное значение в ее заголовке при записи страницы на диск. При чтении страницы с диска контрольная сумма вычисляется повторно и сравнивается с сохраненным в заголовке страницы значением. Если значения не соответствуют, будет выведено сообщение об ошибке 824 (ошибка контрольной суммы) как в журнал ошибок SQL Server, так и в журнал событий Windows. Ошибка контрольной суммы указывает на проблему ввода-вывода. Чтобы определить первопричину, необходимо тщательно проверить оборудование, драйверы, BIOS, фильтрующее программное обеспечение (например, антивирусное) и другие компоненты ввода-вывода.

 

· TORN_PAGE_DETECTION

Сохраняет определенный двухбитовый шаблон для каждого 512-байтового сектора в 8-килобайтной (КБ) странице базы данных и сохраняет в базе данных заголовок страницы при записи страницы на диск. При чтении страницы с диска биты разрыва, хранимые в заголовке страницы, сравниваются с действительными сведениями о секторах страницы. Несовпадающие значения указывают, что только часть страницы была записана на диск. В этой ситуации сообщение об ошибке 824 (ошибка разрыва страницы) будет выведено как в журнал ошибок SQL Server, так и в журнал событий Windows. Разорванные страницы обычно обнаруживаются при восстановлении базы данных, если они действительно не полностью записаны.

 

· NONE

Страница базы данных при записи не будет формировать значение CHECKSUM или TORN_PAGE_DETECTION. SQL Server не будет проверять контрольную сумму и разрывы страниц при считывании, даже если значение CHECKSUM или TORN_PAGE_DETECTION будет присутствовать в заголовке страницы.

Состояние

Ограничение доступа

Какие пользователи имеют доступ к базе данных. Допустимые значения:

· Несколько (MULTI_USER)
Нормальное состояние производственной базы данных, позволяет нескольким пользователям получать одновременный доступ к базе данных.

· Один (SINGLE_USER)
Используется для операций обслуживания, одновременный доступ к базе данных получает только один пользователь.

· Ограничен (RESTRICTED_USER)
Базу данных могут использовать только члены ролей db_owner, dbcreator или sysadmin. Источники информации о базе данных

Представления каталога

Представление каталога	Отображение сведений о
sys.databases	Информация о всех базах данных и опциях для них установленных.
sys.filegroups	Информация обо всех файловых группах.
sys.database_files	Информация о файлах баз данных.

 

Создание базы данных

 

В одном экземпляре SQL Server может быть создано до 32 767 баз данных. В каждой базе данных должно быть по крайней мере 2 файла (первичный файл и файл журнала транзакций) и по крайней мере одна файловая группа. Для каждой базы данных может указываться не более 32 767 файлов и 32 767 файловых групп.

 

При создании новой базы данных в нее копируются все пользовательские объекты из базы данных model. Таким образом, можно добавлять любые объекты, например, таблицы, представления, хранимые процедуры и типы данных, в базу данных model, чтобы включать их во все вновь создаваемые базы данных. Файлы данных следует делать как можно большего размера, в соответствии с максимальным предполагаемым объемом данных в базе данных.

 

Создание базы данных осуществляется выполнением команды CREATE DATABASE:

 

CREATE DATABASE database_name

[ ON

{ [ PRIMARY ] [ <filespec> [,...n ]

[, <filegroup> [,...n ] ]

[ LOG ON { <filespec> [,...n ] } ] }

]

[ COLLATE collation_name ]

]

 

<filespec>::=

{

(

NAME = logical_file_name,

FILENAME = { 'os_file_name' }

[, SIZE = size [ KB | MB | GB | TB ] ]

[, MAXSIZE = { max_size [ KB | MB | GB | TB ] | UNLIMITED } ]

[, FILEGROWTH = growth_increment [ KB | MB | GB | TB | % ] ]

) [,...n ]

}

 

<filegroup>::=

{

FILEGROUP filegroup_name [ CONTAINS FILESTREAM ] [ DEFAULT ]

<filespec> [,...n ]

}

 

database_name

 

Имя новой базы данных. Имена баз данных должны быть уникальны внутри экземпляра SQL Server и должны соответствовать правилам для идентификаторов.

 

Аргумент database_name может иметь максимальную длину 128 символов, если для файла журнала не указано логическое имя. Если логическое имя файла не указано, то SQL Server формирует для журнала имена logical_file_name и os_file_name путем добавления суффикса к database_name. Это ограничивает длину аргумента database_name 123 символами, чтобы формируемое логическое имя файла было не длиннее 128 символов.

 

Если имя файла данных не указано, то SQL Server использует аргумент database_name в качестве имен logical_file_name и os_file_name. Путь по умолчанию берется из реестра. Его можно изменить в «Свойствах сервера» (страница «Параметры базы данных») в Management Studio. Изменение пути по умолчанию требует перезапуска SQL Server.

 

ON

 

Указывает, что дисковые файлы, используемые для хранения разделов данных в базе данных, определяются явно. Параметр ON необходимо применять, если за ним следует список элементов <filespec> с разделителями-запятыми, которые определяют файлы данных первичной файловой группы. За списком файлов в первичной файловой группе может следовать необязательный список элементов <filegroup> с разделителями-запятыми, которые определяют файловые группы пользователей и принадлежащие им файлы.

 

PRIMARY

 

Указывает, что связанный список <filespec> определяет первичный файл. Первый файл, указанный в элементе <filespec> в первичной файловой группе, становится первичным файлом. В базе данных может быть только один первичный файл.

 

Если параметр PRIMARY не указан, то первый файл списка в инструкции CREATE DATABASE становится первичным файлом.

 

LOG ON

Указывает, что дисковые файлы, используемые для хранения журнала базы данных, то есть файлы журналов, определяются явно. За параметром LOG ON следует список элементов <filespec> с разделителями-запятыми, которые определяют файлы журналов. Если параметр LOG ON не указан, автоматически создается один файл журнала, размер которого определяется большей из следующих двух величин: 512 КБ или 25 процентов от суммы размеров всех файлов с данными в базе данных. Этот файл помещается в местоположение для журнала по умолчанию.

 

<filespec>

 

Управляет свойствами файла.

 

NAME logical_file_name

 

Логическое имя, используемое в SQL Server при указании ссылки на файл. Аргумент logical_file_name должен быть уникальным в базе данных и должен соответствовать правилам для идентификаторов. Имя может быть символом или константой Юникода, а также обычным идентификатором или идентификатором с разделителями.

 

FILENAME { 'os_file_name' }

 

Задает физическое имя - путь и имя файла, используемые операционной системой при создании файла. Файл должен находиться на одном из следующих устройств: на локальном сервере, где установлен SQL Server, в сети хранения данных SAN или в сети на основе iSCSI. Указанный путь должен существовать до выполнения инструкции CREATE DATABASE.

 

Для файловой группы FILESTREAM параметр FILENAME указывает путь, где будут храниться данные FILESTREAM. Должен существовать путь вплоть до последнего каталога, но последний каталог существовать не должен. Например, если указать путь "D:\DATA\ FilestreamData ", папка " D:\DATA" должна существовать до запуска инструкции CREATE DATABASE, а папка "FilestreamData" - не должна.

 

Для файловой группы FILESTREAM может быть только один файл, причем файловую группу и файл необходимо создавать в одной инструкции.

 

Параметры SIZE, MAXSIZE и FILEGROWTH не применяется к файловой группе FILESTREAM и недоступны, если путь к файлу указан в формате UNC.

 

Если файл находится в необработанной секции (raw partition), аргумент os_file_name должен указывать только букву диска существующей необработанной секции. В каждой необработанной секции может быть создан только один файл.

 

Файлы данных не следует размещать в файловых системах со сжатием, за исключением случаев, когда файлы являются вторичными и доступны только для чтения или вся база данных доступна только для чтения. Файлы журналов ни в коем случае не должны размещаться в сжатых файловых системах.

 

SIZE size

 

Задает начальный размер файла. Параметр SIZE не может указываться, если аргумент os_file_name задан как путь в формате UNC.

Если аргумент size не задан для первичного файла, то компонент Database Engine использует размер первичного файла, указанный в базе данных model. Когда указан вторичный файл данных или журнала, но параметр size для файла не указан, компонент Database Engine задает размер файла равным 1 МБ. Размер, указанный для первичного файла, не должен быть менее размера первичного файла базы данных model.

 

Можно использовать суффиксы килобайт (KB), мегабайт (MB), гигабайт (GB) и терабайт (TB). По умолчанию — MБ. Аргумент Size имеет тип integer. Для значений, превышающих 2 147 483 647, используются более крупные единицы измерения.

 

MAXSIZE max_size

 

Задает максимальный размер, до которого может расти файл. Параметр MAXSIZE нельзя указывать, если аргумент os_file_name задан как путь в формате UNC. Можно использовать суффиксы KB, MB, GB и TB. По умолчанию — MБ. Укажите целое число (без дробной части). Если аргумент max_size не указан, размер файла будет увеличиваться до заполнения диска. Аргумент Max_size имеет тип integer. Для значений, превышающих 2 147 483 647, используются более крупные единицы измерения. UNLIMITED у казывает, что файл может расти вплоть до заполнения диска. В SQL Server файл журнала, для которого задано неограниченное увеличение размера, имеет максимальный размер 2 ТБ, а файл данных — 16 ТБ.

 

FILEGROWTH growth_increment

 

Задает автоматическое приращение размера файла. Значение параметра FILEGROWTH для файла не может превосходить значение параметра MAXSIZE. Параметр FILEGROWTH нельзя указывать, если аргумент os_file_name задан как путь в формате UNC.

Значение может быть указано в килобайтах, мегабайтах, гигабайтах, терабайтах или процентах (%). Если указано число без суффикса MB, KB или %, то по умолчанию используется MB. Если размер указан в процентах (%), то шаг роста это заданная часть в процентах от размера файла во время этого файла. Указанный размер округляется до ближайших 64 КБ.

 

Значение 0 указывает, что автоматическое приращение отключено и добавление пространства запрещено.

 

Если параметр FILEGROWTH не задан, значением по умолчанию является 1 МБ для файлов данных и 10% для файлов журналов, минимальное значение — 64 КБ.

 

<filegroup>

 

Управляет свойствами файловой группы. Файловая группа не может указываться для моментального снимка базы данных.

 

FILEGROUP filegroup_name

 

Логическое имя файловой группы. Аргумент filegroup_name должен быть уникальным в базе данных и не может быть именем PRIMARY или PRIMARY_LOG, предоставленным системой. Имя может быть символом или константой Юникода, а также обычным идентификатором или идентификатором с разделителями. Имя должно соответствовать правилам для идентификаторов.

 

CONTAINS FILESTREAM

 

Указывает, что файловая группа хранит большие двоичные объекты (BLOB) FILESTREAM в файловой системе.

 

DEFAULT

 

Задает указанную файловую группу как файловую группу по умолчанию в базе данных.

 

Пример: