SQLServer2019でのデータベースリカバリの高速化

従来のリカバリの概要

すべてのリレーショナルデータベースシステムと同様に、SQL Serverはクラッシュリカバリを実装することにより、データの耐久性を保証します。リレーショナルデータベースのトランザクションの特性を表す頭字語ACIDの耐久性は、データベースに突然障害が発生した場合でも、データが安全であることを保証できることを意味します。

SQL Serverは、トランザクションログを使用してこの機能を実装します。 SQL Serverのすべてのデータ操作操作によって行われた変更は、ロールバックまたはロールフォワードが必要な場合に備えて、（チェックポイントプロセスを通じて）データファイルに適用される前にトランザクションログにキャプチャされます。

SQLServerの3フェーズのクラッシュリカバリプロセスは次のとおりです。

• 分析 – SQL Serverは、トランザクションログを最新のチェックポイントからトランザクションログの最後まで読み取ります

• やり直し – SQL Serverは、コミットされていない最も古いトランザクションからログの最後までログを再生します

• 元に戻す – SQL Serverは、ログの最後から最も古いコミットされていないトランザクションまでログを読み取り、クラッシュ中にアクティブだったすべてのトランザクションを元に戻します

経験豊富なDBAは、キャリアのある時点で、非常に大規模なデータベースでクラッシュリカバリが完了するのを無力に待つという落胆した経験をしていました。トランザクションROLLBACKは、クラッシュリカバリプロセスと同様のメカニズムを使用します。 Microsoftは、SQLServer2019のリカバリプロセスを大幅に強化しました。

データベースリカバリの高速化

Accelerated Database Recoveryは、バージョン管理に基づく新機能であり、ロールバックまたはクラッシュからの回復の場合に回復率を大幅に向上させます。

SQL Server 2019では、SQL Serverエンジン内の3つの新しいメカニズムにより、リカバリの処理方法が変更され、ロールバック/ロールフォワードの実行に必要な時間が効果的に短縮されます。

• 永続バージョンストア（PVS） –問題のデータベース内の行バージョンをキャプチャします。永続バージョンストアは、パフォーマンスまたはサイズの理由から、別のファイルグループで定義できます

• 論理復帰 – PVSに格納されている行バージョンを使用して、特定のトランザクションに対してロールバックが呼び出されたとき、またはクラッシュリカバリの元に戻すフェーズが呼び出されたときにロールバックを実行します。

• sLog –これはおそらくセカンダリの略です ログ 。これは、バージョン管理できない操作をキャプチャするために使用されるメモリ内のログストリームです。データベースでADRが有効になっている場合、クラッシュリカバリの分析フェーズ中にsLogは常に再構築されます。 やり直し中 フェーズでは、実際のトランザクションログではなくsLogが使用され、メモリ内に配置されて含まれるトランザクションが少なくなるため、プロセスが高速化されます。従来のリカバリプロセスは、最後のチェックポイントからのトランザクションを処理します。 sLogはundoでも使用されます フェーズ。

• クリーナー –PVSから不要な行バージョンを削除します。 Microsoftは、不要な行バージョンを手動で強制的にクリーンアップするためのストアドプロシージャも提供しています。

-- LISTING 1: INVOKE THE BACKGROUND CLEANER

USE TSQLV4_ADR
GO
EXECUTE sys.sp_persistent_version_cleanup;

USE master
GO
EXECUTE master.sys.sp_persistent_version_cleanup 'TSQLV4_ADR';

データベースの高速リカバリはデフォルトでオフになっています

SQL Server 2019でADRがデフォルトでオフになっているという事実は、ADRが非常に優れた機能であるように見えることを考えると、一部のDBAにとっては意外に思われるかもしれません。 ADRは、それが有効になっているユーザーデータベースでバージョン管理を使用します。これは、データベースのサイズに大きな影響を与える可能性があります。さらに、ADRが有効になっている場合に良好なパフォーマンスを確保するために、データベースの拡張とPVSの可能な場所を計画する必要がある場合があります。したがって、この機能を意図的に有効にすることは理にかなっています。

実験：準備段階

新しい機能を調査し、トランザクションログのサイズとロールバックの速度に対するADRの影響を確認するための実験を設定しました。この実験では、単一のバックアップセットを使用して2つの同一のデータベースを作成し、これらのデータベースの1つでのみADRを有効にします。リスト2は、タスクの準備段階を示しています。

[expand title =” Code”]

-- LISTING 2: PREPARE THE DATABASES AND CONFIGURE ADR

-- 2a. Backup a sample database and restore as two identical databases

BACKUP DATABASE TSQLV4 TO DISK='TSQLV4.BAK' WITH COMPRESSION;

-- Restore Database TSQLV4_NOADR (ADR will not be enabled)
RESTORE DATABASE TSQLV4_NOADR FROM DISK='TSQLV4.BAK' WITH 
MOVE 'TSQLV4' TO 'C:\MSSQL\DATA\TSQLV4_NOADR.MDF',
MOVE 'TSQLV4_log' TO 'E:\MSSQL\LOG\TSQLV4_NOADR_LOG.LDF';

-- Restore Database TSQLV4_ADR (ADR will be enabled)
RESTORE DATABASE TSQLV4_ADR FROM DISK='TSQLV4.BAK' WITH 
MOVE 'TSQLV4' TO 'C:\MSSQL\DATA\TSQLV4_ADR.MDF',
MOVE 'TSQLV4_log' TO 'E:\MSSQL\LOG\TSQLV4_ADR_LOG.LDF';

-- 2b. Enable ADR in TSQLV4_ADR
USE [master]
GO

-- First create a separate filegroup and add a file to the filegroup
ALTER DATABASE [TSQLV4_ADR] ADD FILEGROUP [ADR_FG];
ALTER DATABASE [TSQLV4_ADR] ADD FILE ( NAME = N'TSQLV4_ADR01', FILENAME = N'C:\MSSQL\Data\TSQLV4_ADR01.ndf' , 
SIZE = 8192KB , FILEGROWTH = 65536KB ) TO FILEGROUP [ADR_FG]
GO

-- Enable ADR
ALTER DATABASE TSQLV4_ADR SET ACCELERATED_DATABASE_RECOVERY = ON (PERSISTENT_VERSION_STORE_FILEGROUP = ADR_FG);
GO

-- 2c. Check if all ADR is enabled as planned
SELECT name
, compatibility_level
, snapshot_isolation_state_desc
, recovery_model_desc
, target_recovery_time_in_seconds
, is_accelerated_database_recovery_on FROM SYS.DATABASES
WHERE name LIKE 'TSQLV4_%';


-- 2d. Check sizes of all files in the databases
SELECT DB_NAME(database_id) AS database_name
, name AS file_name
, physical_name
, (size * 8)/1024 AS [size (MB)]
, type_desc
FROM SYS.master_files
WHERE DB_NAME(database_id) LIKE 'TSQLV4_%';


-- 2e. Check size of log used

CREATE TABLE ##LogSpaceUsage (database_name VARCHAR(50)
, database_id INT, total_log_size_in_bytes BIGINT
, used_log_space_in_bytes BIGINT
, used_log_space_in_percent BIGINT
, log_space_in_bytes_since_last_backup BIGINT)

INSERT INTO ##LogSpaceUsage
EXEC sp_MSforeachdb @command1='
IF ''?'' LIKE ("TSQLV4_%")
SELECT DB_NAME(database_id), * FROM ?.SYS.dm_db_log_space_usage;'

SELECT * FROM ##LogSpaceUsage;

DROP TABLE ##LogSpaceUsage;

[/エキスパンド]

図1は、リスト2のセクション2cのSQL​​ステートメントの出力を示しています。また、データベースファイルのサイズとトランザクションログファイルの使用状況もキャプチャしました。 （図3を参照）。

図。 1ADRが構成されていることを確認します

図。 2データベースデータのファイルサイズを確認する

図。 3両方のデータベースに使用されるログのサイズを確認します

実験：実行フェーズ

続行する必要のある詳細を取得したら、リスト3および4のSQLコードを段階的に実行します。 2つのリストは同等ですが、2つの同一のデータベースで別々に実行しています。最初にINSERT（リスト3、3a）を実行し、次にDELETE（リスト3、3b）を実行します。これは、後でロールバックします。 INSERTとDELETEの両方で、操作をトランザクションにカプセル化したことに注意してください。また、INSERTは50回実行されることに注意してください。実行の各段階、つまり3a、3b、および3cの間で、リスト2,2eのコードを使用してトランザクションログの使用状況をキャプチャします。これは、セクション4a、4b、および4cでも同じです。

-- LISTING 3: EXECUTE DML IN TSQLV4_NOADR DATABASE

-- 3a. Execute INSERT Statement in TSQLV4_NOADR Database

USE TSQLV4_NOADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
SELECT * INTO [Sales].[OrderDetails_noadr] FROM [Sales].[OrderDetails];
GO
INSERT INTO [Sales].[OrderDetails_noadr] 
SELECT * FROM [Sales].[OrderDetails];
GO 50

COMMIT;

-- 3b. Execute DELETE in TSQLV4_NOADR Database

USE TSQLV4_NOADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
DELETE FROM [Sales].[OrderDetails_noadr]
GO

-- 3c. Perform Rollback and Capture Time
ROLLBACK;

-- LISTING 4: EXECUTE DML IN TSQLV4_ADR DATABASE

-- 4a. Execute INSERT Statement in TSQLV4_ADR Database

USE TSQLV4_ADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
SELECT * INTO [Sales].[OrderDetails_adr] FROM [Sales].[OrderDetails];
GO
INSERT INTO [Sales].[OrderDetails_adr] 
SELECT * FROM [Sales].[OrderDetails];
GO 50

COMMIT;


-- 4b. Execute DELETE in TSQLV4_ADR Database

USE TSQLV4_ADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
DELETE FROM [Sales].[OrderDetails_adr]
GO

-- 4c. Perform Rollback and Capture Time
ROLLBACK;