高速データベース復旧
適用対象: 
SQL Server 2019 (15.x) 以降のバージョン Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics
高速データベース復旧 (ADR) では、SQL データベース エンジンの復旧プロセスの再設計により、データベースの可用性が向上します (実行時間の長いトランザクションが存在する場合は特に)。
ADR は SQL Server 2019 (15.x) で導入され、SQL Server 2022 (16.x) で改善されました。 ADR は、Azure SQL Database、Azure SQL Managed Instance、Azure Synapse SQL のデータベースでも使用可能です。 ADR は SQL Database と SQL Managed Instance で既定で有効になっており、無効にすることはできません。 Azure SQL における ADR の詳細については、「Azure SQL での高速データベース復旧」を参照してください。
この記事では、ADR機能の概要について説明します。 ADR を使用するには、高速データベース復旧の管理に関するページを参照してください。
概要
ADR の主な利点:
高速かつ一貫性のあるデータベース復旧
ADR を利用すると、実行時間の長いトランザクションが全体的な復旧時間に影響を与えることがありません。システム内でアクティブになっているトランザクションの数やそのサイズに関係なく、高速かつ一貫性のあるデータベース復旧が可能になります。
トランザクションの瞬間的ロールバック
ADR を利用すると、トランザクションがアクティブになっていた時間や実行された更新プログラムの数に関係なく、トランザクションのロールバックが一瞬で完了します。
ログの積極的切り捨て
ADR を利用すると、トランザクション ログが積極的に切り捨てられます。この積極的な切り捨ては、実行時間の長いアクティブなトランザクションが存在しても行われ、制御不能になることを防止します。
現在のデータベース復旧プロセス
ADR を使用しない場合、SQL Server のデータベース復旧は ARIES 復旧モデルに従い、次の図に示されている 3 つのフェーズで構成されます。詳細はこの図の下で説明されています。
分析フェーズ
SQL Server では、最後に成功したチェックポイント (あるいは、最も古いダーティ ページ LSN) の初めから終わりまでトランザクション ログを前方スキャンし、SQL Server が停止した時刻における各トランザクションの状態を判断します。
再実行フェーズ
SQL Server では、コミットした最も古いトランザクションから終わりまでトランザクション ログを前方スキャンし、コミットした操作をすべてやり直すことで、データベースをクラッシュ時の状態にします。
元に戻すフェーズ
クラッシュ時にアクティブになっていたすべてのトランザクションには、SQL Server はログを逆方向に進め、そのトランザクションで実行された操作を元に戻します。
この設計に基づき、データベース エンジンが予想外の再起動から復旧するために必要な時間は、クラッシュ時のシステムで最も大きいアクティブ トランザクションのサイズに (おおよそ) 比例します。 復旧するには、不完全なトランザクションをすべてロールバックする必要があります。 必要となる時間の長さは、トランザクションによって実行された作業の量と、トランザクションがアクティブになっている時間の長さに比例します。 そのため、SQL Server の復旧プロセスでは、実行時間の長いトランザクション (大規模な一括挿入操作や、サイズの大きなテーブルに対するインデックス作成操作など) がある場合に、長時間を要することがあります。
また、この設計に基づいて大規模なトランザクションをキャンセルまたはロールバックすると、前述と同じ"元に戻す"no復元フェースを使用するため、長時間がかかる場合があります。
さらに、データベース エンジンでは、実行時間の長いトランザクションが存在するとき、トランザクション ログを切り捨てることができません。それに対応するログ レコードが復旧プロセスやロールバック プロセスに必要になるためです。 結果として、一部のトランザクション ログが非常に大きくなり、大量のドライブ領域を占有します。
高速データベース復旧プロセス
ADR は、データベース エンジンの復元プロセスを次のように再設計することにより、前述の問題に対処しています。
- 最も古いアクティブ トランザクションの先頭を基点にログをスキャンする必要性をなくすことで、所要時間を一定化し、高速化を実現しています。 ADR を利用することで、トランザクション ログの処理は、最後に成功したチェックポイント (あるいは、最も古いダーティ ページのログ シーケンス番号 (LSN)) からに限定されます。 その結果、実行時間の長いトランザクションによって復元時間が影響を受けることはありません。
- トランザクション全体のログを処理する必要がなくなるので、必要なトランザクション ログ領域が最小限に抑えられます。 そのため、チェックポイントやバックアップごとにトランザクション ログを積極的に切り捨てることができます。
要するに、ADR では、物理的なデータベース変更をすべてバージョン管理し、論理的な操作だけを元に戻すようにすることで、処理の対象を減らし、瞬間的な処理を可能にして、高速なデータベース復旧を実現しているのです。 クラッシュ時にアクティブになっていたトランザクションがあれば、それには "中止" の印が付けられ、そのようなトランザクションによって生成されたバージョンは同時実行ユーザー クエリで無視されます。
ADR 復旧プロセスには、現行の復旧プロセスと同じく 3 つのフェーズがあります。 それらのフェーズと ADR が連動するしくみを示したものが次の図です。
分析フェーズ
プロセスは現行のものと同じままで、SLOG (システム ログ ストリーム) を再構築し、バージョン管理されない操作のログ レコードがコピーされるという作業が追加されます。
再実行フェーズ
2 つのサブフェーズに分割されます。
サブフェーズ 1
SLOG から再実行します (最も古い未コミット トランザクションから最後のチェックポイントまで)。 SLOG から数個のレコードを処理するだけで済むので、再実行操作は迅速に完了します。
サブフェーズ 2
トランザクション ログからの再実行は (最も古いコミット前のトランザクションではなく) 最後のチェックポイントから開始されます。
元に戻すフェーズ
ADR を利用した元に戻すフェーズは、SLOG を利用してバージョン管理されない操作と永続バージョン ストア (PVS) を元に戻し、行レベルではバージョンに基づいて論理的に元に戻すことで、ほぼ一瞬で完了します。
また、高速データベース復旧について説明する 8 分間のビデオもご覧ください。
ADR 復旧コンポーネント
ADR には次の 4 つの主要コンポーネントがあります。
永続的なバージョン ストア (PVS)
永続的なバージョン ストアは、従来の
tempdbバージョン ストアではなく、データベース自体で生成された行バージョンを永続化するためのデータベース エンジン メカニズムです。 PVS を使用すると、リソースの分離が可能になり、読み取り可能なセカンダリの可用性が向上します。 SQL Server 2019 (15.x) では、インスタンスごとに 1 つの PVS スレッドがあります。 SQL Server 2022 (16.x) 以降、SQL Server にはデータベースごとに 1 つの PVS クリーナー スレッドがあります。論理的に元に戻す
論理的に元に戻す操作は、行レベルでバージョンに基づいて元に戻す操作を担う非同期プロセスであり、バージョン管理されているすべての操作に関して、トランザクションを一瞬でロールバックし、元に戻します。
- 中止となったトランザクションをすべて追跡記録する
- すべてのユーザー トランザクションを対象に、PVS を使用してロールバックを実行する
- トランザクション中止の直後、すべてのロックを解放する
SLOG
SLOG は、バージョン管理されない操作 (メタデータ キャッシュの無効化やロックの取得など) のログ レコードを格納するメモリ内ログ ストリームのセカンダリです。 SLOG には次の特徴があります。
- ボリュームが少なく、メモリ内に収められる
- チェックポイント プロセス中にシリアル化され、ディスクに永続化される
- トランザクションのコミットに合わせて定期的に切り捨てられる
- バージョン管理されていない操作のみを処理することでやり直し操作と元に戻す操作を高速にする
- 必須のログ レコードのみを保持することでトランザクション ログの積極的な切り捨てを可能にする
クリーナー
クリーナーは、定期的に起動し、PVS から古い行バージョンを消去する非同期プロセスです。
SQL Server 2022 (16.x) における ADR の改善
永続バージョン ストア (PVS) ストレージに対処し、全体的なスケーラビリティを向上させるためにいくつかの点が改善されました。 SQL Server 2022 (16.x) の新機能について詳しくは、「SQL Server 2022 (16.x) Preview の新機能」を参照してください。
ユーザー トランザクションのクリーンアップ
ロックのエラーが原因で通常のプロセスではクリーンアップできなかったページをクリアします。
この機能により、テーブル レベルのロックの競合が原因で通常のクリーンアップ プロセスでは対処できなかったページに対して、ユーザー トランザクションでクリーンアップを実行できます。 この改善は、ユーザー ワークロードがテーブル レベルのロックを取得できないために ADR クリーンアップ プロセスがいつまでも失敗しないようにするのに役立ちます。
PVS ページ トラッカーのメモリ占有領域の削減
この改善により、バージョン管理されたページを維持するために必要なメモリ占有領域を減らすために、永続的なバージョン ストア (PVS) ページがエクステント レベルで追跡されます。
高速データ復旧 (ADR) クリーナーの機能強化
高速データ復旧 (ADR) クリーナーにより、バージョン クリーンアップの効率が向上し、SQL Server が中止されたバージョンのページを追跡して記録する方法が改善され、メモリと容量が向上しました。
トランザクションレベルの永続的なバージョン ストア (PVS)
この改善により、ADR では、システムに中止されたトランザクションがあるかどうかに関係なく、コミットされたトランザクションに属するバージョンをクリーンアップできます。 この改善により、中止されたトランザクション マップをトリミングするためにクリーンアップが正常にスイープを完了できない場合でも、永続的なバージョン ストア (PVS) ページの割り当てを解除できるようになりました。
この改善の結果、ADR クリーンアップが遅い場合や失敗する場合でも、永続的なバージョン ストア (PVS) の増加が減少します。
マルチスレッド バージョンのクリーンアップ
SQL Server 2019 (15.x) では、クリーンアップ プロセスは SQL Server インスタンス内のシングル スレッドです。
SQL Server 2022 (16.x) 以降、このプロセスではマルチスレッド バージョンのクリーンアップが使用されます。 これにより、同じ SQL Server インスタンス内の複数のデータベースを並列にクリーンアップできます。 この改善は、複数の大規模なデータベースがある場合に重要です。
バージョン クリーンアップのスケーラビリティのためにスレッドの数を調整するには、次のように
sp_configure設定ADR Cleaner Thread Countします。 スレッド数は、インスタンスのコア数に制限されます。ベスト プラクティスとして、データベースの数と同じ数の ADR クリーナー スレッドを使用することをお勧めします。 たとえば、2 つのデータベースを持つ SQL Server インスタンス上に配置するように
4構成ADR Cleaner Thread Countした場合、ADR クリーナーは引き続きデータベースごとに 1 つのスレッドのみを割り当て、残りの 2 つのスレッドはアイドル状態のままです。次の例では、スレッド数を次のように
4変更します。EXEC sp_configure 'ADR Cleaner Thread Count', '4'; RECONFIGURE WITH OVERRIDE;新しい拡張イベント
ADR PVS マルチスレッド バージョン クリーナーでテレメトリ用の新しい拡張イベント
tx_mtvc2_sweep_statsが追加されました。
ベスト プラクティスとガイダンス
ADR に推奨されるワークロードと推奨されないワークロードに関するガイダンスについては、「高速データベース復旧の管理」を参照してください。
重要
Azure SQL Database では、アイドル状態のトランザクション(トランザクション ログに 6 時間書き込まれていないトランザクション)は自動的に終了され、リソースが解放されます。