ニュース&ブログ
【SQL Server】バックアップ圧縮について検証してみた
投稿日:2023/10/20
はじめに
有難いことにSQL Serverの移行作業を行うことが増えてきました。
移行時にはできる限り停止時間を短縮するための施策を考える必要がありますが、その一つとして、バックアップ圧縮という機能があります。
当然この機能を使用するメリット・デメリットが存在します。
本記事では、SQL Serverのバックアップ圧縮の概要と技術検証を記載していこうと思います。
バックアップ圧縮の概要
その名の通り、SQL Serverのバックアップファイルを圧縮する機能です。圧縮を行うことによって得られるメリットは以下の通りです。
①バックアップの時間短縮
②バックアップファイルのサイズを小さくできる
③データ移行の時間短縮
Azure仮想マシン上でのSQL Server構成設定のベストプラクティスにはなりますが、バックアップ圧縮を有効化することも挙げられています。
しかし、圧縮処理によってCPUが通常のバックアップ処理より多く消費されるため、メリットを得るためのトレードオフと考える必要があります。
なお、バックアップ圧縮はSQL ServerのEnterprise、Standard、Developerでサポートされています。
バックアップ圧縮の有効化
SSMSのGUIからは、[バックアップオプション] > [バックアップの圧縮設定] > [バックアップを圧縮する]で設定可能です。
クエリの場合は、COMPRESSIONオプションを付与します。
BACKUP DATABASE <database_name> TO DISK WITH COMPRESSION
検証
今回は以下の環境でバックアップ圧縮効率の検証を行います。
OS : Windows 10(CPU4コア メモリ16GB)
SQL Server : Developer 2022
データベース : TEST(データ:23624MB ログ:25928MB)
ちなみにデータベースのデータ・ログファイルのサイズ及び実際に使用しているサイズを確認するSQLは下記となりますのでご活用ください。
-- 一時テーブルを作成
CREATE TABLE #tmp (
DatabaseName NVARCHAR(128),
LogSize_MB DECIMAL(18, 2),
LogSpaceUsed_PERCENTAGE DECIMAL(18, 2),
Status INT
);
CREATE TABLE #DiskUsageLog (
DatabaseName NVARCHAR(128),
LogSize_MB DECIMAL(18, 2),
);
CREATE TABLE #DiskUsageData (
name NVARCHAR(128),
rows CHAR(11),
reserved VARCHAR(18),
data VARCHAR(18),
index_size VARCHAR(18),
unused VARCHAR(18)
);
-- データの削除
TRUNCATE TABLE #tmp
TRUNCATE TABLE #DiskUsageLog
TRUNCATE TABLE #DiskUsageData
-- DBCC SQLPERF(LOGSPACE)の結果をtmpに挿入
INSERT INTO #tmp
EXEC ('DBCC SQLPERF(LOGSPACE)');
-- Logのデータを挿入
INSERT INTO #DiskUsageLog
SELECT DatabaseName, LogSize_MB FROM #tmp
-- Dataのデータを挿入し変換
INSERT INTO #DiskUsageData
EXEC sp_MSforeachtable 'sp_spaceused ''?''';
-- データファイルのサイズ確認
SELECT name AS Logical_Name,
type_desc AS Type,
size * 8 / 1024 AS Size
FROM sys.database_files;
-- 実際のログのサイズ確認
SELECT * FROM #DiskUsageLog
WHERE DatabaseName = DB_NAME();
-- 実際のデータのサイズ確認
SELECT
DB_NAME() AS DatabaseName,
SUM(CAST(REPLACE(reserved, ' KB', '') AS INT)) / 1024 AS TotalReservedMB,
SUM(CAST(REPLACE(data, ' KB', '') AS INT)) / 1024 AS TotalDataMB,
SUM(CAST(REPLACE(index_size, ' KB', '') AS INT)) / 1024 AS TotalIndexSizeMB
FROM #DiskUsageData;
実行結果
データファイルのサイズは23GBであることが確認できます。
まずは非圧縮でのバックアップパフォーマンスを確認していきます。
23GBのデータをバックアップするのに5分22秒掛かりました。
CPU使用率はパフォーマンスモニターから確認し、平常時は平均15%で、非圧縮でのバックアップ時は平均32%です。
次に圧縮バックアップのパフォーマンスです。
61秒でバックアップが終了しており、23GBのデータを1.5GBまで圧縮できています。
気になるCPU使用率ですが、平均52%という結果となり非圧縮と比べ1.5倍程高くなりました
次にリストアも確認しました。
リストアに掛かった時間ですが、非圧縮の場合は7分21秒、CPU使用率は平均18%程度でした。
圧縮の場合は6分49秒、CPU使用率の平均は22%程度でした。
バックアップファイルのサイズは小さくなりますが、大きなリストア時間の短縮には繋がらないようです。
また、バックアップ程のCPU使用率ではありませんが、リストア開始時の1~2分は30%あたりを推移していましたので若干ですがCPU使用率が高くなる傾向となっていました。
検証結果
圧縮 | 非圧縮 | |
バックアップの時間 | 61秒 | 5分22秒 |
バックアップのCPU使用率 | 52% | 32% |
バックアップファイルのサイズ | 1.5GB | 23GB |
リストアの時間 | 6分46秒 | 7分21秒 |
リストアのCPU使用率 | 22% | 18% |
今回の検証からバックアップの時間は5分の1まで短縮、バックアップファイルのサイズは15分の1にまで圧縮できることがわかりました。
また、SQL Serverのデータ移行ではバックアップファイルを現行環境から新環境へ転送することが多いですが、バックアップ圧縮でファイルサイズを小さくすることで転送時間も短縮可能です。
CPU使用率の増加を許容することができればバックアップ圧縮は有用な設定と判断できそうですね。
中川 智文(2022年入社)
株式会社システムサポート フューチャーイノベーション事業本部 ソリューションサービス事業部所属
Oracle Database,SQL Serverを中心とした案件に従事