Управление историческими данными с использованием политики хранения

Важно!

Azure SQL Edge больше не поддерживает платформу ARM64.

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

  • Если столбец фильтра использует тип данных DATETIMEOFFSET, то условие — filter_column < DATEADD(WEEK, -1, SYSUTCDATETIME())
  • В противном случае условие равно filter_column < DATEADD(WEEK, -1, SYSDATETIME())

Фазы очистки данных в рамках политики их хранения

Операция очистки хранения данных состоит из двух этапов:

  1. Обнаружение. На этом этапе операция очистки определяет все таблицы в пользовательских базах данных для создания списка для очистки. Обнаружение выполняется один раз в день.
  2. Очистка. На этом этапе очистка выполняется для всех таблиц с конечным хранением данных, определенных на этапе обнаружения. Если операция очистки не может быть выполнена в таблице, эта таблица пропускается в текущем запуске и будет извлечена в следующей итерации. Во время очистки используются следующие принципы:
    • Если устаревшая строка заблокирована другой транзакцией, эта строка пропускается.
    • Очистка выполняется с временем ожидания блокировки по умолчанию 5 секунд. Если блокировки не могут быть получены в таблицах в течение периода ожидания, таблица пропускается в текущем запуске и будет извлечена в следующей итерации.
    • Если во время очистки таблицы возникает ошибка, эта таблица пропускается и будет выбрана в следующей итерации.

Ручная очистка

В зависимости от параметров хранения данных в таблице и природы рабочей нагрузки в базе данных возможно, что поток автоматической очистки может не полностью удалить все устаревшие строки во время его выполнения. Чтобы разрешить пользователям вручную удалять устаревшие строки, sys.sp_cleanup_data_retention хранимая процедура появилась в Sql Azure Edge.

Эта хранимая процедура принимает три параметра:

  • @schema_name: имя схемы владения для таблицы. Обязательно.
  • @table_name: имя таблицы, для которой выполняется ручная очистка. Обязательно.
  • @rowcount: выходная переменная. Возвращает число строк, очищенных с помощью ручной очистки SP. Необязательно.

Дополнительные сведения см. в разделе sys.sp_cleanup_data_retention (Transact-SQL).

В следующем примере показано выполнение ручной очистки SP для таблицы dbo.data_retention_table.

DECLARE @rowcnt BIGINT;
EXEC sys.sp_cleanup_data_retention 'dbo', 'data_retention_table', @rowcnt OUTPUT;
SELECT @rowcnt;

Удаление устаревших строк

Процесс очистки зависит от макета индекса таблицы. Для очистки устаревших данных во всех таблицах с ограниченным периодом хранения создается фоновая задача. Очистка логики для индекса rowstore (куча или дерево B-дерева) удаляет устаревшие строки в небольших блоках (до 10 000), минимизируя давление на журнал базы данных и подсистему ввода-вывода. Хотя логика очистки использует необходимый индекс дерева B, порядок удаления строк старше срока хранения не может быть твердо гарантирован. Другими словами, не зависимостей от порядка очистки в приложениях.

Предупреждение

В случае кучи и индексов дерева B-дерева хранение данных выполняет запрос на удаление базовых таблиц, который может конфликтовать с триггерами удаления в таблицах. Следует либо удалить триггеры удаления из таблиц, либо избежать использования хранения данных в таблицах с триггерами DML.

Задача очистки для кластеризованных индексов columnstore удаляет все группы строк одновременно (обычно содержат 1 миллион строк каждый), что эффективно, особенно если данные создаются и возрастают в высоком темпе.

Diagram of data retention cleanup.

Отличное сжатие данных и эффективная очистка хранения делает кластеризованные индексы columnstore идеальным выбором для сценариев, когда рабочая нагрузка быстро создает большой объем данных.

Мониторинг очистки хранения данных

Операции очистки политики хранения данных можно отслеживать с помощью расширенных событий в Sql Azure Edge. Дополнительные сведения о расширенных событиях см. в обзоре расширенных событий.

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

Имя Описание
data_retention_task_started Происходит при запуске фоновой задачи очистки таблиц с политикой хранения.
data_retention_task_completed Происходит, когда фоновая задача очистки таблиц с политикой хранения заканчивается.
data_retention_task_exception Происходит, когда фоновая задача очистки таблиц с политикой хранения завершается сбоем вне процесса очистки хранения, относяющегося к этим таблицам.
data_retention_cleanup_started Происходит при запуске процесса очистки таблицы с политикой хранения данных.
data_retention_cleanup_exception Происходит при сбое процесса очистки таблицы с политикой хранения.
data_retention_cleanup_completed Происходит при завершении процесса очистки таблицы с политикой хранения данных.

Кроме того, в динамическое представление управления добавлен новый тип RING_BUFFER_DATA_RETENTION_CLEANUP кольцевого sys.dm_os_ring_buffers буфера. Это представление можно использовать для отслеживания операций очистки политик хранения данных.

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