SQL Serverデータベースを復元する最速の方法
10000の統合テストのそれぞれは、クリーンアップ段階で、それぞれが完了する前にデータベースを元の「クリーン」状態に復元する必要があります。すべてのテストの実行には時間がかかり、時間の80％はデータベースの復元操作に費やされます。
復元操作は、単にディスクからバックアップを取り、それを復元します。これを最適化する方法があるかどうか私は今疑問に思っています。私が考えている1つのオプションは、バックアップファイルの場所をディスクからメモリに変更することです。それは可能ですか？
別のオプションは、テーブルデータのみのスナップショットを取り、それのみをバックアップデータとして保存することです。次に、バックアップファイルが小さくなり、復元が速くなると想定します。それは可能ですか？
理想的には、復元を回避し、影響を受けるデータ（各テストが生成するデータ）をリセットするだけです。次のようなもの：「テストの開始以降に変更されたテーブル行を元に戻す」
どのようなオプションがありますか？私はこの分野の専門家ではありませんが、私の問題には簡単な解決策があるはずだと感じています。
データベースのスナップショットはおそらく正しい答えです Nicのコメントによると、特定の状況に適しています。
しかし、この質問を見つけた将来のユーザーにとって、ネイティブSQLデータベースのバックアップと復元の時間を改善する方法は確実にあります。
- データベースを圧縮してバックアップします：通常、I/Oがボトルネックになり、一部の作業がCPUにシフトします。
- ストレージ構成を変更します：ローカルまたはより高性能なSANにバックアップを保存します
- データベースを複数のファイル（ストライプ）にバックアップします：これは特定のストレージとネットワーク構成に依存する可能性がありますが、4と8のストライプが見つかりました私たちの環境でのバックアップと復元は、シングルストライプバックアップよりも2倍から10倍速く完了します。確かにいくつかのテストの価値があります。
- ファイルの即時初期化が有効になっていることを確認してください：ファイルを迅速に復元するためのスペースを切り分けるのに役立ちます
- データベースのサイズを縮小します：古いテーブルなどを削除します。もちろん、可能な場合は削除します。
- 空のスペースを縮小します：もちろん、縮小に関するすべての適切な警告と警告が適用されます。
- ページまたは行の圧縮を有効にします：データベースファイルを小さくして、復元時に書き込む量を減らします。