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

  • Статья

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

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

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

  • 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не поддерживается ONв то время как SYSTEM_VERSIONING .

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

Следующие шаги