Темпоральные таблицы, версионируемые системой, с таблицами, оптимизированными для памяти

Применимо к: SQL Server 2016 (13.x) и более поздним версиям Управляемый экземпляр SQL Azure

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

Note

Оптимизированные для памяти временные таблицы доступны только в SQL Server и Управляемом экземпляре SQL Azure. Оптимизированные для памяти таблицы и темпоральные таблицы доступны независимо в Базе данных SQL Azure.

Overview

Системные темпоральные таблицы автоматически сохраняют полный журнал изменений данных и предоставляют удобные расширения Transact-SQL для анализа на определенный момент времени. В типичном случае история данных сохраняется долгое время (несколько месяцев, даже лет), хотя она не подвергается регулярному запросу.

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

Системно-версионируемые временные таблицы для таблиц, оптимизированных для работы в памяти, обеспечивают высокую пропускную способность транзакций и параллелизм без блокировок. Вы можете хранить большое количество исторических данных, используя таблицы в памяти для хранения текущих данных (временную таблицу) и дисковые таблицы для исторических данных. Влияние на операции DML уменьшается за счёт использования внутренней, автоматически создаваемой промежуточной таблицы, оптимизированной для работы в памяти, которая хранит недавнюю историю и позволяет выполнять операции DML в собственно компилируемом коде.

Эта архитектура показана на следующей диаграмме.

Сведения о реализации

При создании таблицы, оптимизированной для памяти в системе, помните о следующих рекомендациях. Варианты синтаксиса и пример см. в разделе CREATE TABLE.

Только устойчивые таблицы, оптимизированные для памяти, могут быть системными версиями (DURABILITY = SCHEMA_AND_DATA).
Таблица истории для системной версии, оптимизированной по памяти, должна быть на диске, независимо от того, создаёте ли вы её или система.
Вы можете использовать запросы, которые затрагивают только текущую таблицу в памяти в нативно скомпилированных T-SQL модулях. Нативно компилируемые модули не поддерживают предложение FOR SYSTEM TIME, однако специальные запросы и модули, не компилируемые нативно, могут использовать это предложение с таблицами, оптимизированными для работы в памяти.
При использовании SYSTEM_VERSIONING = ON система автоматически создаёт внутреннюю оптимизированную для памяти промежуточную таблицу для приема последних системно-версионированных изменений, которые возникают в результате операций обновления и удаления в текущей оптимизированной для памяти таблице.
Асинхронная задача сброса данных регулярно перемещает данные из внутренней промежуточной таблицы, оптимизированной для работы в памяти, в таблицу журнала на диске. Этот механизм сброса данных поддерживает объём памяти, используемой внутренними буферами, на уровне менее 10 % от объёма памяти, потребляемой их родительскими объектами. Вы можете отслеживать общее потребление памяти оптимизированной для памяти системно-версионной временной таблицы, выполнив запрос к sys.dm_db_xtp_memory_consumers и суммировав данные для внутренней оптимизированной для памяти промежуточной таблицы и текущей временной таблицы.
Чтобы вручную выполнить промывку данных, запустите sp_xtp_flush_temporal_history.
С помощью SYSTEM_VERSIONING = OFF, или при изменении схемы таблицы с системным управлением версиями путём добавления, удаления или изменения столбцов, всё содержимое внутреннего промежуточного буфера перемещается в дисковую таблицу журнала версий.
Запросы исторических данных эффективно выполняются на уровне изоляции моментальных снимков и всегда возвращают объединение между промежуточным буфером в памяти и таблицей на основе дисков без дубликатов.
ALTER TABLE Операции, изменяющие схему таблицы внутри, должны выполнять промывку данных, что может продлить процесс.

Внутренняя промежуточная таблица, оптимизированная для памяти

Система создает внутреннюю промежуточную таблицу, оптимизированную для памяти, для оптимизации операций DML.

Название таблицы имеет следующий формат: Memory_Optimized_History_Table_<object_id> где <object_id> — идентификатор текущей временной таблицы.
Таблица воспроизводит схему текущей временной таблицы плюс один столбец bigint . Этот дополнительный столбец обеспечивает уникальность строк, перемещённых во внутренний буфер истории.
Дополнительный столбец имеет следующий формат имени: Change_ID[<suffix>]где <suffix> необязательно добавляется в случае, когда таблица уже имеет Change_ID столбец.
Максимальный размер строки для системно-версионируемой таблицы, оптимизированной для памяти, уменьшается на 8 байт из-за дополнительного столбца bigint в staging-таблице. Максимальный объем теперь составляет 8 052 байта.
Внутренняя оптимизированная по памяти таблица постановки отсутствует в обозреватель объектов SQL Server Management Studio.
Метаданные об этой таблице и её связи с текущей временной таблицей можно найти в sys.internal_tables.

Задача очистки данных

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

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

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

Вы можете выполнить очистку данных, выполнив sp_xtp_flush_temporal_history и указав имя схемы и таблицы:

EXEC sys.sp_xtp_flush_temporal_history <schema_name>, <object_name>;

Тот же процесс перемещения данных вызывается, как и при выполнении системой задачи очистки данных во внутреннем расписании.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-08-18