高速データベース復旧 (ADR) の動作を把握するために必要となる情報 at SE の雑記

SQL Server 2019 以降と Azure SQL Database では、データベースの高速な復旧を可能とする高速データベース復旧 (ADR : Accelerated Database Recovery / CTR : Constant Time Recovery) という機能が搭載されています。

SQL Server 2019 では手動で有効化する必要がありますが、現在の Azure SQL Database ではデフォルトで有効化されており、無効にすることはできませんので、SQL Database を使用している場合には、必ず ADR が使用されています。

この ADR の挙動を把握する必要があり、情報を調査した際の内容をまとめておこうと思います。

Contents

1 公式ドキュメント
2 ADR についての公開記事
3 ADR の挙動を把握する際のポイント

公式ドキュメント

ADR の公式ドキュメントは次の情報になります。

ADR の基本的な動作については、この情報から把握する必要があります。

ADR については、サーバー構成オプションがありますので、これも公式ドキュメントに含まれるかと。

基本的な動作については上記のドキュメントで確認することができるのですが、詳細な動作を把握する必要になった場合はこれだけでは情報が不足しています。

ADR については、Constant Time Recovery : CTR として Microsoft Research から論文が公開されています。

Constant Time Recovery in Azure SQL Database

この論文の内容から詳細な情報を確認することができますので、詳細な動作の確認が必要となった場合は論文を参照しましょう。

Microsoft から提供されている情報から ADR の挙動を把握する場合は、これらの情報から確認を行います。

ADR についての公開記事

ADR の挙動を確認する際には、「どのようにして ADR の挙動を確認するか」が重要となりますが、公式ドキュメントは実際に手を動かして確認した内容になっていないため、公式外のドキュメントの確認も重要となります。

ADR について記載された記事については、次の内容がとても参考になりました。

実際に手を動かして ADR の挙動を確認する場合にはこれらの記事の内容がとても参考になります。

ADR の挙動を把握する際のポイント

基本動作

ADR の挙動を把握するためにはいくつかのポイントがあります。

ADR はデータベースの高速な復旧を可能とするために、次のような動作が行われます。

通常のトランザクションログには従来と同じように書き込みが行われる
データの変更は永続化バージョンストア (Persisted Version Store : PVS) として、ユーザーデータベースのファイルに保存される
トランザクションのタイムスタンプに応じて、実データ / PVS 内のどちらのデータを確認すればよいかが判断される
バージョン管理されない操作については、sLog (Secondary Log / Secondary Log Stream) に格納され、ADR による復旧に必要なログレコードのみが格納される
、不要なトランザクションとなった PVS のデータについてはバックグラウンドタスクである PVS Cleaner (Command = PERSISTED_VERSION_CLEANER) によって削除

これらの動作が行われることを意識しておくと、PVS の挙動を把握する際の理解が深まります。

論文を読むと、PFS にバージョン情報が含まれていることが理解できたりもしますので、論文を読んでみることも重要です。

用語

ADR を理解するためにはいくつかの用語を中心に情報の収集を行う必要があります。ポイントとなる用語には次のようなものがあります。

Accelerated Database Recovery : ADR
Constant Time Recovery : CTR

ADR を実現するために、一定時間で Recovery を行うことをさしますが、ADR / CTR を合わせて検索することで集まる情報の幅が広がります。

Persistent Version Store : PVS
sLog : Secondary Log / Secondary Log Stream
Persisted Version Cleaner : PVS Cleaner
Aborted Transaction Map : ATM
In-row Version Store
Off-row Version Store

各用語の説明については、高速データベース復旧に記載されているのですが、Aborted Transaction Map (ATM) / ATM / In-row Version Store / Off-row Versoin Store については、ドキュメントには記載が行われていません。
そのため、これらの用語については、Constant Time Recovery in Azure SQL Database の論文から確認する必要があります。

ATM

ATM は中止されたトランザクションの情報を確認するためのハッシュテーブルとなります。PVS はトランザクションのバージョンごとにデータの状態を保持しますが、中止されたトランザクションのバージョンについては、有効なデータではないため、アクセスをスキップさせる必要があります。

アクセスをスキップさせるために、ATM に中止されたトランザクションの情報を格納し、該当のトランザクションのバージョンについては、中止されたトランザクションであるということを認識できるようになっています。

In-row Version Store / Off-row Version Store

PVS はトランザクションのバージョンごとに行データを保存しておくものとなりますが、保存の方法には行内 / 行外の 2 種類の方法があります。

In-row Version Store はバージョンストアの情報を、行内データとして、該当行のスロット内に格納を行います。

Off-row Version Store はバージョンストアの情報を、行外データとして、実データの行ではなく、sys.persistent_version_store というシステムテーブルにバージョンストアの情報を格納する方式となります。

ADR の状態を確認するための情報

ADR の状態を確認するためににはいくつかの情報を使用することができます。

動的管理ビュー / システムテーブル

DMV 等の情報については、次のような内容が使用できます。
SQL Database の場合は、参照可能な情報が制限されているためすべての情報を確認することはできませんので、SQL Server 2019 で挙動を把握してから SQL Database で情報を確認したほうが良いかもしれませんね。

DMV としては次のようなものが使用できます。

sys.dm_tran_persistent_version_store

PVS に格納されている情報を参照可能
DAC (Dedicated Admin Connection : 専用管理者接続) が使用できる場合は sys.persistent_version_store 伝参照可能

sys.dm_tran_persistent_version_store_stats

PVS の使用状況を参照することができる
SQL Database でもこの DMV は参照可能
活用方法はトラブルシューティングに記載されている

DAC で接続した場合に、確認できるシステムテーブルについては、次の 2 種類があります。

sys.persistent_version_store

sys.dm_tran_persistent_version_store で確認できる情報の元

sys.persistent_version_store_long_term

DMV / システムテーブルともに現時点では、個別のドキュメントが用意されていないため、検証をしながらどのようなデータが格納されているのかを確認する必要があります。

既存の DMV についても拡張がされており、インデックスの断片化情報を確認するための sys.dm_db_index_physical_stats (Transact-sql) が拡張されています。

PVS の格納状況を確認するための情報が追加されており、in-row / off-row がどの程度格納されているか確認することができます。

パフォーマンスモニター

SQLServer:Databases のオブジェクトに PVS 向けの項目が追加されています。

SQL Server の Databases オブジェクト

PVS の生成状況や解放状況については、パフォーマンスモニターから確認することができます。

拡張イベント

PVS 用の拡張イベントが追加されており、PVS の操作状況は拡張イベントから確認することができます。
PVS の割り当ての状況の詳細を確認したい場合などは、拡張イベントを活用します。

バックグラウンドタスク

PVS のバックグラウンドタスクとしては PVS Cleaner がありますが、PVS Cleaner は常駐型のタスクではなく、非同期に起動されるジョブとなっており、起動しているタイミングであれば、次のクエリで情報を取得することができます。

select * from sys.dm_exec_requests where command = 'PERSISTED_VERSION_CLEANER'

通常、PVS Cleaner は長時間実行されるタスクではありませんが、PVS が肥大化している場合は、command が「PERSISTED_VERSION_CLEANER」となっているバックグラウンドタスクが長時間動作している状態となります。

通常、Cleaner は瞬間的な動作のみとなりますので、sys.dm_exec_requests でタスクが取得できる場合は、PVS の削除が想定通り動作しておらず、PVS の肥大化が発生している可能性を疑う必要があります。

長時間トランザクションの確認

PVS もバージョンストアの一種となり、削除可能なバージョンストアは完了しているトランザクションが対象となります。

そのため、長時間実行されているトランザクションが存在している場合は、PVS のクリーンアップが完了せず、PVS が肥大化していきます。

SQL Server の Transactions オブジェクトの Longest Transaction Running Time から、長時間実行されているトランザクションが存在するかを確認することができます。

このカウンターが大きい値を示している場合には、長時間実行されているトランザクションによって PVS のクリーンアップが阻害されている可能性を検討する必要があります。

AlwaysOn 可用性グループ / Geo レプリケーション等を使用している場合、セカンダリ側で長時間実行されているトランザクションが存在している場合は、セカンダリ側のトランザクションにより、プライマリの PVS のクリーンアップが阻害される可能性がありますので、PVS については、セカンダリも含めて関連する環境のトランザクションを意識しておく必要があります。

今回、ADR の挙動を把握するために操作した内容については、https://github.com/MasayukiOzawa/SQLServer-Util/blob/master/ADR%EF%BC%88CTR)/ADR%20Sample.sql に残してありますのでこちらの情報も参考になれば幸いです。

ADR を把握するためにはこのような情報を把握する必要があるのではないでしょうか。

SE の雑記