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