Особенности и ограничения темпоральных таблиц

Относится к: SQL Server 2016 (13.x) и более поздние версии База данных SQL AzureУправляемый экземпляр SQL AzureSQL Database в Microsoft Fabric

При работе с временными таблицами учитывайте следующие факторы и ограничения, вызванные спецификой системного версионирования:

  • Временная таблица должна иметь определённый первичный ключ, чтобы сопоставлять записи между текущей таблицей и таблицей истории. Для таблицы журнала нельзя определить первичный ключ.

  • SYSTEM_TIME Столбцы периода, используемые для записи значений ValidFrom и ValidTo, должны быть определены с типом данных datetime2.

  • Темпоральный синтаксис работает с таблицами или представлениями, которые хранятся локально в базе данных. Для удалённых объектов, таких как таблицы на связанном сервере или внешние таблицы, нельзя напрямую использовать в запросе предложение FOR или предикаты периода.

  • Если при создании таблицы журнала указывается ее имя, следует также указать имя схемы и таблицы.

  • По умолчанию таблица истории сжата PAGE.

  • Если текущая таблица разделена, таблица истории создаётся в стандартной группе файлов, поскольку конфигурация разделов не репликациируется автоматически из текущей таблицы в таблицу истории.

  • Темпоральные таблицы и таблицы журнала не поддерживают использование FileTable или FILESTREAM. FileTable и FILESTREAM позволяют управлять данными за пределами SQL Server, поэтому системное управление версиями не может быть гарантировано.

  • Таблицу узлов или граничную таблицу невозможно создать как темпоральную или преобразовать в нее.

  • Хотя темпоральные таблицы поддерживают типы данных BLOB, такие как (n)varchar(max), varbinary(max), (n)text и image, их использование связано со значительными затратами на хранение и влияет на производительность из-за своего размера. При проектировании системы будьте осторожны при использовании этих типов данных.

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

  • Таблица журнала не может содержать ограничения (первичный ключ, внешний ключ, таблица или ограничения столбцов).

  • Индексированные представления не поддерживаются поверх темпоральных запросов (запросов, использующих FOR SYSTEM_TIME предложение).

  • Параметр ONLINE (WITH (ONLINE = ON) не влияет на ALTER TABLE ALTER COLUMN в системно-версионируемой темпоральной таблице. Для столбца ALTER операция не выполняется в режиме онлайн независимо от того, какое значение указано для параметра ONLINE.

  • Инструкции INSERT и UPDATE не могут ссылаться на столбцы периода SYSTEM_TIME. Попытки вставки значений непосредственно в эти столбцы блокируются.

  • TRUNCATE TABLE не поддерживается, в то время как SYSTEM_VERSIONINGON.

  • Прямое изменение данных в таблице истории не допускается.

  • Чтобы не аннулировать логику языка обработки данными (DML), INSTEAD OF триггеры не разрешены ни в текущей, ни в таблице истории. AFTER триггеры разрешены только в текущей таблице. Эти триггеры отключены для таблицы истории, чтобы не нарушить логику операций DML.

  • Использование технологий репликации ограничено.

    • Группы доступности: полностью поддерживаются

    • Сбор данных изменений и отслеживание изменений: поддерживается только в текущей таблице

    • Репликация моментальных снимков и транзакционная репликация: поддерживается только для одного издателя без включённой темпоральности и одного подписчика с включённой темпоральностью. Использование нескольких подписчиков не поддерживается из-за зависимости от локальных системных часов, что может привести к несогласованным темпоральным данным. В этом случае издатель используется для рабочей нагрузки онлайн-обработки транзакций (OLTP), а подписчик — для разгрузки задач формирования отчётов, включая выполнение AS OF запросов. Когда агент распределения запускается, он открывает транзакцию, которая остаётся открытой до тех пор, пока агент распределителя не остановится. ValidFrom и ValidTo заполняются к началу первой транзакции, которую запускает агент распределения. Возможно, предпочтительнее запускать агент распространения по расписанию, а не использовать поведение по умолчанию, при котором он выполняется непрерывно, если для вашего приложения или вашей организации важно, чтобы ValidFrom и ValidTo заполнялись временем, близким к текущему системному времени. Дополнительные сведения см. в разделе Сценарии использования темпоральных таблиц.

    • Репликация слияния: не поддерживается для временных таблиц

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

  • Оптимальная стратегия индексирования включает кластерный индекс столбцевого хранилища или индекс рядового хранилища B-дерева в текущей таблице, а также кластерный индекс столбцевого хранилища в таблице истории для оптимального размера и производительности. Если вы создаёте или используете собственную таблицу истории, создайте такой индекс из столбцов периодов, начинающихся с колонки конца периода. Этот индекс ускоряет временные запросы и запросы, входящие в проверку согласованности данных. Для таблицы журнала по умолчанию создается кластеризованный индекс хранилища строк на основе столбцов периода (end, start). Минимум используйте некластерный индекс Rowstore.

  • При создании таблицы журнала следующие объекты и свойства не копируются из текущей таблицы в таблицу журнала:

    • Определение периода
    • Определение идентичности
    • Indexes
    • Statistics
    • Проверка ограничений
    • Триггеры
    • Конфигурация секционирования
    • Permissions
    • предикаты безопасности на уровне строк.

  • Нельзя настроить таблицу истории как текущую в цепочке таблиц истории.

Примечание.

В документации термин B-tree обычно используется в ссылке на индексы. В индексах rowstore ядро СУБД реализует дерево B+. Это не относится к индексам columnstore или индексам в таблицах, оптимизированных для памяти. Дополнительные сведения см. в руководстве по архитектуре и проектированию индексов SQL Sql Server и Azure.

Связанные материалы

  • Last updated on