Руководство по архитектуре страницы и диапазонов

Относится к:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsСистема аналитической платформы (PDW)SQL база данных в Microsoft Fabric

В этом руководстве описывается структура страниц и экстентов, а также организация страниц и экстентов в файлах данных.

Страница — это фундаментальная единица хранилища данных в ядре СУБД. Место на диске, выделенное файлу данных (.mdf или NDF) в базе данных, логически делится на страницы, нумеруемые последовательно от 0 до n. Операции ввода-вывода диска с файлами данных выполняются на уровне страницы. То есть ядро СУБД считывает или записывает целые страницы данных.

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

Файлы журнала транзакций (LDF) не содержат страницы. Они содержат ряд записей журналов, которые не имеют фиксированного размера.

Страницы

В обычной книге все содержимое написано на страницах. Как и в книге, ядро СУБД записывает все строки данных на страницах. Размер каждой страницы одинаков: 8 КиБ. В книге большинство страниц содержат данные или основное содержимое книги. Некоторые страницы содержат метаданные, описывающие содержимое, например оглавление и индекс.

Аналогичным образом, большинство страниц в базе данных содержат фактические строки данных. Эти страницы называются страницами данных. Страницы Text/LOB также содержат данные, но используются только большими объектами (LOB). Страницы индексов содержат структуры индексов , которые помогают эффективно находить данные. Наконец, различные системные страницы хранят метаданные, описывающие организацию и свойства данных.

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

Тип страницы	Тип хранимых данных
Data	Строки данных со всеми данными. Данные в столбцах LOB-типов данных также могут частично храниться на страницах данных.
Текст или направление бизнеса	Данные в столбцах с помощью типов данных LOB, таких как text, ntext, image, varchar(max), nvarchar(max), varbinary(max), xml и json. Данные в столбцах переменной длины, когда строка данных превышает 8 КИБ, для столбцов, использующих такие типы данных, как varchar, nvarchar, varbinary и sql_variant.
Индекс	Структуры индекса Btree.
Глобальная карта распределения (GAM) Общая глобальная карта распределения (SGAM)	Сведения о выделенных и нераспределенных экстентах.
Свободное место на страницах (PFS)	Сведения о размещении страниц и доступном на них свободном месте.
Карта выделения индекса (IAM)	Сведения о экстентах, используемых кучей или индексом в единице выделения.
Схема массовых изменений (Bulk Changed Map, BCM)	Сведения об экстентах, измененных групповыми операциями с момента последнего резервного копирования транзакционного журнала.
Схема разностных изменений (Differential Changed Map, DCM)	Сведения об экстентах, которые изменились с момента последнего полного резервного копирования базы данных.

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

Структура, называемая массивом слотов , хранится в конце страницы. Каждый 2-байтовый элемент в массиве слотов соответствует строке, хранящейся на странице. Элемент массива слотов хранит смещение строки в байтах относительно начала страницы. Ядро СУБД использует эти смещения для поиска строк на странице.

Когда ядро СУБД добавляет строку на пустую страницу, она сохраняет строку сразу после заголовка. Элемент массива слотов для первой строки хранится в самом конце страницы. По мере добавления дополнительных строк они хранятся друг за другом с начала до конца страницы, а массив слотов растет с конца до начала страницы, как показано на следующей схеме.

Так как строки на странице удаляются или обновляются с течением времени, свободное пространство может отображаться среди оставшихся строк. При добавлении новой строки он может храниться в этом свободном пространстве, если достаточно места. Это означает, что строки на странице могут не храниться физически в определенном порядке. Однако ядро СУБД сохраняет записи массива слотов в логическом порядке. В результате строки страницы также обращаются в логическом порядке, например, в порядке, определенном ключом индекса BTree, который хранит страницу.

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

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

Ограничение на 8 060 байт не применяется к данным в столбцах, использующих LOB-типы данных (типы данных больших объектов). По умолчанию для таких столбцов данные хранятся в строке, если достаточно места. В противном случае строка содержит 16-байтовый указатель на отдельное дерево текстовых и LOB-страниц, храня LOB данные в единице выделения LOB_DATA. Параметр large value types out of rowтаблицы управляет этим поведением.

Ограничение на 8 060 байтов расслаблено для таблиц и индексов, содержащих столбцы переменной длины с помощью varchar, nvarchar, varbinary, sql_variant или определяемых пользователем типов данных CLR. Если общий размер строки всех столбцов фиксированной и переменной длины в куче или индексе превышает ограничение в 8 060 байтов, ядро СУБД динамически перемещает один или несколько столбцов переменной длины на страницы в единице ROW_OVERFLOW_DATA выделения, начиная с самой широкой столбцы.

Это действие выполняется всегда, когда в результате операций вставки или обновления общий размер строки выходит за предел в 8060 байт. При перемещении столбца на страницу в единице выделения ROW_OVERFLOW_DATA сохраняется 24-байтовый указатель на исходной странице в единице выделения IN_ROW_DATA. Если следующая операция уменьшает размер строки, ядро СУБД динамически перемещает столбцы обратно на исходную страницу данных.

Например, таблицу можно создать с двумя столбцами: один varchar(7000) и другой varchar(2000). По отдельности ни один столбец не превышает 8 060 байт, но в сочетании они будут делать это, если вся ширина каждого столбца заполнена. В этом случае ядро СУБД динамически перемещает столбец переменной длины varchar(7000) с исходной страницы на страницы в единице выделения ROW_OVERFLOW_DATA.

Если в таблице или индексе есть столбцы типа varchar, nvarchar, varbinary, sql_variant или пользовательский тип CLR, которые могут превышать 8 060 байт на строку, учтите следующее:

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

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

  Поэтому при проектировании таблицы с несколькими столбцами типов varchar, nvarchar, varbinary, sql_variant или пользовательскими типами, определёнными CLR, учитывайте процент строк, которые, скорее всего, будут переполняться, и частоту запросов к этим данным. Чтобы избежать замедления производительности, нормализуйте таблицу, чтобы переместить некоторые из этих столбцов в другую таблицу, чтобы уменьшить или исключить вероятность использования хранилища переполнения строк.

• Длина отдельных столбцов по-прежнему должна находиться в пределах 8 000 байт для столбцов типа varchar, nvarchar, varbinary, sql_variant и CLR, определяемых пользователем. И только общая их длина может выходить за предел в 8 060 байт на строку таблицы.

• Сумма длины других столбцов типа данных, например char, nchar и int , должна оставаться в пределах 8060-байтовых строк. Однако столбцы, использующие типы данных LOB, такие как varchar(max), nvarchar(max), и varbinary(max) исключаются из ограничения строк в 8 060 байтов.

• Ключ индекса кластеризованного индекса не может содержать столбцы varchar , содержащие данные в единице ROW_OVERFLOW_DATA выделения. Если кластеризованный индекс создается в столбце varchar, а все существующие данные находятся в блоке выделения IN_ROW_DATA, но последующий запрос INSERT или UPDATE перемещает данные за пределы строки, запрос завершается ошибкой. Дополнительные сведения см. в руководстве по архитектуре индекса и проектированию.

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

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

• Для получения сведений о таблицах или индексах, которые могут содержать превышающие размер страницы данные строки, используется функция динамического управления sys.dm_db_index_physical_stats. Индекс или раздел содержит данные переполнения строк, если функция возвращает строки, где столбец alloc_unit_type_desc равен ROW_OVERFLOW_DATA и столбец page_count больше 0.

Экстенты

Экстент представляет собой коллекцию из восьми физически смежных страниц. Размер каждой экстенты составляет 64 КиБ.

Существует два типа экстентов:

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

Вплоть до SQL Server 2014 (12.x), СУБД не выделяет однородные экстенты для таблиц с небольшим объемом данных. Новая куча или индекс выделяет страницы из смешанных экстентов. Когда куча или индекс растут до точки, в которой она использует восемь страниц, она переключается на единообразные экстенты для всех последующих выделений. При создании индекса для существующей таблицы, в которой содержится достаточно строк, чтобы сформировать восемь страниц в индексе, все единицы распределения для индекса находятся в однородных экстентах.

Начиная с SQL Server 2016 (13.x), ядро СУБД использует равномерные экстенты для выделений в пользовательской базе данных, а также в tempdb, за исключением выделений, принадлежащих первым восьми страницам цепочки IAM. Выделения в базах данных master, msdb и model по-прежнему сохраняют прежнее поведение.

До и включая SQL Server 2014 (12.x), можно использовать флаг трассировки (TF) 1118, чтобы изменить выделение по умолчанию на использование только универсальных экстентов. Дополнительные сведения об этом флаге трассировки см. в разделе флаг трассировки 1118.

Начиная с SQL Server 2016 (13.x), TF 1118 не действует. Функции, предоставляемые TF 1118 ранее, автоматически включены для всех пользовательских баз данных и для tempdb. Для пользовательских баз данных это поведение можно контролировать с помощью MIXED_PAGE_ALLOCATION параметра базы данных. Значение по умолчанию — OFF, это означает, что используются однородные экстенты. Дополнительные сведения см. в статье Параметры ALTER DATABASE SET.

Начиная с SQL Server 2012 (11.x), системная sys.dm_db_database_page_allocations функция может сообщать сведения о выделении страниц для базы данных, таблицы, индекса и секции.

Внимание

Системная sys.dm_db_database_page_allocations функция не поддерживается и подлежит изменению. Совместимость не гарантируется.

Начиная с SQL Server 2019 (15.x), системная функция sys.dm_db_page_info возвращает сведения о странице в базе данных. Функция возвращает одну строку, содержащую данные заголовка страницы, включая идентификатор объекта, идентификатор индекса и идентификатор секции. Во многих случаях эта функция может использоваться в качестве поддерживаемой альтернативы для неподдерживаемой DBCC PAGE команды.

Системные страницы

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

Страницы GAM и SGAM

Ядро СУБД использует два типа карт выделения для записи распределения экстентов:

• Глобальная карта распределения (GAM)

  Страницы GAM записывают экстенты, которые были выделены. Каждая страница GAM охватывает интервал примерно в 64 000 экстентов или около 4 гигабайт (ГИБ) данных, называемых интервалом GAM. Страница GAM имеет 1 бит для каждого экстента в покрываемом ей интервале. Если бит имеет 1значение, степень свободна; если бит имеет значение 0, то выделяется экстент.

• Общая глобальная карта распределения (SGAM)

  На SGAM-страницах записано, какие экстенты в текущий момент используются в качестве смешанных экстентов и имеют как минимум одну неиспользуемую страницу. Каждая страница SGAM также охватывает интервал около 64 000 экстентов или около 4 ГиБ данных. SGAM имеет 1 бит для каждого экстента в интервале, который он охватывает. Если бит имеет значение 1, экстент используется в качестве смешанной экстенты и имеет бесплатную страницу. Если бит 0, экстент не используется как смешанный экстент или является смешанным экстентом, где все страницы используются.

Вкратце, для каждого экстента установлены следующие битовые шаблоны на страницах GAM и SGAM в зависимости от его текущего использования.

Текущее использование экстента	Настройка битов карты GAM	Настройка битов карты SGAM
Свободно, в текущий момент не используется	1	0
Однородный экстент или заполненный смешанный экстент	0	0
Смешанный экстент со свободными страницами	0	1

Для управления экстентами ядро СУБД использует следующие концептуальные алгоритмы:

• Чтобы выделить одинаковую область, ядро СУБД ищет на странице GAM бит 1 и задаёт для него значение 0.
• Чтобы найти смешанный экстент со свободными страницами, движок базы данных выполняет поиск на странице SGAM 1 бит.
• Чтобы выделить смешанный экстент, СУБД выполняет поиск на странице GAM для бита 1, устанавливает для него значение 0, а затем задает соответствующий бит на странице SGAM 1.
• Чтобы освободить экстент, ядро СУБД гарантирует, что бит на странице GAM установлен в 1, а бит на странице SGAM установлен в 0.

Пропорциональное выделение заливки

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

Дополнительные сведения см. в статье "Стратегия заполнения файлов и файловой группы".

Страницы PFS

Страницы "Свободное пространство страницы" (PFS) записывают состояние выделения каждой страницы и объем свободного места на каждой странице. Страница PFS содержит 1 байт для каждой страницы, которую он отслеживает. Байт регистрирует, выделена ли страница, и если да, будь она пустая, от 1 до 50 процентов заполнена, от 51 до 80 процентов заполнена, от 81 до 95 процентов заполнена или 96 до 100 процентов заполнена.

После выделения экстентов объекту ядро СУБД использует страницы PFS для отслеживания того, какие страницы в экстенте имеют данные или являются бесплатными. Эта информация используется при выделении новой страницы ядром СУБД. Объем свободного места на странице сохраняется только для heap и страниц с большими объектами (LOB). Эта информация используется, когда ядро СУБД должен найти страницу с достаточным объемом свободного места для хранения только что вставленной строки.

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

Интервалы GAM и PFS

В файл данных добавляется новая страница PFS, GAM или SGAM для каждого дополнительного диапазона, который она отслеживает.

Существует новая страница PFS через 8 088 страниц после первой страницы PFS, а также дополнительные страницы PFS через каждые 8 088 страниц. В файле данных идентификатор страницы 1 — это страница PFS, идентификатор страницы 8088 — это страница PFS, идентификатор страницы 16176 — это страница PFS и т. д.

Аналогичным образом, существует пара страниц GAM и SGAM, начиная с страниц 2 и 3 соответственно, и повторяющихся для каждого интервала GAM приблизительно 64 000 экстентов или 4 ГиБ.

На следующей диаграмме показано первое вхождение страниц PFS, GAM и SGAM в начале файла данных после страницы заголовка файла. По мере роста файла новые страницы PFS, GAM и SGAM появляются в соответствующих интервалах.

Страницы IAM

Страница Index Allocation Map (IAM) отображает экстенты, используемые единицей выделения в интервале GAM. Единица выделения связана с разделом кучи или индекса и может принадлежать к одному из трех типов.

• IN_ROW_DATA

  Содержит страницы данных, не относящихся к объектам типа LOB (большим объектам), или части данных LOB, которые могут поместиться в строке.

• LOB_DATA

  Хранит страницы данных LOB, используемые такими типами данных, как varchar(max), nvarchar(max), varbinary(max), xml и json.

• ROW_OVERFLOW_DATA

  Содержит страницы данных больших объектов (LOB), используемые типами данных переменной длины, такими как varchar, nvarchar, varbinary или sql_variant, когда данные превышают размер строки в 8 060 байт.

Каждая секция кучи или индекса всегда содержит как минимум одну IN_ROW_DATA единицу выделения. Он также может содержать LOB_DATA и ROW_OVERFLOW_DATA единицы выделения в зависимости от типов данных и размеров строк, имеющихся в разделе.

Как и страница GAM или SGAM, страница IAM охватывает интервал 4-ГиБ в файле. Если единица выделения содержит экстенты из нескольких файлов или более одного 4-ГиБ интервала одного файла, несколько страниц IAM связаны в цепочку IAM. Таким образом, каждая единица распределения имеет как минимум одну страницу IAM для каждого файла, где есть экстенты. В файле может быть несколько страниц IAM, если диапазон экстентов, выделенных единице выделения в файле, превышает диапазон, который может записывать одна страница IAM. Страница IAM в файле может отслеживать экстенты в этом файле и в любом другом файле той же базы данных.

В отличие от PFS, GAM и страниц SGAM, повторяющихся через фиксированные интервалы, страницы IAM выделяются по мере необходимости для каждой единицы выделения. Системное представление sys.system_internals_allocation_units указывает на первую страницу IAM единицы размещения. Все страницы IAM, относящиеся к одной единице размещения, объединяются в цепочку IAM.

Внимание

Системное sys.system_internals_allocation_units представление не поддерживается и подлежит изменению. Совместимость не гарантируется. Это представление недоступно в База данных SQL Azure.

Страница IAM содержит заголовок, указывающий начальную степень диапазона экстентов, сопоставленных этой страницей. На странице IAM также есть растровое изображение, в котором каждый бит представляет один экстент. Первый бит схемы представляет первый экстент диапазона, второй бит — второй экстент и т. д. Если двоичный разряд равен 0, то диапазон, который он представляет, не выделен единице выделения, к которой принадлежит страница IAM. Если бит имеет значение 1, то степень, которую она представляет, выделяется единицам выделения, принадлежащим странице IAM.

Когда ядру СУБД необходимо вставить новую строку и нет свободного места на текущей странице, оно использует страницы IAM и PFS, чтобы найти страницу для размещения строки. Для кучи или текстовых/LOB страниц также используются страницы IAM и PFS, чтобы найти страницу с достаточным пространством для хранения строки. Ядро СУБД использует страницы IAM для поиска экстентов, выделенных блоку распределения. Для каждого экстента выполняется поиск страниц PFS, чтобы узнать, есть ли страница, которую можно использовать.

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

Ядро СУБД выделяет новый экстент для единицы выделения, если не может быстро найти страницу в существующем экстенте с достаточным пространством для вставки строки.

Страницы DCM и BCM

Ядро СУБД использует два типа системных страниц для отслеживания экстентов, измененных с момента последней полной резервной копии, и экстентов, измененных операциями массового копирования.

Страницы карты изменений (DCM) ускоряют создание разностных резервных копий. Функция "Карта массовых изменений" (BCM) ускоряет процессы пакетного копирования, если база данных использует журналируемую модель восстановления. Как и страницы GAM и SGAM, эти структуры представляют собой растровые изображения, в которых каждый бит представляет один экстент.

• Страницы DCM

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

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

• Страницы BCM

  Эти страницы отслеживают экстенты, которые были изменены операциями массового ведения журнала с момента последнего резервного копирования журнала транзакций. Если бит для экстента равен 1, то экстент был изменен. Если бит имеет значение 0, экстент не был изменен.

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

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

Страницы DCM и BCM хранятся в одинаковых интервалах GAM в размере примерно 4 ГиБ, как и страницы GAM и SGAM. Страницы DCM и BCM следуют страницам GAM и SGAM в физическом файле следующим образом:

Связанный контент

• Основы ввода-вывода SQL Server
• sys.allocation_units (Transact-SQL)
• Кучи (таблицы без кластеризованных индексов)
• sys.dm_db_page_info (Transact-SQL)
• Чтение страниц данных в ядре СУБД
• Запись страниц в ядро СУБД