Управление историческими данными с использованием политики хранения
Внимание
Azure SQL Edge будет прекращена 30 сентября 2025 г. Дополнительные сведения и параметры миграции см. в уведомлении о выходе на пенсию.
Примечание.
Azure SQL Edge больше не поддерживает платформу ARM64.
После определения политики хранения данных для базы данных и базовой таблицы задача таймера фонового времени выполняется для удаления устаревших записей из таблицы, включенной для хранения данных. Идентификация соответствующих строк и их удаление из таблицы происходит прозрачно в фоновой задаче, запланированной и запущенной системой. Условие возраста для строк таблицы проверяется на основе столбца, filter_column указанного в определении таблицы. Если срок хранения равен одной неделе, например, строки таблиц, подходящие для очистки, соответствуют одному из следующих условий:
- Если столбец фильтра использует тип данных DATETIMEOFFSET, то условие —
filter_column < DATEADD(WEEK, -1, SYSUTCDATETIME()) - В противном случае условие равно
filter_column < DATEADD(WEEK, -1, SYSDATETIME())
Фазы очистки данных в рамках политики их хранения
Операция очистки хранения данных состоит из двух этапов:
- Обнаружение. На этом этапе операция очистки определяет все таблицы в пользовательских базах данных для создания списка для очистки. Обнаружение выполняется один раз в день.
- Очистка. На этом этапе очистка выполняется для всех таблиц с конечным хранением данных, определенных на этапе обнаружения. Если операция очистки не может быть выполнена в таблице, эта таблица пропускается в текущем запуске и будет извлечена в следующей итерации. Во время очистки используются следующие принципы:
- Если устаревшая строка заблокирована другой транзакцией, эта строка пропускается.
- Очистка выполняется с временем ожидания блокировки по умолчанию 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 миллион строк каждый), что эффективно, особенно если данные создаются и возрастают в высоком темпе.
Отличное сжатие данных и эффективная очистка хранения делает кластеризованные индексы 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 буфера. Это представление можно использовать для отслеживания операций очистки политик хранения данных.