Рекомендации и ограничения темпоральной таблицы

  • Статья
  • Чтение занимает 4 мин

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

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

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

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

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

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

  • По умолчанию таблица журнала сжимается с использованием метода PAGE.

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

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

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

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

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

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

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

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

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

  • TRUNCATE TABLE не поддерживается, а SYSTEM_VERSIONING имеет значение ON.

  • Запрещено изменять данные в таблице журнала напрямую.

  • ON DELETE CASCADE и ON UPDATE CASCADE не разрешены для текущей таблицы. Другими словами, если темпоральная таблица ссылается на таблицу в связи внешнего ключа (соответствующая parent_object_id в sys.foreign_key), CASCADE параметры не допускаются. Чтобы обойти это ограничение, используйте логику referenced_object_id приложения или триггеры после, чтобы обеспечить согласованность при удалении в таблице первичного ключа (соответствующей в sys.foreign_key). Если таблица первичного ключа является темпоральной, а ссылочная таблица — нет, это ограничение отсутствует.

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

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

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

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

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

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

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

  • В оптимальной стратегии индексирования будет использоваться кластеризованный индекс columnstore и/или индекс rowstore сбалансированного дерева для текущей таблицы, а также кластеризованный индекс columnstore для таблицы журнала. Такая стратегия будет обеспечивать оптимальный размер и оптимальную производительность. При создании или использовании собственной таблицы журнала мы настоятельно советуем создать этот индекс, состоящий из столбцов периода, начиная с последних. Это позволит ускорить выполнение темпоральных запросов, а также запросов, выполняющихся в ходе проверки согласованности данных. Таблица журнала по умолчанию содержит кластеризованный индекс rowstore, созданный на основе столбцов периода (с конца или с начала). Мы советуем использовать хотя бы некластеризованный индекс rowstore.

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

    • определение периода;
    • определение идентификатора;
    • Индексы
    • Статистика
    • Проверочные ограничения
    • Триггеры
    • конфигурация секционирования;
    • Разрешения
    • предикаты безопасности на уровне строк.

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

Примечание

В документации по SQL Server термин "сбалансированное дерево" обычно используется в отношении индексов. В индексах rowstore SQL Server реализует B+-дерево. Это не относится к индексам columnstore или хранилищам данных в памяти. Дополнительные сведения см. в руководстве по архитектуре и разработке индексов SQL Server.

См. также раздел