Share via

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

  • Статья

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

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

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

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

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

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

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

См. также: