高速データベース復旧
適用対象:
SQL Server 2019 (15.x) 以降のバージョン Azure SQL DatabaseAzure SQL Managed InstanceSql データベース
高速データベース復旧 (ADR) では、データベース エンジンの復旧プロセスを再設計することで、特に実行時間の長いトランザクションが存在する場合にデータベースの可用性が向上します。
ADR は SQL Server 2019 (15.x) で導入され、SQL Server 2022 (16.x) で改善されました。 ADR は、Azure SQL Database、Azure SQL Managed Instance、Azure Synapse Analytics (専用 SQL プールのみ)、および Microsoft Fabric の SQL データベースでも使用できます。
手記
ADR は、Azure SQL Database、Azure SQL Managed Instance、および Fabric の SQL データベースで常に有効になります。
この記事では、ADR の概要について説明します。 ADR を使用するには、高速データベース復旧の管理に関するページを参照してください。
トランザクション ログとデータベースの復旧の詳細については、SQL Server トランザクション ログのアーキテクチャと管理ガイドの と 復元と復旧の概要 (SQL Server)を参照してください。
概要
ADR の主な利点:
高速かつ一貫性のあるデータベース復旧
実行時間の長いトランザクションは全体的な復旧時間に影響しないため、システム内のアクティブなトランザクションの数やサイズに関係なく、高速で一貫性のあるデータベース復旧が可能になります。
トランザクションの瞬間的ロールバック
トランザクションのロールバックは、トランザクションがアクティブになっている時間や行われた更新の数に関係なく、瞬時に実行されます。
ログの積極的切り捨て
アクティブな長時間実行中のトランザクションが存在する場合でも、トランザクションログは積極的に切り詰められ、それによって制御不能な成長を防ぎます。
従来のデータベース復旧プロセス
ADR がない場合、データベース復旧は ARIES 復旧モデル
分析フェーズ
データベース エンジンは、最後に成功したチェックポイントの先頭 (または最も古いダーティ ページ ログ シーケンス番号 (LSN)) から最後までトランザクション ログの前方スキャンを実行して、エンジンが停止した時点の各トランザクションの状態を判断します。
再実行フェーズ
データベース エンジンは、最も古いコミットされていないトランザクションから最後までのトランザクション ログの前方スキャンを実行します。 このプロセスは、クラッシュ時にデータベースをその状態に復元するためにコミットされたすべての操作を再実行します。
元に戻すフェーズ
クラッシュ時にアクティブだった各トランザクションについて、データベース エンジンはログを後方に走査し、このトランザクションが実行した操作を元に戻します。
従来のデータベース復旧プロセスでは、実行時間の長いトランザクションがアクティブな場合、クラッシュ後の復旧に時間がかかる場合があります。
データベース エンジンが予期しない再起動から復旧する時間は、クラッシュ時のシステム内で最も長いアクティブなトランザクションのサイズにほぼ比例します。 復旧するには、不完全なトランザクションをすべてロールバックする必要があります。 必要となる時間の長さは、トランザクションによって実行された作業の量と、トランザクションがアクティブになっている時間の長さに比例します。
大規模なトランザクションの取り消しまたはロールバックには、前に説明したのと同じ元に戻す回復フェーズが使用されるため、時間がかかる場合があります。
データベース エンジンは、実行時間の長いトランザクションがある場合にトランザクション ログを切り捨てることはできません。これは、対応するログ レコードが復旧およびロールバック プロセスに必要であるためです。 その結果、トランザクション ログは非常に大きくなり、大量のストレージ領域を消費する可能性があります。
高速データベース復旧プロセス
ADR は、データベース エンジンの復旧プロセスを完全に再設計して、従来の復旧モデルに関する以前の問題に対処します。
最も古いアクティブなトランザクションの先頭からトランザクション ログをスキャンする必要がなくなったため、復旧時間を一定にします。 ADR では、トランザクション ログは最後に成功したチェックポイント (または最も古いダーティ ページ LSN) からのみ処理されます。 その結果、復旧時間は実行時間の長いトランザクションの影響を受けず、通常は瞬時です。
トランザクション全体のログを保持する必要がなくなったため、必要なトランザクション ログ領域を最小限に抑えます。 そのため、チェックポイントやバックアップごとにトランザクション ログを積極的に切り捨てることができます。
大まかに言えば、ADR は、すべての物理データベースの変更をバージョン管理し、バージョン管理されていない操作のみを元に戻すことで、データベースの高速復旧を実現します。この操作は制限されており、ほぼ瞬時に元に戻すことができます。 クラッシュ時にアクティブになっていたトランザクションがあれば、それには "中止" の印が付けられ、そのようなトランザクションによって生成されたバージョンは同時実行ユーザー クエリで無視されます。
ADR 復旧プロセスには、従来の復旧プロセスと同じ 3 つのフェーズがあります。 これらのフェーズが ADR でどのように動作するかを次の図に示します。
分析フェーズ
このプロセスは従来の復旧モデルと同じままで、セカンダリ ログ ストリーム (SLOG) を再構築し、バージョン非対応の操作用にログ レコードをコピーします。
再実行フェーズ
2 つのサブフェーズに分割されます。
サブフェーズ 1
SLOG からのやり直し (最後のチェックポイントまでの最も古いコミットされていないトランザクション)。 再実行は、SLOG からいくつかのレコードを処理するだけで済む可能性があるため、高速な操作です。
サブフェーズ 2
トランザクション ログからのやり直しは、最後に成功したチェックポイント (コミットされていない最も古いトランザクションではなく) から開始されます。
元に戻すフェーズ
ADR を使用した元に戻すフェーズは、SLOG を使ってバージョン非対応の操作を元に戻し、永続バージョンストア (PVS) を使い、論理的に行レベルのバージョンベースの元に戻し操作を行うことで、ほぼ瞬時に完了します。
高速データベース復旧の説明については、次の 8 分間のビデオをご覧ください。
ADR 復旧コンポーネント
ADR には次の 4 つの主要コンポーネントがあります。
永続的なバージョン ストア (PVS)
永続バージョン ストア (PVS) は、
tempdbデータベースの従来のバージョン ストアではなく、データベース自体で行バージョンを保持するためのデータベース エンジン メカニズムです。 PVS を使用すると、リソースの分離が可能になり、読み取り可能なセカンダリの可用性が向上します。論理的に元に戻す
論理的に元に戻す操作は、行レベルでバージョンに基づいて元に戻す操作を担う非同期プロセスであり、バージョン管理されているすべての操作に関して、トランザクションを一瞬でロールバックし、元に戻します。
- 中止となったトランザクションをすべて追跡記録する
- すべてのユーザー トランザクションを対象に、PVS を使用してロールバックを実行する
- トランザクション中止の直後、すべてのロックを解放する
SLOG
SLOG は、バージョン管理されない操作 (メタデータ キャッシュの無効化やロックの取得など) のログ レコードを格納するメモリ内ログ ストリームのセカンダリです。 SLOG には次の特徴があります。
- ボリュームが少なく、メモリ内に収められる
- チェックポイント プロセス中にディスクに永続化される
- トランザクションのコミットに合わせて定期的に切り捨てられる
- バージョン管理されていない操作のみを処理することで、やり直しと元に戻す処理を高速化します
- 必須のログ レコードのみを保持することでトランザクション ログの積極的な切り捨てを可能にする
クリーナー
クリーナーは、定期的に起動し、PVS から古い行バージョンを消去する非同期プロセスです。
ADR の恩恵を受けるワークロード
ADR は、次のようなワークロードに特に役立ちます。
- 実行時間の長いトランザクション。
- トランザクション ログが大幅に増加する原因となるアクティブなトランザクション。
- 実行時間の長い復旧 (予期しないサービスの再起動やトランザクションの手動ロールバックなど) によるデータベースの使用不能期間が長い。
ADR のベスト プラクティス
不要な実行時間の長いトランザクションを回避します。 ADR は実行時間の長いトランザクションでもデータベースの復旧を高速化しますが、このようなトランザクションはバージョンのクリーンアップを遅らせ、PVS のサイズを増やすことができます。
DDL 操作を含む大規模なトランザクションは避けてください。 ADR は、セカンダリ ログ ストリーム (SLOG) メカニズムを使用して、復旧で使用される DDL 操作を追跡します。 SLOG は、トランザクションがアクティブな間にのみ使用されます。 SLOG はチェックポイント処理されるため、SLOG を使用する大規模なトランザクションを回避すると、全体的なパフォーマンスに役立ちます。 これらのシナリオにより、SLOG の領域が増える可能性があります。
- 多くの DDL は、1 つのトランザクションで実行されます。 たとえば、1 つのトランザクションで、一時テーブルを迅速に作成および削除します。
- テーブルには、変更されるパーティション/インデックスの数が非常に多いです。 たとえば、このようなテーブルに対する
DROP TABLE操作では、SLOG メモリを大量に予約する必要があります。これにより、トランザクション ログの切り捨てが遅れ、元に戻す/やり直す操作が遅れます。 回避策として、インデックスを個別に徐々に削除してから、テーブルを削除します。
SLOG の詳細については、ADR 回復コンポーネント
を参照してください。 不要な中止されたトランザクションを防止または削減します。 トランザクションの中止率が高いと、PVS クリーナーが負荷され、ADR のパフォーマンスが低下します。 中止は、高いデッドロック率、重複キー、制約違反、またはクエリ タイムアウトから発生する可能性があります。 sys.dm_tran_aborted_transactions DMV には、データベース エンジン インスタンスで中止されたすべてのトランザクションが表示されます。
nested_abort列は、トランザクションがコミット済みであることを示しますが、中止された部分 (セーブポイントまたは入れ子になったトランザクション) があり、PVS クリーンアップ プロセスも遅延する可能性があります。PVS の使用を考慮するのに十分な領域がデータベースにあることを確認します。 データベースに PVS を拡張するための十分な領域がない場合、ADR はバージョンの生成に失敗し、DML ステートメントが失敗する可能性があります。
書き込み集中型ワークロードで ADR が有効になっている場合、PVS に書き込まれた行バージョンがログに記録されるため、トランザクション ログ生成率が大幅に増加する可能性があります。 これにより、トランザクション ログ バックアップのサイズが大きくなる可能性があります。
トランザクション レプリケーション 、スナップショット レプリケーション、または変更データ キャプチャ (CDC)使用すると、ADR の積極的なログ切り捨て動作が無効にされ、ログ リーダーがトランザクション ログから変更を収集できるようになります。 トランザクション ログが十分な大きさであることを確認します。 Azure SQL Database では、すべてのワークロードのニーズに十分なトランザクション ログ領域を確保するために、サービス レベルまたはコンピューティング サイズを増やす必要がある場合があります。 同様に、Azure SQL Managed Instance では、インスタンスの最大ストレージ サイズを増やす必要がある場合があります。
SQL Server の場合は、ハイエンド SSD や Advanced SSD、永続メモリ (PMEM) など、上位層ストレージ上のファイル グループ上の PVS バージョン ストアを分離します。これは、ストレージ クラス メモリ (SCM) とも呼ばれます。 詳細については、「PVS の場所を別のファイル グループに変更する」を参照してください。
SQL Server の場合は、エラー ログで
PreallocatePVSエントリを監視します。PreallocatePVSエントリが存在する場合は、バックグラウンド タスクを使用してページを事前割り当てする ADR 機能を増やす必要がある場合があります。 バックグラウンドで PVS ページを事前に割り当てると、より高価なフォアグラウンド PVS 割り当てが削減され、ADR のパフォーマンスが向上します。ADR Preallocation Factorサーバー構成を使用して、この量を増やすことができます。 詳細については、「サーバー構成: ADR Preallocation Factor」を参照してください。SQL Server 2022 (16.x) 以降では、シングルスレッド クリーナーのパフォーマンスが不十分な場合は、マルチスレッド PVS クリーンアップを有効にすることを検討してください。 詳細については、「サーバー構成: ADR クリーナー スレッド数の」を参照してください。
PVS によるデータベース領域の使用率が高い、PVS のクリーンアップが遅いなどの問題が発生した場合は、「高速データベース復旧のトラブルシューティング」を参照してください。
SQL Server 2022 での ADR の機能強化
永続バージョン ストア (PVS) ストレージに対処し、全体的なスケーラビリティを向上させるためにいくつかの点が改善されました。 SQL Server 2022 (16.x) の新機能の詳細については、「SQL Server 2022の新機能」を参照してください。
同じ機能強化は、Azure SQL Database、Azure SQL Managed Instance、Azure Synapse Analytics (専用 SQL プールのみ)、および Microsoft Fabric の SQL データベースでも利用できます。
ユーザー トランザクションのクリーンアップ
ロック取得エラーのため、通常のプロセスでクリーンアップできないページをクリーンアップします。
この機能により、テーブル レベルのロックの競合が原因で通常のクリーンアップ プロセスでは対処できなかったページに対して、ユーザー トランザクションでクリーンアップを実行できます。 この改善は、ユーザー ワークロードがテーブル レベルのロックを取得できないために ADR クリーンアップ プロセスがいつまでも失敗しないようにするのに役立ちます。
PVS ページ トラッカー のメモリ占有領域を削減する
この改善により、バージョン管理されたページを維持するために必要なメモリ占有領域を減らすために、エクステント レベルで PVS ページが追跡されます。
PVS クリーナーの改善
PVS クリーナーは、データベース エンジンが中止されたトランザクションの行バージョンを追跡および記録する方法を改善するために、バージョンクリーンアップの効率を向上しました。 これにより、メモリとストレージの使用量が向上します。
トランザクションレベルの永続的なバージョン ストア (PVS)
この改善により、ADR は、システムに中止されたトランザクションがあるかどうかに関係なく、コミットされたトランザクションに属するバージョンをクリーンアップできます。 この改善により、中止されたトランザクション マップをトリミングするためにクリーンアップが正常にスイープを完了できない場合でも、PVS ページの割り当てを解除できます。
この改善の結果、PVS クリーンアップが遅い場合や失敗した場合でも、PVS の増加が減少します。
マルチスレッド バージョンのクリーンアップ
SQL Server 2019 (15.x) では、クリーンアップ プロセスはデータベース エンジン インスタンス内でシングル スレッドです。
SQL Server 2022 (16.x) 以降では、マルチスレッド バージョンのクリーンアップがサポートされています。 これにより、同じデータベース エンジン インスタンス上の複数のデータベースを並列にクリーンアップしたり、1 つのデータベースをより高速にクリーンアップしたりできます。 詳細については、「サーバー構成: ADR クリーナー スレッド数の」を参照してください。
ADR PVS マルチスレッド バージョン クリーナーを監視するための新しい拡張イベント (
tx_mtvc2_sweep_stats) が追加されました。