Azure SQL の高速データベース復旧パターンAccelerated Database Recovery in Azure SQL

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

高速データベース復旧 (ADR) は、SQL Server データベース エンジンの復旧プロセスを再設計することで、特に実行時間の長いトランザクションがある場合にはデータベースの可用性を大幅に向上させる、SQL Server データベース エンジンの機能です。Accelerated Database Recovery (ADR) is a SQL Server database engine feature that greatly improves database availability, especially in the presence of long running transactions, by redesigning the SQL Server database engine recovery process.

ADR は、現時点では、Azure SQL Database、Azure SQL Managed Instance、Azure Synapse Analytics のデータベース (現在はプレビュー段階)、および SQL Server 2019 以降の Azure VM の SQL Server で使用できます。ADR is currently available for Azure SQL Database, Azure SQL Managed Instance, databases in Azure Synapse Analytics (currently in preview), and SQL Server on Azure VMs starting with SQL Server 2019.

注意

Azure SQL Database と Azure SQL Managed Instance では、ADR が既定で有効になっており、いずれかの製品での ADR の無効化はサポートされていません。ADR is enabled by default in Azure SQL Database and Azure SQL Managed Instance and disabling ADR for either product is not supported.

概要Overview

ADR の主な利点:The primary benefits of ADR are:

  • 高速かつ一貫性のあるデータベース復旧Fast and consistent database recovery

    ADR を利用すると、実行時間の長いトランザクションが全体的な復旧時間に影響を与えることがありません。システム内でアクティブになっているトランザクションの数やそのサイズに関係なく、高速かつ一貫性のあるデータベース復旧が可能になります。With ADR, long running transactions do not impact the overall recovery time, enabling fast and consistent database recovery irrespective of the number of active transactions in the system or their sizes.

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

    ADR を利用すると、トランザクションがアクティブになっていた時間や実行された更新プログラムの数に関係なく、トランザクションのロールバックが一瞬で完了します。With ADR, transaction rollback is instantaneous, irrespective of the time that the transaction has been active or the number of updates that has performed.

  • ログの積極的切り捨てAggressive log truncation

    ADR を利用すると、トランザクション ログが積極的に切り捨てられます。これは実行時間の長いアクティブなトランザクションが存在しても行われ、制御不能なログの拡大が防止されます。With ADR, the transaction log is aggressively truncated, even in the presence of active long-running transactions, which prevents it from growing out of control.

標準のデータベース復旧プロセスStandard database recovery process

データベース復旧は ARIES 復旧モデルに従っており、3 つのフェーズで構成されています。次の図とその後の記述は、それらのフェーズについて詳しく説明したものです。Database recovery follows the ARIES recovery model and consists of three phases, which are illustrated in the following diagram and explained in more detail following the diagram.

現在の復旧プロセス

  • 分析フェーズAnalysis phase

    最後に成功したチェックポイント (または最も古いダーティ ページ LSN) から末尾まで、トランザクション ログを前方スキャンして、データベースが停止した時点での各トランザクションの状態を判定します。Forward scan of the transaction log from the beginning of the last successful checkpoint (or the oldest dirty page LSN) until the end, to determine the state of each transaction at the time the database stopped.

  • 再実行フェーズRedo phase

    最も古い未コミット トランザクションから末尾まで、トランザクション ログを前方スキャンし、すべてのコミット済みの操作をやり直すことにより、データベースの状態をクラッシュが発生した時点の状態に戻します。Forward scan of the transaction log from the oldest uncommitted transaction until the end, to bring the database to the state it was at the time of the crash by redoing all committed operations.

  • 元に戻すフェーズUndo phase

    クラッシュの発生時点でアクティブだった各トランザクションについて、ログを後方に走査し、そのトランザクションによって実行された操作を元に戻します。For each transaction that was active as of the time of the crash, traverses the log backwards, undoing the operations that this transaction performed.

この設計では、SQL Server データベース エンジンが予期しない再起動から復旧するのにかかる時間は、クラッシュの発生時にシステム内でアクティブ時間が最も長かったトランザクションのサイズに (ほぼ) 比例します。Based on this design, the time it takes the SQL Server database engine to recover from an unexpected restart is (roughly) proportional to the size of the longest active transaction in the system at the time of the crash. 復旧するには、不完全なトランザクションをすべてロールバックする必要があります。Recovery requires a rollback of all incomplete transactions. 必要となる時間の長さは、トランザクションによって実行された作業の量と、トランザクションがアクティブになっている時間の長さに比例します。The length of time required is proportional to the work that the transaction has performed and the time it has been active. そのため、実行時間の長いトランザクション (大規模な一括挿入操作や、サイズの大きなテーブルに対するインデックス作成操作など) がある場合、復旧プロセスが長時間になる可能性があります。Therefore, the recovery process can take a long time in the presence of long-running transactions (such as large bulk insert operations or index build operations against a large table).

また、この設計では、先に述べたのと同じ元に戻す復旧フェーズが使用されるため、大規模なトランザクションを取り消したりロールバックしたりする際にも、長い時間がかかることがあります。Also, cancelling/rolling back a large transaction based on this design can also take a long time as it is using the same Undo recovery phase as described above.

さらに、SQL Server データベース エンジンでは、復旧とロールバック プロセスのために、対応するログ レコードが必要となるため、実行時間の長いトランザクションがある場合に、トランザクション ログを切り捨てることができません。In addition, the SQL Server database engine cannot truncate the transaction log when there are long-running transactions because their corresponding log records are needed for the recovery and rollback processes. SQL Server データベース エンジンがこのように設計されているため、以前は一部のお客様で、トランザクション ログのサイズが非常に大きくなり、膨大な量のドライブ領域が消費される問題が発生しました。As a result of this design of the SQL Server database engine, some customers used to face the problem that the size of the transaction log grows very large and consumes huge amounts of drive space.

高速データベース復旧のプロセスThe Accelerated Database Recovery process

ADR では、SQL Server データベース エンジンの復旧プロセスを以下のように根本から再設計することで、上記の問題に対処しています。ADR addresses the above issues by completely redesigning the SQL Server database engine recovery process to:

  • 最も古いアクティブ トランザクションの先頭を基点にログをスキャンする必要性をなくすことで、所要時間を一定化し、高速化を実現しています。Make it constant time/instant by avoiding having to scan the log from/to the beginning of the oldest active transaction. ADR では、最後に成功したチェックポイント (または最も古いダーティ ページのログ シーケンス番号 (LSN)) を基点に、それ以降のトランザクション ログだけを処理します。With ADR, the transaction log is only processed from the last successful checkpoint (or oldest dirty page Log Sequence Number (LSN)). そのため、実行時間の長いトランザクションによって復旧時間が影響を受けることはありません。As a result, recovery time is not impacted by long running transactions.
  • トランザクション全体のログを処理する必要がなくなるので、必要なトランザクション ログ領域が最小限に抑えられます。Minimize the required transaction log space since there is no longer a need to process the log for the whole transaction. そのため、チェックポイントやバックアップごとにトランザクション ログを積極的に切り捨てることができます。As a result, the transaction log can be truncated aggressively as checkpoints and backups occur.

要するに、ADR では、物理的なデータベース変更をすべてバージョン管理し、論理的な操作だけを元に戻すようにすることで、処理の対象を減らし、瞬間的な処理を可能にして、高速なデータベース復旧を実現しているのです。At a high level, ADR achieves fast database recovery by versioning all physical database modifications and only undoing logical operations, which are limited and can be undone almost instantly. クラッシュが発生した時点でアクティブだったトランザクションは中止としてマークされるため、それらのトランザクションによって生成されたバージョンはすべて、同時ユーザー クエリで無視できます。Any transaction that was active as of the time of a crash are marked as aborted and, therefore, any versions generated by these transactions can be ignored by concurrent user queries.

ADR 復旧プロセスには、現行の復旧プロセスと同じく 3 つのフェーズがあります。The ADR recovery process has the same three phases as the current recovery process. 次の図とその後の記述は、それらのフェーズが ADR でどのように動作するかについて詳しく説明したものです。How these phases operate with ADR is illustrated in the following diagram and explained in more detail following the diagram.

ADR の復旧プロセス

  • 分析フェーズAnalysis phase

    プロセスは以前と同じままで、sLog を再構築し、バージョン管理されない操作のログ レコードがコピーされるという処理が追加されています。The process remains the same as before with the addition of reconstructing sLog and copying log records for non-versioned operations.

  • 再実行フェーズRedo phase

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

    • フェーズ 1Phase 1

      sLog から再実行します (最も古い未コミット トランザクションから最後のチェックポイントまで)。Redo from sLog (oldest uncommitted transaction up to last checkpoint). sLog から数個のレコードを処理するだけで済むので、再実行操作は迅速に完了します。Redo is a fast operation as it only needs to process a few records from the sLog.

    • フェーズ 2Phase 2

      トランザクション ログからの再実行は、(最も古い未コミット トランザクションではなく) 最後のチェックポイントから開始されますRedo from Transaction Log starts from last checkpoint (instead of oldest uncommitted transaction)

  • 元に戻すフェーズUndo phase

    ADR では、sLog を使用してバージョン管理のない操作を元に戻し、永続バージョン ストア (PVS) と論理復元によってバージョンベースの Undo 処理を行レベルで実行できるため、元に戻すフェーズをほぼ瞬時に完了できます。The Undo phase with ADR completes almost instantaneously by using sLog to undo non-versioned operations and Persisted Version Store (PVS) with Logical Revert to perform row level version-based Undo.

ADR 復旧コンポーネントADR recovery components

ADR には次の 4 つの主要コンポーネントがあります。The four key components of ADR are:

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

    永続バージョン ストアは、データベース自体で生成された行バージョンを保持するための新しい SQL Server データベース エンジン メカニズムであり、従来の tempdb バージョン ストアに代わるものです。The persisted version store is a new SQL Server database engine mechanism for persisting the row versions generated in the database itself instead of the traditional tempdb version store. PVS を使用すると、リソース分離が可能になり、読み取り可能なセカンダリの可用性が向上します。PVS enables resource isolation as well as improves availability of readable secondaries.

  • 論理的に元に戻すLogical revert

    論理復元は、バージョン ベースの復元を行レベルで実行するための非同期プロセスです。トランザクションのロールバックを瞬時に実行し、バージョン管理されているすべての操作を元に戻すことができます。Logical revert is the asynchronous process responsible for performing row-level version-based Undo - providing instant transaction rollback and undo for all versioned operations. 論理復元は、次の方法で行われます。Logical revert is accomplished by:

    • 中止されたすべてのトランザクションを追跡し、それらを他のトランザクションから参照できなくします。Keeping track of all aborted transactions and marking them invisible to other transactions.
    • トランザクション ログを物理的にスキャンして変更を一度に 1 つずつ元に戻すのではなく、すべてのユーザー トランザクションに対して PVS を使用してロールバックを実行します。Performing rollback by using PVS for all user transactions, rather than physically scanning the transaction log and undoing changes one at a time.
    • トランザクションの中止直後にすべてのロックを解除します。Releasing all locks immediately after transaction abort. 中止はメモリ内の変更をマークするだけなので、プロセスは非常に効率的です。そのため、ロックを長時間保持する必要がありません。Since abort involves simply marking changes in memory, the process is very efficient and therefore locks do not have to be held for a long time.
  • sLogsLog

    sLog は、バージョン管理されない操作 (メタデータ キャッシュの無効化やロックの取得など) のログ レコードを格納するメモリ内ログ ストリームのセカンダリです。sLog is a secondary in-memory log stream that stores log records for non-versioned operations (such as metadata cache invalidation, lock acquisitions, and so on). sLog には次の特徴があります。The sLog is:

    • ボリュームが少なく、メモリ内に収められるLow volume and in-memory
    • チェックポイント プロセス中にシリアル化され、ディスクに永続化されるPersisted on disk by being serialized during the checkpoint process
    • トランザクションのコミットに合わせて定期的に切り捨てられるPeriodically truncated as transactions commit
    • バージョン管理されていない操作のみを処理することでやり直し操作と元に戻す操作を高速にするAccelerates redo and undo by processing only the non-versioned operations
    • 必須のログ レコードのみを保持することでトランザクション ログの積極的な切り捨てを可能にするEnables aggressive transaction log truncation by preserving only the required log records
  • クリーナーCleaner

    クリーナーは、定期的に起動し、不要なページ バージョンを消去する非同期プロセスです。The cleaner is the asynchronous process that wakes up periodically and cleans page versions that are not needed.

高速データベース復旧パターンAccelerated Database Recovery Patterns

以下の種類のワークロードについては、ADR のメリットが最も活かされます。The following types of workloads benefit most from ADR:

  • 実行時間の長いトランザクションが含まれるワークロード。Workloads with long-running transactions.
  • アクティブなトランザクションが原因となって、トランザクション ログが大幅に拡大している状況が見られたワークロード。Workloads that have seen cases where active transactions are causing the transaction log to grow significantly.
  • (予期しない再起動やトランザクションの手動ロールバックなどで) 復旧時間が長いために、データベースを長時間使用できなくなったことがあるワークロード。Workloads that have experienced long periods of database unavailability due to long running recovery (such as unexpected service restart or manual transaction rollback).