高速データベース復旧の管理

[アーティクル]
04/26/2023

適用対象: SQL Server 2019 (15.x)

この記事には、SQL Server 2019 (15.x) 以降の高速データベース復旧 (ADR) を管理および構成するためのベストプラクティスに関する情報が含まれています。 Azure SQL の ADR の詳細については、「Azure SQL での高速データベース復旧」を参照してください。

Note

Azure SQL Database と Azure SQL Managed Instance では、高速データベース復旧 (ADR) はすべてのデータベースで有効になっており、無効にすることはできません。ストレージの使用、トランザクションの中止の多発、その他の要因で問題が発生する場合は、「高速データベース復旧のトラブルシューティング」を参照するか、Azure サポートにお問い合わせください。

データベース復旧の高速化を考慮すべきユーザー

多くのお客様は、高速データベース復旧 (ADR) が復旧時間を短縮する価値あるテクノロジであると考えています。どのデータベースに ADR を使うかを決定する前に、次の要因の積み重ねを検討し、それによって ADR の使用に有利になるか不利になるかを評価する必要があります。

回避できず、実行時間の長いトランザクションがあるワークロードには、ADR を使うことをお勧めします。たとえば、実行時間の長いトランザクションがロールバックされるリスクがある場合、ADR が役立ちます。
アクティブなトランザクションが原因でトランザクションログが大幅に拡大したことがあるワークロードには、ADR が推奨されます。
(予期しない SQL Server の再起動やトランザクションの手動ロールバックなどで) SQL Server の復旧時間が長いために、データベースを長時間使用できなくなったことがあるワークロードには、ADR をお勧めします。
ADR は、データベースミラーリングに登録されているデータベースではサポートされていません。
シングルスレッドの永続バージョンストア (PVS) バージョンクリーナーのため、ADR は 100 テラバイトを超えるデータベースには推奨されません。
行のアクセス/挿入があるたびにレコードを更新するような、非バッチの増分更新を多数実行するアプリケーションの場合、ワークロードが ADR に適していない可能性があります。可能であれば、アプリケーションのクエリを書き換えて、コマンドの最後までの更新をバッチ処理し、多数の小さな更新トランザクションを削減することを検討してください。

ワークロードが ADR に適しているかどうかを評価する

ワークロードで ADR を有効にしたら、永続バージョンストア (PVS) が追いついていない兆候があるかどうかに注意します。「高速データベース復旧のトラブルシューティング」に記載されている方法を使って、ADR の正常性を監視することをお勧めします。

ADR は、大量の OLTP など、更新や削除の回数が多く、PVS クリーンアッププロセスで領域を再利用するための保存/復旧期間がないデータベース環境の場合は推奨されません。通常、ビジネス運用サイクルではこの時間を確保できますが、シナリオによっては、アプリケーションのアクティビティ状況を考慮して、PVS クリーンアッププロセスを手動で開始することが必要になる場合もあります。

PVS クリーンアッププロセスが実行時間が長いと、中断されたトランザクションの数が増え、PVS サイズが増加することがあります。中止されたトランザクション数を報告するために sys.dm_tran_aborted_transactions DMV を使用し、PVS サイズと共にクリーンアップの開始/終了時刻を報告するために sys.dm_tran_persistent_version_store_stats を使用します。詳細については、「sys.dm_tran_persistent_version_store_stats」を参照してください。
ワークロードの間またはメンテナンス期間中に PVS クリーンアッププロセスを手動でアクティブにするには、sys.sp_persistent_version_cleanup を使います。詳しくは、「sys.sp_persistent_version_cleanup」をご覧ください。
SNAPSHOT または READ COMMITTED SNAPSHOT 分離モードで実行時間の長いクエリを中心としたワークロードでは、他のデータベースでの ADR PVS クリーンアップが遅れ、PVS ファイルが拡張される可能性があります。詳細については、「高速データベース復旧のトラブルシューティング」の「長時間にわたってアクティブなスナップショットスキャン」セクションを参照してください。これは、SQL Server と Azure SQL Managed Instance のインスタンス、または Azure SQL Database Elastic Pool 内のインスタンスに適用されます。

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

このセクションでは、ADR に関するガイダンスと推奨事項について説明します。

SQL Server の場合、PVS バージョンストアをハイエンド SSD やアドバンスト SSD、またはストレージクラスメモリ (SCM) と呼ばれることもある永続メモリ (PMEM) など、上位レベルのストレージ上のファイルグループに分離します。詳細については、PVS の場所を別のファイルグループに変更するに関する記事を参照してください。このオプションは Azure SQL Database と Azure SQL Managed Instance では使用できません。
PVS の使用量を考慮して、データベースに十分な領域があることを確認します。データベースに PVS を拡大するのに十分な空き領域がない場合、ADR はバージョンの生成に失敗します。 ADR は tempdb バージョンストアと比較して、バージョンストアの領域を節約します。
データベースで複数のトランザクションが長時間実行されないようにします。 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)」をご覧ください。

ADR の有効化と制御

Note

Azure SQL Database と Azure SQL Managed Instance では、高速データベース復旧 (ADR) はすべてのデータベースで有効になっており、無効にしたり、別のファイルグループに移動したりすることはできません。

SQL Server 2019 (15.x) では ADR は既定でオフになっており、DDL 構文を使用して制御できます。

ALTER DATABASE [DB] SET ACCELERATED_DATABASE_RECOVERY = {ON | OFF};

この構文を使用してこの機能のオン/オフを制御し、永続的なバージョンストア (PVS) データに特定のファイルグループを指定します。ファイルグループが指定されていない場合、PVS はプライマリファイルグループに格納されます。

この状態を変更するには、データベースの排他的ロックが必要です。つまり、ALTER DATABASE コマンドはすべてのアクティブなセッションが終了するまで停止し、新しいセッションは ALTER DATABASE コマンドが終了するまで待機します。操作を完了してロックを解除することが重要な場合は、終了句 WITH ROLLBACK [IMMEDIATE | AFTER {number} SECONDS | NO_WAIT] を使って、データベース内のすべてのアクティブなセッションを中止できます。詳細については、「ALTER DATABASE SET オプション」を参照してください。

永続バージョンストアファイルグループの管理

ADR 機能は変更をバージョン管理することを基盤としており、さまざまなバージョンのデータ要素が PVS に保管されます。 PVS の場所の見つけ方と PVS に含まれるデータサイズの管理方法には注意点があります。

ファイルグループを指定せずに ADR を有効にするには

この操作には、データベースへの排他アクセスが必要です。

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = ON;
GO

この場合、PVS ファイルグループが指定されていないとき、PRIMARY ファイルグループで PVS データが保持されます。

ADR を有効にし、PVS をファイルグループに格納するように指定するには

既定の PRIMARY ファイルグループ以外の別のファイルグループを使用して PVS データを保持するように ADR を構成できます。

PRIMARY 以外のファイルグループで ADR を有効にする前に、ファイルグループとデータファイルを作成する必要があります。

VersionStoreFG ファイルグループを作成し、そのファイルグループに新しいデータファイルを作成します。次に例を示します。

ALTER DATABASE [MyDatabase] ADD FILEGROUP [VersionStoreFG];
GO
ALTER DATABASE [MyDatabase] ADD FILE ( NAME = N'VersionStoreFG'
, FILENAME = N'E:\DATA\VersionStore.ndf'
, SIZE = 8192KB , FILEGROWTH = 65536KB )
TO FILEGROUP [VersionStoreFG];
GO

ファイルグループとセカンダリデータファイルが作成された後にのみ、ADR を有効にし、PVS を特定のファイルグループに格納するように指定します。この操作には、データベースへの排他アクセスが必要です。

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = ON
(PERSISTENT_VERSION_STORE_FILEGROUP = [VersionStoreFG]);

ADR 機能を無効にするには

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = OFF;
GO

ADR 機能が無効になった後でも、論理的に元に戻すときに必要となる永続的なバージョンストアにバージョンが格納されます。

PVS の場所を別のファイルグループに変更する

SQL Server では、さまざまな理由から、PVS の場所を別のファイルグループに移さなければならないことがあります。たとえば、PVS でもっとたくさんの領域が必要になったり、高速のストレージが必要になったりすることがあります。

PVS の場所の変更は、3 つの手順からなるプロセスです。

ADR 機能をオフにします。

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = OFF;
GO

PVS に格納されているすべてのバージョンを解放できるようになるまで待ちます。

ADR をオンにし、永続的なバージョンストアに新しい場所を指定するには、まず、PVS の前の場所からバージョン情報がすべて削除されていることを確認する必要があります。その消去を強制するには、次のコマンドを実行します。
```
EXEC sys.sp_persistent_version_cleanup [database name];
```
sys.sp_persistent_version_cleanup ストアドプロシージャは同期型です。つまり、現行の PVS からすべてのバージョン情報が消去されるまで完了となりません。完了したら、DMV sys.dm_tran_persistent_version_store_stats を問い合わせ、persistent_version_store_size_kb の値を調べることでバージョン情報が確かに削除されていることを確認できます。
```
SELECT DB_Name(database_id), persistent_version_store_size_kb 
FROM sys.dm_tran_persistent_version_store_stats where database_id = [MyDatabaseID];
```
persistent_version_store_size_kb の値が 0 のとき、ADR 機能を再度有効にし、PVS を新しいファイルグループに置くように構成できます。

PVS の新しい場所を指定して ADR をオンにします。

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = ON
(PERSISTENT_VERSION_STORE_FILEGROUP = [VersionStoreFG]);

次の方法で共有

高速データベース復旧の管理

データベース復旧の高速化を考慮すべきユーザー

ワークロードが ADR に適しているかどうかを評価する

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

ADR の有効化と制御

永続バージョンストアファイルグループの管理

ファイルグループを指定せずに ADR を有効にするには

ADR を有効にし、PVS をファイルグループに格納するように指定するには

ADR 機能を無効にするには

PVS の場所を別のファイルグループに変更する

次のステップ

フィードバック

その他のリソース

次の方法で共有

高速データベース復旧の管理

データベース復旧の高速化を考慮すべきユーザー

ワークロードが ADR に適しているかどうかを評価する

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

ADR の有効化と制御

永続バージョン ストア ファイル グループの管理

ファイルグループを指定せずに ADR を有効にするには

ADR を有効にし、PVS をファイル グループに格納するように指定するには

ADR 機能を無効にするには

PVS の場所を別のファイルグループに変更する

次のステップ

フィードバック

その他のリソース

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

永続バージョンストアファイルグループの管理

ADR を有効にし、PVS をファイルグループに格納するように指定するには