SE の雑記

SQL Database / SQL Server 2019 では、Accelerated Database Recovery (ADR : 高速データベース復旧) という機能が追加されています。

• 復元と復旧の概要 (SQL Server)
• 高速データベース復旧

この機能は、予測可能な一定時間でのデータベースの回復 (Constant Time Recovery : CTR) を実現するために実装されたものであり、次のようなことを実現することができるようになります。

• 大量のトランザクションのロールバックの高速化
• SQL Server サービス起動時のデータベース復旧の高速化
• トランザクションログの積極的な切り捨て

ADR を実現するために、SQL Server では新しく次のような概念が入っています。

• Persistent Version Store (永続化バージョンボリュームストア) : PVS
• Secondary Log Stream : sLog

この中の PVS について、調べる機会がありましたので、調べた内容をまとめておきたいと思います。
ADR の詳細については、Accelerated Database Recovery in SQL Server 2019 か、Microsoft が公開している論文の Constant Time Recovery in Azure SQL Database で解説されています。
(論文の方はまだ半分ぐらいまでしか読めておらず…)

ADR とは？

まず、ADR とは何かについて触れておこうと思います。
ADR の基本的な概念については、冒頭で紹介した 高速データベース復旧 に記載されています。
従来の SQL Server では、ロールバック時のデータベースの復旧は ARIES 復旧モデルに基づいた処理が行われているとされています。
データベースの復旧は、次のような流れで実装されています。

トランザクションをロールバックする必要が発生した場合、どのトランザクションまでを復旧すれば良いかの分析フェーズを実行し、トランザクションログの内容を Redo / Undo することで復旧を行うという流れとなります。
簡単に書いてしまいますと、変更の内容をログレコードから読み取り、ロールバックまでに実行された変更内容を取り消していくというようなものとなります。

BEGIN TRAN
UPDATE T9 SET C3 = NEWID(), C2=NEWID() WHERE C1 = 205
ROLLBACK TRAN

 
この時、トランザクションログには、次のような内容が記録されます。

• 13 : BEGIN TRAN
• 14 : UPDATE による行の変更
• 15 : ROLLBACK による行の変更の取り消し
• 16 : ROLLBACK の完了

ロールバック時には、変更されたデータに対して変更内容の取り消しを実施していくため、トランザクションによって影響を受けた行数が多いほど、復旧に時間がかかることになります。
この問題を解決するためのチャレンジとして、SQL Database と SQL Server 2019 では  ADR という高速に復旧を行う機能が、新しく導入されました。
ADR ではデータベース復旧の流れが次のようになります。

ADR により高速に復旧を可能にするために、従来のトランザクションログの他に、二つの新しい領域が使用されています。
一つが「sLog」 となります。

これは後述の PVS では管理していない、バージョン管理の対象ではない操作 (スキーマの変更等) のみを記録した、領域となります。

トランザクションログから、上述のバージョン管理対象ではない操作のみを切り出したログと考えてもよいかもしれません。
sLog だけでは、「データがどのような状態から変更されたか」は管理できていません。

データ変更の状態を管理する (バージョン管理された行バージョン) ために使用されるのが、本投稿でメインとなる「Persistent Version Store : PVS」となります。
ADR では sLog と PVS の情報を使用することで、高速なデータベースの復旧を実現しています。

バージョン管理されたデータを使用することで、トランザクションログから行に対しての操作をロールバックするのではなく、行のバージョンを活用することで高速にデータベースの復旧が行われます。
 

Persistent Version Store : PVS

従来から、SQL Server では、スナップショット (スナップショット分離 : SI / READ COMMITTED SNAPSHOT ISOLATION : RCSI) を使用した際の「Multi Version Concurrency Control : MVCC」として「行のバージョン管理」が採用されていました。

• SQL Server トランザクションのロックおよび行のバージョン管理ガイド

データの変更が行われた際に、各トランザクション / セッションが適切なバージョンのデータを参照することで読み取り一貫性を持たせるため、行のバージョン管理が行われています。
データの変更が行われると、ページ内容が次のようになります。

現在、ページ内に格納されているデータは「変更後」のデータとなるのですが、読み取り一貫性を保つため、変更後のデータについては「tempb」に格納が行われます。

tempdb に格納されている情報が次の内容となります。

変更前の情報が、tempdb に格納されており、トランザクションのタイムスタンプに応じて、どのデータを読めばよいのかを切り替えることで、適切な状態のデータが読み込まれます。
これが従来から導入されている行バージョンの実装となっています。
この行のバージョンについては「読み取り一貫性」のためのバージョン管理となっています。

データは tempdb に格納されているため、SQL Server のサービスが再起動することでデータが初期化されてしまいますので、高速にデータベースを復旧するという用途ではありませんでした。
今回の Persistent Version Store は行バージョンが、tempdb ではなく「ユーザーデータベース」に格納されます。

ユーザーデータベースのデータについては SQL Server のサービスが再起動しても永続化されていますので、サービス再起動による影響を受けることなく、復旧に使用することができます。
Persistent Version Store には、大きく分けて 2 つの種類があります。

• In-row Version Store
• 変更対象の行を含むページ内に行バージョンが記録される
• Off-row Version Store
• PVS テーブルに行バージョンが格納される

変更されるデータのサイズやページの状況に応じて、どちらが使用されるのかは変わってくるのですが、基本的な考え方としては「高速なデータ復旧を実現するための行のバージョンが保持される」ということです。
先ほどと同様の変更を実行して、行の状態を確認してみます。
読み取り一貫性のための行バージョンについては、tempdb に格納されており、変更前の情報を確認するためには tempdb 内の情報を確認する必要がありました。
Persistent Version Store については、ユーザーデータベース内に格納されている物足りますので、バージョン管理されている行にアクセスすると

• 変更後のデータ : 赤枠
• 変更前のデータ : 青枠

というようなデータの取得ができていることが確認できます。
このデータが In-row Version なのか、Off-row Version なのかですが、ADR に対応している SQL Server では、sys.dm_db_index_physical_stats が拡張されており、どちらの Version Store がどの程度利用されているかを確認することができるようになっています。
DETAILED で情報を取得すると、Persistent Version Store の情報が取得できるように拡張されています。

今回のデータであれば、inrow_diff_version_record として、変更があったデータのみがページ内に In-Row として格納されていることが確認できます。
PVS 対応として、このほかにも取得できる情報の拡張が行われています。
DMV としては、次のようなものがと追加されており、PVS の使用状況は Off-Row のデータについての確認ができます。

• sys.dm_tran_persistent_version_store
• sys.dm_tran_persistent_version_store_stats

他にもページ情報のフラグとして「VERSION_INFO」の追加が行われていたり、

拡張イベントにもいくつかの PVS 対応の情報が追加されており、これらの情報を使用することで理解を深めることができるようになっています。

PVS については、バックグラウンドでクリーナーが 1 分程度の間隔で動作しているようで、クリーナーの動作状況については「sys.dm_tran_persistent_version_store_stats」から確認をすることができます。
Research Paper Week: Constant Time Recovery in Azure SQL DB でも触れられていますが、動作的にはかなり大き目な動作の変更となっており、論文ではパフォーマンスについても触れられています。
現時点では、論文を読み込めているわけではないので理解が薄い部分も多々ありますが、機能としては面白いものですので、今後も情報をキャッチアップしていければと思います。