アイテム保持ポリシーを使用して履歴データを管理する
重要
Azure SQL Edge では、ARM64 プラットフォームがサポートされなくなりました。
データベースと基になるテーブルに対してデータ保持ポリシーを定義した後、バックグラウンド時間タイマー タスクを実行して、データ保有期間が有効になっているテーブルから古いレコードを削除します。 一致する行の識別とテーブルからの削除は、システムによってスケジュール設定されて実行されるバックグラウンド タスクにおいて透過的に行われます。 テーブルの行の Age 条件は、テーブル定義で指定されている filter_column 列に基づいてチェックされます。 たとえば、保持期間が 1 週間に設定されている場合、クリーンアップの対象となるテーブルの行は次のいずれかの条件を満たします。
- フィルター列に DATETIMEOFFSET データ型が使用されている場合、条件は
filter_column < DATEADD(WEEK, -1, SYSUTCDATETIME())となります - そうでない場合、条件は
filter_column < DATEADD(WEEK, -1, SYSDATETIME())です
データ保有のクリーンアップ フェーズ
データ保有のクリーンアップ操作は、2 つのフェーズで構成されます。
- 検出: このフェーズでは、クリーンアップ操作によって、ユーザー データベース内のすべてのテーブルが特定され、クリーンアップの一覧が作成されます。 検出は 1 日に 1 回実行されます。
- クリーンアップ: このフェーズでは、検出フェーズで特定されたデータ保持の期間が有限であるすべてのテーブルに対してクリーンアップを実行します。 テーブルに対してクリーンアップ操作を実行できない場合、そのテーブルは現在の実行ではスキップされ、次の繰り返しで再試行されます。 クリーンアップ時には、次の原則が使用されます。
- 古い行が別のトランザクションによってロックされている場合、その行はスキップされます。
- クリーンアップは既定の 5 秒のロック タイムアウトで実行されます。 タイムアウト ウィンドウ内にテーブルのロックを取得できない場合、現在の実行ではテーブルがスキップされ、次の繰り返しで再試行されます。
- テーブルのクリーンアップ中にエラーが発生した場合、そのテーブルはスキップされ、次の繰り返しで選択されます。
手動クリーンアップ
テーブルのデータ保有期間の設定とデータベースのワークロードの性質によっては、自動クリーンアップ スレッドの実行中にすべての古い行を完全に削除できない可能性があります。 ユーザーが古い行を手動で削除できるようにするため、Azure SQL Edge で sys.sp_cleanup_data_retention ストアド プロシージャが導入されました。
このストアド プロシージャは、3 つのパラメーターを受け取ります。
@schema_name: テーブルを所有するスキーマの名前。 必須。@table_name: 手動クリーンアップを実行するテーブルの名前。 必須。@rowcount: 出力変数。 手動クリーンアップ sp によってクリーンアップされた行の数を返します。 省略可能。
詳細については、「sys.sp_cleanup_data_retention (Transact-SQL)」を参照してください。
次の例は、テーブル dbo.data_retention_table の手動クリーンアップ sp の実行を示しています。
DECLARE @rowcnt BIGINT;
EXEC sys.sp_cleanup_data_retention 'dbo', 'data_retention_table', @rowcnt OUTPUT;
SELECT @rowcnt;
古い行の削除方法
クリーンアップ プロセスは、テーブルのインデックスのレイアウトに依存します。 有限の保持期間を持つすべてのテーブルの古いデータをクリーンアップするために、バックグラウンド タスクが作成されます。 行ストア (ヒープまたは B ツリー) のインデックスのクリーンアップ ロジックでは、よりサイズの小さなまとまり (最大 10,000) で期限切れの行が削除され、データベース ログや I/O サブシステムへの負荷が軽減されます。 クリーンアップ ロジックでは必要な B ツリー インデックスが使用されますが、保有期間より古い行の削除の順序は確実には保証できません。 言い換えると、アプリケーションではクリーンアップ順序に依存してはいけません。
警告
ヒープと B ツリーのインデックスの場合、データ保有は基になるテーブルに対して削除クエリを実行しますが、テーブルの削除トリガーと競合する可能性があります。 削除トリガーをテーブルから削除するか、削除 DML トリガーが設定されたテーブルではデータ保持期間の使用を避けるべきです。
クラスター化列ストアのインデックスのクリーンアップ タスクでは、行グループ全体を一度に削除します (通常、各グループには 100 万行が含まれます)。これは効率が高く、データが速いペースで生成および期限切れになるときは特にそうです。
優れたデータ圧縮と効率的な保有期間のクリーンアップにより、クラスター化列ストア インデックスはワークロードが急速に大量のデータを生成するシナリオに最適な選択肢になります。
データ保有のクリーンアップを監視する
データ保持ポリシーのクリーンアップ操作は、Azure SQL 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 動的管理ビューに追加されました。 このビューは、データ保有のクリーンアップ操作を監視するために使用できます。