データベース スナップショット (SQL Server)
データベース スナップショットは、SQL Server データベース (ソース データベース) の読み取り専用の静的ビューです。 データベース スナップショットには、そのスナップショットを作成した時点でのソース データベースに対するトランザクションが反映されています。 データベース スナップショットは、常にそのソース データベースと同じサーバー インスタンス上に存在します。 ソース データベースが更新されると、データベース スナップショットが更新されます。 したがって、データベース スナップショットが長期間にわたって存在するほど、使用可能なディスク領域が使い尽くされる可能性が高くなります。
1 つのソース データベースには複数のスナップショットが存在できます。 各データベース スナップショットは、データベースの所有者によって明示的に削除されるまで保持されます。
Note
データベース スナップショットは、スナップショットのバックアップ、トランザクションのスナップショット分離、およびスナップショット レプリケーションとは無関係の機能です。
このトピックの内容
機能の概要
データベース スナップショットは、データページ レベルで動作します。 ソース データベースのページをユーザーが初めて変更する前に、元のページがソース データベースからスナップショットにコピーされます。 スナップショットには元のページが格納され、スナップショットの作成時点におけるデータ レコードの状態が保持されます。 初めて変更する各ページについて、同様の処理が繰り返されます。 データベース スナップショットに対する読み取り操作では、その格納場所にかかわらず、常に元のデータ ページにアクセスすることになります。したがって、データベース スナップショットはユーザーには不変なものとして映ります。
コピーされた元のページを格納するために、スナップショットでは スパース ファイルが使用されます。 スパース ファイルの最初の状態は、ユーザー データを一切含まず、ユーザー データ用のディスク領域も割り当てられていない空のファイルです。 スパース ファイルのサイズは、ソース データベースで更新されるページ数が増えるにつれて大きくなります。 次の図は、2 つの対照的な更新パターンがスナップショットのサイズにどのような影響を与えるかを示しています。 更新パターン A は、スナップショットの有効期間に元のページの 30% しか更新されない環境を反映し、 更新パターン B は、スナップショットの有効期間に元のページの 80% が更新される環境を反映しています。
データベース スナップショットの利点
スナップショットはレポート生成に使用できます。
クライアントは、データベース スナップショットをクエリできます。したがって、スナップショットを作成した時点のデータに基づいてレポートを作成することができます。
レポートの生成に関する履歴データを維持できます。
スナップショットを使用すると、データへのユーザー アクセスを特定の時点から延長することができます。 たとえば、特定の期間 (営業年度の四半期など) の終了時にデータベース スナップショットを作成しておけば、 その後、これらのスナップショットに基づいて期間末レポートを作成できます。 ディスク領域が十分にある場合は、期間末スナップショットを無期限に維持することも可能です。それによって、これらの期間の結果をクエリして、組織の業績を調べたりできるようになります。
可用性の目的で維持しているミラー データベースを使用して、レポート作成に伴う負担を軽減できます。
データベース スナップショットをデータベース ミラーリングと共に使用すると、ミラー サーバー上のデータをレポートに使用できるようになります。 また、ミラー データベースに対してクエリを実行すると、プリンシパル サーバー上のリソースを解放することもできます。 詳細については、「データベース ミラーリングとデータベース スナップショット (SQL Server)」を参照してください。
管理者によるエラーからデータを保護できます。
ソース データベースでユーザー エラーが発生したときは、特定のデータベース スナップショットの作成時の状態にソース データベースを戻すことができます。 失われるデータは、スナップショットの作成時点よりも後に行ったデータベースへの更新内容だけです。
たとえば、一括更新やスキーマの変更などの大がかりな更新を実行する場合は、事前にデータベース スナップショットを作成しておくと、データを保護することができます。 スナップショットを使用すると、更新を間違えた場合でも、データベースをスナップショットに戻すことによってデータを復旧できます。 この場合、データベースを元の状態に戻す方がバックアップから復元するよりも短時間で済みますが、後でロールフォワードすることはできません。
重要
オフラインのデータベースや破損したデータベースは元に戻せません。 このため、データベースの保護には、定期的なバックアップと復元プランのテストが必要です。
Note
データベース スナップショットはソース データベースに依存します。 したがって、データベース スナップショットを使用してデータベースを以前の状態に戻す方法は、バックアップおよび復元の代替にはなりません。 定期的なバックアップを毎回行うことが必要なことに変わりはありません。 データベース スナップショットを作成した時点の状態にソース データベースを復元する必要がある場合は、そのためのバックアップ ポリシーを実装してください。
ユーザーによるエラーからデータを保護できます。
データベース スナップショットを定期的に作成すると、テーブルの削除など、ユーザーが重大な間違いを犯した場合にその影響を最小限に抑えることができます。 ユーザーによる大半のエラーを認識し、それに対応できるよう、十分な長さの期間をカバーした一連のデータベース スナップショットを作成しておくと、データの保護レベルを高めることができます。 たとえば、ディスク リソースに応じて、24 時間間隔で作成されるスナップショットを 6 ～ 12 個維持しておき、 新しいスナップショットが作成されるたびに、最も古いスナップショットが削除されるようにすることができます。
ユーザー エラーが発生する直前のスナップショットにデータベースを戻すと、エラーから復旧することができます。 この場合、データベースを元の状態に戻す方がバックアップから復元するよりも短時間で済みますが、後でロールフォワードすることはできません。
あるいは、スナップショットの情報を使用すると、削除されたテーブルやその他の紛失データを手動で再構築できる場合もあります。 たとえば、スナップショットのデータをデータベースに一括コピーして、データベースにデータを手動でマージすることができます。
Note
データベースごとに必要な同時実行スナップショットの数、新規スナップショットを作成する頻度、およびスナップショットを保持する期間は、データベース スナップショットをどのような理由で使用するかによって決まります。
テスト データベースの管理
テスト環境でテスト プロトコルを繰り返し実行する場合は、各テスト ラウンドを開始する際に同一のデータをデータベースに格納しておくと便利です。 アプリケーション開発者やテスターは、最初のラウンドを実行する前に、テスト データベースのデータベース スナップショットを作成できます。 各テストの実行が完了したら、データベース スナップショットを戻すことにより、データベースを元の状態にすばやく戻すことができます。
用語と定義
データベース スナップショット (database snapshot)
データベース (ソース データベース) の読み取り専用の静的なビュー。トランザクションの一貫性が確保されます。
ソース データベース
データベース スナップショットの場合、スナップショットの作成元となったデータベース。 データベース スナップショットはソース データベースに依存します。 データベースのスナップショットは、データベースと同じサーバー インスタンス上に格納する必要があります。 さらに、データベースがなんらかの理由で使用できなくなった場合、データベース スナップショットもすべて使用できなくなります。
スパース ファイル (sparse file)
NTFS ファイル システムによって実現される、本来よりもはるかに少ないディスク領域しか必要としないファイル。 スパース ファイルは、データベース スナップショットにコピーされたページを保存する際に使用されます。 作成したばかりのスパース ファイルは、ディスク領域をほとんど使用しません。 データがデータベース スナップショットに書き込まれるにつれて、NTFS によって、対応するスパース ファイルにディスク領域が徐々に割り当てられます。
データベース スナップショットの前提条件と制限
このセクションの内容
前提条件
任意の復旧モデルを使用できるソース データベースは、次の前提条件を満たす必要があります。
サーバー インスタンスは、データベース スナップショットをサポートするSQL Serverのエディションで実行されている必要があります。 詳しくは「 Features Supported by the Editions of SQL Server 2014」をご覧ください。
ソース データベースは、データベース ミラーリング セッション内のミラー データベースである場合を除き、オンラインである必要があります。
データベース スナップショットは、可用性グループ内の任意のプライマリ データベースまたはセカンダリ データベースに作成できます。 レプリカのロールは "プライマリ" または "セカンダリ" とし、"解決中" 状態でないことが必要です。
データベース スナップショットの作成は、データベースの同期状態が "同期中" または "同期済み" であるときに実行することをお勧めします。 ただし、データベースの同期状態が "同期されていません" であっても、データベース スナップショットを作成することはできます。
詳細については、「AlwaysOn 可用性グループを使用したデータベース スナップショット (SQL Server)」を参照してください。
ミラー データベースにデータベース スナップショットを作成するには、データベースは "同期済み" のミラーリング状態になっている必要があります。
ソース データベースは、スケーラブルな共有データベースとして構成できません。
注意
すべての復旧モデルがデータベース スナップショットをサポートしています。
ソース データベースへの制限
データベース スナップショットが存在する限り、スナップショットのソース データベースには次の制限事項があります。
データベースは削除、デタッチ、または復元できません。
注意
ソース データベースのバックアップは正常に実行されます。この動作はデータベース スナップショットの影響を受けません。
ソース データベースでの I/O が増加することによって、パフォーマンスが低下します。これは、ページが更新されるたびにスナップショットに対して copy-on-write (書き込まれるたびにコピーする) 操作が実行されることが原因です。
ソース データベースまたはスナップショットからはファイルを削除できません。
データベース スナップショットへの制限
データベース スナップショットには、次の制限事項が適用されます。
データベース スナップショットは、ソース データベースと同じサーバー インスタンスに作成および保持される必要があります。
データベース スナップショットは、常にデータベース全体に対して機能します。
データベース スナップショットはソース データベースに依存するものであり、冗長ストレージではありません。 ディスク エラーやその他の種類の破損からは保護されません。 したがって、データベース スナップショットを使用してデータベースを以前の状態に戻す方法は、バックアップおよび復元の代替にはなりません。 定期的なバックアップを毎回行うことが必要なことに変わりはありません。 データベース スナップショットを作成した時点の状態にソース データベースを復元する必要がある場合は、そのためのバックアップ ポリシーを実装してください。
ソース データベースで更新されているページがスナップショットにプッシュされたときに、そのスナップショットによりディスク領域不足やその他のエラーが発生すると、そのスナップショットは問題ありに設定されるので、削除する必要があります。
スナップショットは読み取り専用です。 読み取り専用であるため、アップグレードできません。 したがって、データベース スナップショットはアップグレード後は利用不可と想定されます。
model、 master、および tempdb の各データベースのスナップショットは禁止されています。
データベース スナップショット ファイルの仕様は変更できません。
データベース スナップショットからはファイルを削除できません。
データベース スナップショットはバックアップまたは復元できません。
データベース スナップショットはアタッチまたはデタッチできません。
FAT32 ファイル システムまたは未処理のパーティションにはデータベース スナップショットを作成できません。 データベース スナップショットで使用されるスパース ファイルは NTFS ファイル システムによって提供されます。
データベース スナップショットではフルテキスト インデックスはサポートされていません。 フルテキスト カタログはソース データベースから反映されません。
データベース スナップショットでは、スナップショットの作成時にソース データベースのセキュリティ制約が継承されます。 スナップショットは読み取り専用なので、継承された権限は変更できません。また、ソース データベースに加えられた権限の変更は、既存のスナップショットには反映されません。
スナップショットには、常にスナップショットの作成時にファイル グループの状態が反映されます。オンライン ファイル グループはオンラインのまま、オフライン ファイル グループはオフラインのまま保持されます。 詳細については、このトピックの後半に記載されている「オフライン ファイル グループを含むデータベース スナップショット」を参照してください。
ソース データベースが RECOVERY_PENDING になった場合、データベース スナップショットにアクセスできなくなる場合があります。 ただし、ソース データベースの問題を解決した後は、スナップショットを再度利用できるようになります。
元に戻す操作は、読み取り専用のファイル グループと圧縮されたファイル グループではサポートされていません。 これらのいずれかの種類のファイル グループを含むデータベースを元に戻す操作は失敗します。
ログ配布構成では、データベース スナップショットを作成できるのはプライマリ データベースだけです。セカンダリ データベースでは作成できません。 プライマリ サーバー インスタンスとセカンダリ サーバー インスタンスの役割を交代させる場合は、プライマリ データベースをセカンダリ データベースとしてセットアップする前にすべてのデータベース スナップショットを削除する必要があります。
データベース スナップショットは、スケーラブルな共有データベースとして構成できません。
FILESTREAM ファイル グループは、データベース スナップショットではサポートされていません。 FILESTREAM ファイル グループがソース データベース内にある場合、それらはデータベース スナップショット内でオフラインとしてマークされ、データベースを元に戻す操作でデータベース スナップショットを使用できなくなります。
注意
データベース スナップショットで実行する SELECT ステートメントには、FILESTREAM 列を指定しないようにする必要があります。FILESTREAM 列が含まれていると、次のようなエラー メッセージが返されます。
Could not continue scan with NOLOCK due to data movement.読み取り専用スナップショットの統計が見つからないか古い場合、データベース エンジンは tempdb で一時的な統計を作成して保持します。 詳細については、統計に関する記事を参照してください。
必要なディスク領域
データベース スナップショットはディスク領域を消費します。 データベース スナップショットによってディスク領域が足りなくなった場合、そのデータベース スナップショットは問題ありに設定されるので、削除する必要があります (ただし、ソース データベースは影響を受けず、操作は正常に続行されます)。しかし、データベースの完全なコピーと比較すると、スナップショットでは領域が非常に効率的に使用されます。 スナップショットにとって必要なのは、有効期間中に変化するページを格納する領域だけです。 通常はスナップショットが保持されている時間は限られているので、サイズはそれほど大きな問題ではありません。
ただし、スナップショットを保持する時間が長くなると、空き領域が消費される可能性が高くなります。 スパース ファイルを拡張できる最大サイズは、スナップショットの作成時の対応するソース データベース ファイルのサイズです。
データベース スナップショットによってディスク領域が足りなくなった場合は、データベース スナップショットを削除する必要があります。
注意
ファイル領域を除いて、データベース スナップショットはデータベースとほぼ同じくらいのリソースを消費します。
オフライン ファイル グループを含むデータベース スナップショット
ソース データベース内のオフライン ファイル グループは、次の操作を実行しようとすると、データベース スナップショットに影響を与えます。
スナップショットの作成
ソース データベースに 1 つ以上のオフライン ファイル グループが含まれている場合、ファイル グループがオフラインのときは、スナップショットを正常に作成できます。 オフライン ファイル グループの場合、スパース ファイルは作成されません。
ファイル グループをオフラインにする
ソース データベースのファイルはオフラインにできます。 ただし、データベース スナップショットの作成時にオンラインだったファイル グループは、データベース スナップショットでもオンラインです。 クエリされたデータがスナップショットの作成時以降に変更された場合、スナップショットから元のデータ ページにアクセスできます。 ただし、ファイル グループ内の変更されていないデータへのアクセスにスナップショットを使用するクエリは、入出力 (I/O) エラーで失敗する可能性があります。
ファイル グループをオンラインにする
データベース スナップショットが存在するデータベースでファイル グループをオンラインにすることはできません。 スナップショットの作成時にオフラインだったファイル グループや、データベース スナップショットが存在している間にオフラインにしたファイル グループは、オフラインのままになります。 これは、ファイルをオンラインに戻す際にファイルの復元が行われるためです。データベースにデータベース スナップショットが存在している場合、ファイルを復元することはできません。
ソース データベースをスナップショットに戻す
ソース データベースをデータベース スナップショットに戻すには、スナップショットの作成時にオフラインだったファイル グループを除くすべてのファイル グループがオンラインである必要があります。