高速データベース復旧
適用対象:
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 復旧モデルに従います。これは、次の図で詳しく説明する 3 つのフェーズで構成されています。
分析フェーズ
データベース エンジンは、最後に成功したチェックポイントの先頭 (または最も古いダーティ ページ ログ シーケンス番号 (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 は、変更するデータ ページに直接、または別のシステム テーブルに行バージョンを格納します。 詳細については、｢永続的なバージョン ストア (PVS) で使用される領域」を参照してください。
論理的に元に戻す
論理的に元に戻す操作は、行レベルでバージョンに基づいて元に戻す操作を担う非同期プロセスであり、バージョン管理されているすべての操作に関して、トランザクションを一瞬でロールバックし、元に戻します。
- 中止となったトランザクションをすべて追跡記録する
- すべてのユーザー トランザクションを対象に、PVS を使用してロールバックを実行する
- トランザクション中止の直後、すべてのロックを解放する
SLOG
SLOG は、バージョン管理されない操作 (メタデータ キャッシュの無効化やロックの取得など) のログ レコードを格納するメモリ内ログ ストリームのセカンダリです。 SLOG には次の特徴があります。
- ボリュームが少なく、メモリ内に収められる
- チェックポイント プロセス中にディスクに永続化される
- トランザクションのコミットに合わせて定期的に切り捨てられる
- バージョン管理されていない操作のみを処理することで、再実行と元に戻す処理を高速化する
- 必須のログ レコードのみを保持することでトランザクション ログの積極的な切り捨てを可能にする
クリーナー
クリーナーは、定期的に起動し、PVS から古い行バージョンを消去する非同期プロセスです。
ADR の恩恵を受けるワークロード
ADR は、次のようなワークロードの場合、特に役立ちます。
- 実行時間の長いトランザクション。
- トランザクション ログが大幅に増加する原因となるアクティブなトランザクション。
- (予期しない再起動や手動でのトランザクションのロールバックなどで) 長期の復旧時間が原因の、長時間にわたるデータベースの使用不可の状態。
ADR は、古くて非推奨の高可用性機能であるデータベース ミラーリング 使用しているデータベースではサポートされていません。
ADR のベスト プラクティス
実行時間の長い不要なトランザクションを回避します。 ADR は実行時間の長いトランザクションでもデータベースの復旧を高速化しますが、このようなトランザクションはバージョンのクリーンアップを遅らせ、PVS のサイズを増やす場合があります。
DDL 操作を含む大規模なトランザクションは避けてください。 ADR は、セカンダリ ログ ストリーム (SLOG) メカニズムを使用して、復旧で使用される DDL 操作を追跡します。 SLOG は、トランザクションがアクティブな間だけ使われます。 SLOG はチェックポイント化されるので、SLOG を使用する大規模なトランザクションを回避すると、全体的なパフォーマンスが向上します。 次のようなシナリオでは、SLOG が占める領域が大きくなる可能性があります。
- 1 つのトランザクションで多くの DDL が実行される。 たとえば、1 つのトランザクションで、一時テーブルが急速に作成および削除される場合。
- テーブルで変更されるパーティションまたはインデックスの数が非常に多い。 たとえば、そのようなテーブルに対する
DROP TABLE操作では、SLOG メモリを大量に予約する必要があり、トランザクション ログの切り捨てが遅れて、元に戻す/再実行の操作が遅くなります。 回避策として、個々のインデックスを 1 つずつ削除し、その後でテーブルを削除します。
SLOG の詳細については、「ADR 回復コンポーネント」を参照してください。
不必要なトランザクションの中断を防止または削減します。 トランザクションの中止率が高いと、PVS クリーナーの負荷が増え、ADR のパフォーマンスが低下します。 中止は、高いデッドロック率、重複キー、制約違反、またはクエリのタイムアウトによって発生する可能性があります。 sys.dm_tran_aborted_transactions DMV には、データベース エンジン インスタンスで中止されたすべてのトランザクションが表示されます。
nested_abort列は、トランザクションがコミット済みであることを示しますが、中止された部分 (セーブポイントまたは入れ子になったトランザクション) があり、これも PVS クリーンアップ プロセスに遅延が生じる原因になる場合があります。PVS の使用を考慮するのに十分なスペースがデータベースにあることを確認します。 データベースに PVS を拡張するための十分な領域がない場合、ADR はバージョンの生成に失敗し、DML ステートメントが失敗する可能性があります。
書き込み集中型ワークロードで ADR が有効になっている場合、PVS に書き込まれた行バージョンがログされるため、トランザクション ログ生成率が大幅に増加する可能性があります。 これにより、トランザクション ログのバックアップのサイズが大きくなることがあります。
トランザクション レプリケーション、スナップショット レプリケーション、または変更データ キャプチャ (CDC) を使用すると、ADR の積極的なログ切り捨て動作が無効にされ、ログ リーダーがトランザクション ログから変更を収集できるようになります。 トランザクション ログが十分な大きさであることを確認します。
Azure SQL Database で CDC または変更フィード 使用する場合は、サービス レベルまたはコンピューティング サイズを増やして、すべてのワークロードのニーズに十分なトランザクション ログ領域を確保することが必要になる場合があります。 同様に、Azure SQL Managed Instance では、インスタンスの最大ストレージ サイズを増やす必要がある場合があります。
SQL Server の場合、ハイエンド SSD、高度な SSD、永続メモリ (PMEM) (ストレージ クラス メモリ (SCM) と呼ばれることもある) などの上位層ストレージ上のファイル グループに PVS バージョン ストアを分離します。 詳細については、PVS の場所を別のファイル グループに変更する方法に関する記事を参照してください。
SQL Server の場合は、エラー ログで
PreallocatePVSエントリを監視します。PreallocatePVSエントリが存在する場合は、バックグラウンド タスクを使用してページを事前に割り当てる ADR 機能を増やす必要がある場合があります。 バックグラウンドで PVS ページを事前に割り当てると、より高価なフォアグラウンド PVS 割り当てが削減され、ADR のパフォーマンスが向上します。ADR Preallocation Factorサーバー構成を使用して、この量を増やすことができます。 詳細については、「サーバー構成: ADR 事前割り当て係数」を参照してください。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) が追加されました。