Azure SQL の高速データベース復旧パターン

適用対象: Azure SQL Database Azure SQL Managed Instance

高速データベース復旧 (ADR) は、SQL Server データベース エンジンの復旧プロセスを再設計することで、特に実行時間の長いトランザクションがある場合にはデータベースの可用性を大幅に向上させる、SQL Server データベース エンジンの機能です。

ADR は、現時点では、Azure SQL Database、Azure SQL Managed Instance、Azure Synapse Analytics のデータベース、および SQL Server 2019 以降の Azure VM の SQL Server で使用できます。 SQL Server での ADR については、「高速データベース復旧を管理する」をご覧ください。

概要

ADR の主な利点:

• 高速かつ一貫性のあるデータベース復旧

  ADR を利用すると、実行時間の長いトランザクションが全体的な復旧時間に影響を与えることがありません。システム内でアクティブになっているトランザクションの数やそのサイズに関係なく、高速かつ一貫性のあるデータベース復旧が可能になります。

• トランザクションの瞬間的ロールバック

  ADR を利用すると、トランザクションがアクティブになっていた時間や実行された更新プログラムの数に関係なく、トランザクションのロールバックが一瞬で完了します。

• ログの積極的切り捨て

  ADR を利用すると、トランザクション ログが積極的に切り捨てられます。これは実行時間の長いアクティブなトランザクションが存在しても行われ、制御不能なログの拡大が防止されます。

標準のデータベース復旧プロセス

データベース復旧は ARIES 復旧モデルに従っており、3 つのフェーズで構成されています。次の図とその後の記述は、それらのフェーズについて詳しく説明したものです。

• 分析フェーズ

  最後に成功したチェックポイント (または最も古いダーティ ページ LSN) から末尾まで、トランザクション ログを前方スキャンして、データベースが停止した時点での各トランザクションの状態を判定します。

• 再実行フェーズ

  最も古い未コミット トランザクションから末尾まで、トランザクション ログを前方スキャンし、すべてのコミット済みの操作をやり直すことにより、データベースの状態をクラッシュが発生した時点の状態に戻します。

• 元に戻すフェーズ

  クラッシュの発生時点でアクティブだった各トランザクションについて、ログを後方に走査し、そのトランザクションによって実行された操作を元に戻します。

この設計では、SQL Server データベース エンジンが予期しない再起動から復旧するのにかかる時間は、クラッシュの発生時にシステム内でアクティブ時間が最も長かったトランザクションのサイズに (ほぼ) 比例します。 復旧するには、不完全なトランザクションをすべてロールバックする必要があります。 必要となる時間の長さは、トランザクションによって実行された作業の量と、トランザクションがアクティブになっている時間の長さに比例します。 そのため、実行時間の長いトランザクション (大規模な一括挿入操作や、サイズの大きなテーブルに対するインデックス作成操作など) がある場合、復旧プロセスが長時間になる可能性があります。

また、この設計では、先に述べたのと同じ元に戻す復旧フェーズが使用されるため、大規模なトランザクションを取り消したりロールバックしたりする際にも、長い時間がかかることがあります。

さらに、SQL Server データベース エンジンでは、復旧とロールバック プロセスのために、対応するログ レコードが必要となるため、実行時間の長いトランザクションがある場合に、トランザクション ログを切り捨てることができません。 SQL Server データベース エンジンがこのように設計されているため、以前は一部のお客様で、トランザクション ログのサイズが非常に大きくなり、膨大な量のドライブ領域が消費される問題が発生しました。

高速データベース復旧のプロセス

ADR では、SQL Server データベース エンジンの復旧プロセスを以下のように根本から再設計することで、上記の問題に対処しています。

• 最も古いアクティブ トランザクションの先頭を基点にログをスキャンする必要性をなくすことで、所要時間を一定化し、高速化を実現しています。 ADR では、最後に成功したチェックポイント (または最も古いダーティ ページのログ シーケンス番号 (LSN)) を基点に、それ以降のトランザクション ログだけを処理します。 そのため、実行時間の長いトランザクションによって復旧時間が影響を受けることはありません。
• トランザクション全体のログを処理する必要がなくなるので、必要なトランザクション ログ領域が最小限に抑えられます。 そのため、チェックポイントやバックアップごとにトランザクション ログを積極的に切り捨てることができます。

要するに、ADR では、物理的なデータベース変更をすべてバージョン管理し、論理的な操作だけを元に戻すようにすることで、処理の対象を減らし、瞬間的な処理を可能にして、高速なデータベース復旧を実現しているのです。 クラッシュが発生した時点でアクティブだったトランザクションは中止としてマークされるため、それらのトランザクションによって生成されたバージョンはすべて、同時ユーザー クエリで無視できます。

ADR 復旧プロセスには、現行の復旧プロセスと同じく 3 つのフェーズがあります。 次の図とその後の記述は、それらのフェーズが ADR でどのように動作するかについて詳しく説明したものです。

• 分析フェーズ

  プロセスは以前と同じままで、SLOG を再構築し、バージョン管理されない操作のログ レコードがコピーされるという処理が追加されています。

• 再実行フェーズ

  2 つのフェーズ (P) に分けられます

  • フェーズ 1

    SLOG から再実行します (最も古い未コミット トランザクションから最後のチェックポイントまで)。 SLOG から数個のレコードを処理するだけで済むので、再実行操作は迅速に完了します。

  • フェーズ 2

    トランザクション ログからの再実行は、(最も古い未コミット トランザクションではなく) 最後のチェックポイントから開始されます

• 元に戻すフェーズ

  ADR を利用した元に戻すフェーズは、SLOG を利用してバージョン管理されない操作と永続的なバージョン ストア (PVS) を元に戻し、行レベルではバージョンに基づいて論理的に元に戻すことで、ほぼ一瞬で完了します。

ADR 復旧コンポーネント

ADR には次の 4 つの主要コンポーネントがあります。

• 永続的なバージョン ストア (PVS)

  永続バージョン ストアは、データベース自体で生成された行バージョンを保持するための新しい SQL Server データベース エンジン メカニズムであり、従来の tempdb バージョン ストアに代わるものです。 PVS を使用すると、リソース分離が可能になり、読み取り可能なセカンダリの可用性が向上します。

• 論理的に元に戻す

  論理復元は、バージョン ベースの復元を行レベルで実行するための非同期プロセスです。トランザクションのロールバックを瞬時に実行し、バージョン管理されているすべての操作を元に戻すことができます。 論理復元は、次の方法で行われます。

  • 中止されたすべてのトランザクションを追跡し、それらを他のトランザクションから参照できなくします。
  • トランザクション ログを物理的にスキャンして変更を一度に 1 つずつ元に戻すのではなく、すべてのユーザー トランザクションに対して PVS を使用してロールバックを実行します。
  • トランザクションの中止直後にすべてのロックを解除します。 中止はメモリ内の変更をマークするだけなので、プロセスは非常に効率的です。そのため、ロックを長時間保持する必要がありません。

• SLOG

  SLOG は、バージョン管理されない操作 (メタデータ キャッシュの無効化やロックの取得など) のログ レコードを格納するメモリ内ログ ストリームのセカンダリです。 SLOG には次の特徴があります。

  • ボリュームが少なく、メモリ内に収められる
  • チェックポイント プロセス中にシリアル化され、ディスクに永続化される
  • トランザクションのコミットに合わせて定期的に切り捨てられる
  • バージョン管理されていない操作のみを処理することでやり直し操作と元に戻す操作を高速にする
  • 必須のログ レコードのみを保持することでトランザクション ログの積極的な切り捨てを可能にする

• クリーナー

  クリーナーは、定期的に起動し、不要なページ バージョンを消去する非同期プロセスです。

高速データベース復旧 (ADR) のパターン

以下の種類のワークロードについては、ADR のメリットが最も活かされます。

• 実行時間の長いトランザクションがあるワークロードには、ADR を使うことをお勧めします。
• アクティブなトランザクションが原因でトランザクション ログが大幅に拡大したことがあるワークロードには、ADR が推奨されます。
• 回復の実行に長い時間がかかり、データベースを長時間使用できなくなったことがあるワークロード (予期しない再起動やトランザクションの手動ロールバックなど) には、ADR が推奨されます。

高速データベース復旧に関するベスト プラクティス

• データベースでトランザクションが長時間実行されないようにします。 ADR の目標の 1 つは、長時間アクティブになっているトランザクションを再実行するためにデータベースの復旧を高速化することですが、トランザクションの実行時間が長いと、バージョンのクリーンアップが遅れ、PVS のサイズが大きくなる可能性があります。

• データ定義の変更や DDL 操作を伴う大きなトランザクションは避けるようにします。 ADR では、SLOG (システム ログ ストリーム) メカニズムを使って、復旧で使われる DDL 操作が追跡されます。 SLOG は、トランザクションがアクティブな間だけ使われます。 SLOG はチェックポイント化されるので、SLOG を使用する大規模なトランザクションを回避すると、全体的なパフォーマンスが向上します。 次のようなシナリオでは、SLOG が占める領域が大きくなる可能性があります。

  • 1 つのトランザクションで多くの DDL が実行される。 たとえば、1 つのトランザクションで、一時テーブルが急速に作成および削除される場合。

  • テーブルで変更されるパーティションまたはインデックスの数が非常に多い。 たとえば、そのようなテーブルに対する DROP TABLE 操作では、SLOG メモリを大量に確保する必要があり、トランザクション ログの切り捨てが遅れて、元に戻す/再実行の操作が遅くなります。 インデックスを個別に少しずつ削除してから、テーブルを削除することで、これを回避できます。 SLOG について詳しくは、「ADR 復旧コンポーネント」をご覧ください。

• 必要のない中止が発生する状況を回避するか減らします。 中止が多いと、PVS クリーナーの負荷が高くなり、ADR のパフォーマンスが低下します。 中止は、デッドロック、キーの重複、またはその他の制約違反が多いために発生している可能性があります。

  • sys.dm_tran_aborted_transactions DMV を見ると、SQL Server インスタンスで中止されたすべてのトランザクションがわかります。 nested_abort 列では、トランザクションがコミットされたが、PVS クリーンアップ プロセスをブロックしている可能性がある中断された部分 (セーブポイントまたは入れ子になったトランザクション) があることが示されます。 詳しくは、「ys.dm_tran_aborted_transactions (Transact-SQL)」をご覧ください。

  • ワークロードの間またはメンテナンス期間中に PVS クリーンアップ プロセスを手動でアクティブにするには、sys.sp_persistent_version_cleanup を使います。 詳しくは、「sys.sp_persistent_version_cleanup」をご覧ください。

• ストレージの使用、トランザクションの中止の多発、その他の要因で問題が発生する場合は、SQL Server での高速データベース復旧 (ADR) のトラブルシューティングに関する記事をご覧ください。

次のステップ

• データベース復旧の高速化
• SQL Server での高速データベース復旧 (ADR) のトラブルシューティング。