SQL Database の Single Database では、SQL Database バックアップとは に記載されているタイミングでトランザクションログのバックアップが取得され、ログの切り捨てが行われます。
Hyperscale の各種メトリクスを取得して分析すると気づくのですが、Hyperscale については、定期的な間隔ではなく、使用サイズによってトランザクションログの切り捨てが行われるような動作となっているように見えます。
このサイズが何によって決まっているのかを調べてみました。
トランザクションログの使用状況は、次のようなクエリでメトリクスを取得しています。
DROP TABLE IF EXISTS log_used
GO
SELECT
GETDATE() AS Collect_Date,
total_log_size_in_bytes / POWER(1024, 2) AS total_size_MB,
used_log_space_in_bytes / POWER(1024, 2) AS used_size_MB,
used_log_space_in_percent,
log_space_in_bytes_since_last_backup / POWER(1024, 2)AS log_space_in_MB,
(SELECT
active_vlf_count
FROM
sys.dm_db_log_stats(DB_ID())) AS active_vlf_count
INTO
log_used
FROM
sys.dm_db_log_space_usage
GO
WHILE(0=0)
BEGIN
INSERT INTO log_used
SELECT
GETDATE() AS Collect_Date,
total_log_size_in_bytes / POWER(1024, 2) AS total_size_MB,
used_log_space_in_bytes / POWER(1024, 2) AS used_size_MB,
used_log_space_in_percent,
log_space_in_bytes_since_last_backup / POWER(1024, 2)AS log_space_in_MB,
(SELECT
active_vlf_count
FROM
sys.dm_db_log_stats(DB_ID())) AS active_vlf_count
FROM
sys.dm_db_log_space_usage
WAITFOR DELAY '00:00:30'
END
GO
データの変更を実施している状態で、上述のクエリで情報を取得してみると、トランザクションログの使用サイズは次のようになります。
16GB 程度まで達するとトランザクションログの切り捨てが行われているようなグラフとなり、この波形が以降も続きます。
16GB というサイズですが、これは SQL Server のトランザクションログの VLF (仮想ログファイル) 単位で Destage しているからだと思います。
VLF の情報は次のようなクエリで取得することができます。
SELECT * FROM sys.dm_db_log_stats(DB_ID()) SELECT * FROM sys.dm_db_log_info(DB_ID())
Hyperscale のトランザクションログのファイルですが、1TB のトランザクションログを 16GB × 63 個の VLF に分割をして構成が行われているようです。
トランザクションログの使用率とアクティブな VLF の個数を同一の時系列にしてみると、次のような波形となります。
瞬間的にアクティブな VLF が 2 個となっていますが、トランザクションログのサイズの減少と合わせて、アクティブな VLF の個数の減少が確認できますね。
これが Hyperscale のトランザクションログの切り捨ての基本的な波形となるようです。
Hyperscale のデータベースのバックアップは通常の SQL Server のデータベースとは異なり、
- データファイルを Snapshot でバックアップを取得
- ログについては、ログレコードを Destage することで長期保存する
というようなアプローチで取得が行われているため、通常のデータベースとはトランザクションログのログ切り捨ての動作が異なっているようです。
16GB という固定的なサイズでどうして切り捨てられているのかというのが、以前からの疑問だったのですが、VLF の情報と合わせて考えて波形を作ってみることで、理解を進めることができる情報になりました。