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

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

В этой статье рассматриваются конкретные аспекты производительности при использовании системных временных таблиц, оптимизированных для памяти.

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

Вопросы производительности

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

  • Не выполняйте массовые удаления из текущей таблицы на одном шаге. Рассмотрите возможность удаления данных в несколько этапов с принудительным сбросом данных, запускаемым вручную между этапами, с помощью sp_xtp_flush_temporal_history, или во время SYSTEM_VERSIONING = OFF.

  • Не выполняйте массовое обновление таблиц за один раз, так как для этого может потребоваться вдвое больше памяти, чем для обновления нетемпоральной таблицы, оптимизированной для памяти. Это удвоенное потребление памяти носит временный характер, поскольку задача сброса данных регулярно выполняется, чтобы удерживать потребление памяти внутренних промежуточных таблиц в пределах ожидаемых границ в установившемся режиме. Граница составляет 10 процентов потребления памяти текущей темпоральной таблицы. Рассмотрите возможность выполнения массовых обновлений в несколько пакетов или SYSTEM_VERSIONING = OFF, например используя обновления, чтобы задать значения по умолчанию для недавно добавленных столбцов.

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

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

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

  • Last updated on