データベーススナップショットのパフォーマンスを見る

データベーススナップショットは、データベーススナップショットが作成されたときのソースデータベースの状態とトランザクション的に整合性のあるSQLServerデータベースの読み取り専用ビューを提供します。ミラーリングされたデータベースに対するレポートなど、データベーススナップショットを使用する理由はいくつかあります。また、DBCC CHECKDBは、SQLServer2005以降の内部データベーススナップショットも使用します。

データベーススナップショットは、データベーススナップショットの作成以降にデータベースに発生したすべての変更をロールバックする機能も提供しますが、Paulがここでブログに書いたデータベースのトランザクションログに厄介な副作用があります。

データベーススナップショットに関して一般的に考慮または表示されないものの1つは、スナップショットがデータベース書き込みワークロードに与えるパフォーマンスへの影響です。 SQLCATチームは、SQL Server2005のホワイトペーパー「I/O集約型ワークロードでのデータベーススナップショットのパフォーマンスに関する考慮事項」を公開しました。このホワイトペーパーでは、データベーススナップショットのパフォーマンスへの影響を調査しました。最近、データベーススナップショットによってパフォーマンスの問題が発生したクライアントと連携した後、 SQL Server 2012をテストし、7年後および3回のSQLServerリリース後にデータベーススナップショットのオーバーヘッドに変更があったかどうかを判断します。

テスト構成

書き込みワークロードのパフォーマンスに対するデータベーススナップショットの影響のテストを実行するために、AdventureWorks2012データベースの拡大バージョンの新しいテーブルに1,000,000行の挿入を実行するDellR720を使用しました。 AdventureWorks2012データベースは、2つのFusion-io ioDrive Duo 640GB SSDに分散された8つのデータファイルで作成されました。各SSDは、Windowsで2つの個別の320GBディスクとしてセットアップされ、合計4つのディスクを提供します。構成の説明を簡単にするために、これらのテストに使用されたストレージレイアウトを次の表に示します。

ディスク	構成	使用法
K	15K RAID 5 –6ディスク	スナップショット
L	Fusion-io Card2 –サイドB	ログファイル
M	Fusion-io Card2 –サイドA	4つのデータファイル
N	Fusion-io Card1 –サイドA	4つのデータファイル
Q	Fusion-io Card1 –サイドB	Tempdb
R	LSI Nytro BLP4-1600	スナップショット

表1-サーバーディスクのレイアウトと使用法

データベーススナップショットのストレージは、iSCSIを介して接続された6台の15k RPM SASドライブのRAID-5アレイ、またはLSI NytroBLP4-1600PCI-Eカードのいずれかでした。

テストワークロードは、次のSELECT INTOステートメントを使用して、各テストの間にドロップされた1,000,000行のテーブルを生成しました。

SELECT TOP 1000000 *
INTO tmp_SalesOrderHeader
FROM Sales.SalesOrderHeaderEnlarged;

テストは、データベーススナップショットなしの期間を測定し、次に各ストレージデバイスでデータベーススナップショットを使用して期間を測定して、データベーススナップショットスパースファイルへのページ変更の書き込みによって引き起こされるパフォーマンスの低下を測定するようにタイミングを合わせました。また、同じストレージデバイスで2つのデータベーススナップショットを使用してテストを実行し、実行する必要のある重複した書き込み操作に対して、追加のデータベーススナップショットを作成することによるオーバーヘッドを確認しました。

結果

各テスト構成は10回実行され、見やすくするためにミリ秒から秒に変換された平均期間が、0、1、または2つのデータベーススナップショットについて図1に示されています。

図1-スナップショットの継続時間

データベーススナップショットを使用しないベースラインテストでは、平均1.8秒で実行され、データベーススナップショットファイルのストレージのパフォーマンスが同等であった場合でも、単一のデータベーススナップショットが存在すると、データベースの書き込みパフォーマンスにオーバーヘッドが発生しました。 2番目のデータベーススナップショットのオーバーヘッドは、各テストで最初のデータベーススナップショットを使用するよりも低くなりますが、15K RPMディスクでは、データベースの2番目のデータベーススナップショットから追加された書き込みワークロードに対応するのがはるかに困難でした。

LSI Nytroカードのパフォーマンスは、PCI-X SSDでもあったため、最初は驚きました。ただし、Glennと結果について話し合った後、Sandforceコントローラーの圧縮と、ドライブでの過去のテストからのランダムな低圧縮データの書き込みパフォーマンスの低下について言及しました。ただし、それでも回転するメディアを簡単に凌駕しました。

テストを実行する前に、テスト中に発生する待機タイプを知りたいと思ったので、テスト構成の一部として、DBCC SQLPERFを使用してsys.dm_os_wait_statsをクリアし、テスト実行ごとにDMVからの出力をテーブルにキャプチャしました。単一のスナップショット構成の上位待機は、図2に示すように、1つまたは2つのデータベーススナップショットのPREEMPTIVE_OS_WRITEFILEとWRITE_COMPLETIONでした。

図2–スナップショットの上位待機

興味深い項目の1つは、2番目のスナップショットが作成されたときにFCB_REPLICA_WRITE待機が追加されたことです。単一データベースのスナップショット待機結果を確認し、数回のテストを再実行した後、この待機は単一のスナップショットでは発生せず、複数のスナップショットが存在し、データベーススナップショットファイルへのページのコピーに関連付けられている場合にのみ発生します。 PREEMPTIVE_OS_WRITEFILE待機の待機時間は、各構成の実行時間の増加に伴って密接に変化します。

これらの結果を念頭に置いて、待機とキューの方法論を使用してシステムを確認する場合、値が高いこの待機タイプを確認することは、サーバー上のデータベースのいずれかにデータベーススナップショットが存在するかどうかを調査する価値があります。

結論

データベーススナップショットを使用する場合、SQL Server 2012でも、スナップショットのスパースファイルにデータページをコピーするために必要な追加の書き込みに関連するオーバーヘッドがあります。データベーススナップショットの使用が一般的な構成の一部である場合、データベーススナップショットスパースファイルへの同時I/Oアクティビティのワークロード要件を満たすようにI/Oサブシステムを計画することに本当に注意します。

これらのテストの結果から、書き込みパフォーマンスとスナップショットのメンテナンスによるパフォーマンスへの影響を低減するために、データベーススナップショットをtempdbよりも先にSSDに配置することも検討します。

いつものように、マイレージは異なる場合があります。実際に使用する前に、構成のパフォーマンスをテストすることをお勧めします。