SE の雑記

SQL Database では先行して実装されていた高速データベース復旧 (Accelerated Database Recovery : ADR) が、SQL Server では、2019 CTP 2.3 から使用可能となりました。
昨年の 10 月ぐらいからドキュメントは公開されていたのですが、情報を調べられていなかったので、今回の機会に調べてみました。
公式の情報としては次の内容となります。

• Accelerated Database Recovery (SQL Database 向け)

• Accelerated database recovery (SQL Server 2019 向け)

• Announcing Public Preview of Accelerated Database Recovery
• Constant Time Recovery in Azure SQL Database

ドキュメントの内容をもとに特徴をまとめると次のようになるのではないでしょうか。

1. 高速で一貫したデータベースの復旧

• • 長時間実行されているトランザクションが、全体のリカバリ時間に影響を与えることがなく、トランザクション数やサイズに依存することなく、高速で一貫性のあるデータベースリカバリーが可能となる
    → サーバー起動時の DB の復旧処理が高速化
• トランザクションのロールバックの実行を即時実行
  • トランザクションがアクティブであった時間や、実行された更新データ数に依存することなく、トランザクションのロールバックが瞬時に行われる
    → トランザクションのロールバック実行時の復旧処理が高速化
• 積極的なトランザクションログの切り捨て
  • 長時間アクティブな状態のトランザクションが存在する場合でも、トランザクションログを積極的に切り捨てることができる
    → トランザクションログの再利用性の向上

仕組みとしては、上述のドキュメントに記載されている次の内容となります。

 

 
ADR 用に新しく次の 2 つの領域が追加されており、ADR ではこの追加された領域が活用されます。

• 永続化バージョンストア : Persistent Version Store : PVS
• セカンダリ インメモリ ログストリーム : sLog

ドキュメントだけですと、実際にどの程度実運用時の処理時間が変わるのかが判断しずらいのですが、SQLBits で実施されていたワークショップのコンテンツが公開されており、このコンテンツのデモを実施すると理解度が深まります。

• Workshop: Modernize Your Database with SQL Server 2019

このリポジトリの中では、SQL Server 2019 の各種機能が解説されており、Module 4 Activities – Mission Critical Availability に ADR のデモコンテンツが含まれています。
このデモで作成されている「gocowboys」のデータを元に、ADR の有無による次の 2 つのパターンの動作の違いを見ていきたいと思います。

• トランザクションのロールバックの実行を即時実行
• 積極的なトランザクションログの切り捨て

今回使用しているクエリについては ADR Demo.sql で公開しています。
ADR は、DB 単位で有効にする必要があり、「ALTER DATABASE gocowboys SET ACCELERATED_DATABASE_RECOVERY = {ON | OFF}」で切り替えができますので、動作の確認状況に合わせて変更してください。
最初に ADR が無効な状態 (OFF) で動作を確認したいと思います。
最初に、gist に公開している ADR Demo.sql を実行します。
このクエリは、実行の途中で、Wait するようにしていますので、待機中に別のウィンドウで、gist 内の Log Truncate.sql を実行します。
待機に入ると、メッセージとして「Wait….」が出力されますので、このメッセージで Log Truncate.sql の実行タイミングを判断してください。
この結果を ADR の OFF /ON の 2 パターンで取得して、各情報を比較してみましょう
Info #1

ADR : 無効	ADR : 有効

ADR を有効にすることで、削除の処理時間が短くなっています。
トランザクションログの書き込みの動作が変わってくる影響だと思いますが、トランザクション内の処理時間についても多少改善する傾向があるのかもしれません。
Info #2

ADR : 無効	ADR : 有効

トランザクションログに書き込まれた内容を操作とコンテキストでグルーピングした情報になるのですが、トランザクションログに書き込まれるログレコードの内容が大きく変わっていることが確認できますね。
これは、次のトランザクションログの使用状況からも確認できます。
Info #3

ADR : 無効

ADR : 有効

ADR の有効 / 無効によってトランザクションログの使用状況も変わってきています。
無効の場合は、39% 程度、トランザクションログを使用していたのですが、有効の場合は、9.3% 程度の利用となっており、トランザクションログの書き込みが大幅に減っていることが確認できます。
ADR が有効な場合は、ユーザーデータベース内に存在している「永続化バージョンストア (PVS)」に情報を書き込んでいるためだと思いますが、トランザクションログの使用状況が ADR の状態によって大きく変わってきています。
(従来までのバージョンでも、リードコミットスナップショット分離レベルや、スナップショット分離でバージョンストアが存在しており、その情報は tempdb に格納されていましたが、PVS については tempdb ではなく、ユーザーデータベース内の領域として存在しています)
Info #4

ADR : 無効	ADR : 有効

トランザクションログのレコード数も ADR を有効にした場合は少ないですね。
この後に、Log Truncate.sql の実行を行っています。
このクエリは何をしているかというと「アクティブなトランザクションが存在している最中にトランザクションログのバックアップを実行」しているものとなります。
Info #5

ADR : 無効

ADR : 有効

従来までの ADR が無効な状態では、アクティブなトランザクションが存在している最中は、トランザクションログのバックアップを取得してもログの切り捨てを行うことができませんでした。
そのため、ログの再利用を阻害している理由が「ACTIVE_TRANSACTION」となっています。
ADR を有効にすることでこの動作が変わります。
ADR には「トランザクションログを積極的に切り捨てる」という特徴があり、これによりアクティブなトランザクションが存在している状態でもトランザクションログの切り捨てによる再利用が可能となります。
そのため、ログの再利用を阻害する要因はなく「NOTHING」となっていることが確認できます。
これは、次に取得している情報からも確認できます。
Info #6

ADR : 無効

ADR : 有効

ADR が無効な場合は、アクティブなトランザクションが存在している状態でトランザクションログのバックアップを実行してもトランザクションログが切り捨てられておらず、39% の使用状況はそのままでした。
しかし、ADR を有効にした場合は、9.3% だったトランザクションログの使用状況が 2.3 % まで減少しており、トランザクションログのレコード数も減少していることが確認できます。
このことから ADR を有効にすることで、アクティブなトランザクションが存在していても、トランザクションログのバックアップによりログの切り捨てが行われたことが確認できます。
Info #7

ADR : 無効	ADR : 有効

ロールバックの処理時間も大きく変わっています。
ADR が無効な場合は、1.9 秒ほど DELETE の処理内容をロールバックするのにかかっていますが、ADR が有効な場合は即時にロールバックが完了しています。
「トランザクションのロールバックの実行を即時実行」という ADR の効果が出ていますね。
Info #8
最後がデータベースのファイルのアクセス状況です。

ADR : 無効

ADR : 有効

ADR を有効にすることで、トランザクションログの書き込みは大幅に変わっていますね。
データファイルの書き込みについても、バイト数は減少しているようです。
単純な DELETE → ロールバック という流れの処理ですが、それぞれのタイミングで情報の取得を行うことで ADR によりどのような改善が行われるのかを見ることができたのではないでしょうか。
さらに踏み込んで情報を確認することもできるのですが、まだ理解度が低く情報を発信できるレベルに落とせていないので、今回はわかっている範囲で ADR についてまとめてみました。
「積極的なトランザクションログの切り捨て」については、もう少しいろいろなユースケースで動作を見ていきたいですね。