SQL Serverサンドボックス

私はレポート開発者が作業を行うためのサンドボックスをセットアップしようとしています。私の現在の計画は、毎晩データベースを「リセット」することですが、どうすればよいかわかりません。リセットとは、サーバー上の1つのデータベースを除くすべてのユーザーテーブル、ビュー、ストアドプロシージャなどを基本的に削除することです。データベースを削除して再作成することもできると思いますが、適切なADグループ/ユーザーすべてへのアクセスを再度許可することになると思います。

これを実行するための最善の方法は本当にわからないので、あなたの何人かがいくつかの良いアイデア/提案を提供できることを願っています。ありがとう。

：明確にするために、我々は基本的に私達のデータベースでこれをやりたいhttp://try.discourse.org/t/this-site-is-a-sandbox-it-is-reset-every-day/57。唯一の違いは、毎日ユーザーを再現したくないということです。

バージョン： SQL Server 2008
エディション： Developer＆Enterprise

sql-server sql-server-2008

— キット0124
ソース

回答:

もう1つのアイデアは、copy_onlyバックアップを実行し、それを開発サーバー（または、サーバーが1つしかない場合は同じサーバー）に復元する、毎晩のジョブを単純に設定することです。これの良い点は、復元が任意のサーバー（または複数のサーバー）に移動でき、プライマリデータベースでのアクティビティから完全に分離できることです。

サーバー1で：

BACKUP DATABASE db TO DISK = '\\someshare\file.bak' 
  WITH COPY_ONLY, INIT, COMPRESSION;

サーバー2で：

RESTORE DATABASE db_dev FROM DISK = '\\someshare\file.bak'
  WITH REPLACE, RECOVERY;

MOVEサーバー間のディスクレイアウトが異なる場合（またはコピーを同じサーバーに配置する場合）は、コマンドを追加する必要がある場合もあります。

RESTORE DATABASE db_dev FROM DISK = '\\someshare\file.bak'
  WITH REPLACE, RECOVERY,
  MOVE 'data_file_name' TO 'D:\somepath\somefile.mdf',
  MOVE 'log_file_name'  TO 'E:\somepath\somefile.ldf';

同じサーバーで復元している場合は、ユーザーに問題はありません。別のサーバーに復元する場合、ユーザーは存在しますが、サーバーレベルのログインは存在しない場合があります。これを修正するスクリプトと、SQL Server 2012（包含データベース）の新機能により、問題を完全に排除します。

— アーロン・バートランド
ソース

dev / prodはありますが、devはこれが発生する唯一のサーバーです。本番は本番対応のプロセス専用です。

— Kittoes0124

これが私が選択するソリューションです。ほとんどの場合、本番環境を開発環境に単にコピーすることを望まないことを覚えておいてください。たとえば、ユーザーのメールアドレス、連絡先の詳細などを削除または不明瞭にする対策（スクリプト？）を用意してください。開発者が誤ってユーザーにメールを送信し始めないようにする必要があります。

— zeroDivisible 2013

Enterprise Editionエンジンのインスタンスがあるので、データベーススナップショットを使用します。

これにより、データベース全体を復元しなくても、日中に加えられた変更をすばやく簡単にロールバックできます。

開発者がビッグデータのロードを計画している場合（そうでないように聞こえますか？）、これは適切でない場合があります。

— ジョン・セイゲル
ソース

ビッグデータの読み込みを行うのが適切ではないのはなぜですか。時々、100カラムの800万行がロードされる可能性があります（そうでない場合でも）、必ずしもそうすることを防ぐ必要はありません。私たちが本当に気にしているのは、すべてが1日の終わりに核になることです。

— Kittoes0124

@Kittoes。これは、ソースデータが変更されたときにスナップショットを維持する必要があるためです。ソースが変更された場合、既存のページをソースからプルして、「前」のビューを維持する必要があります。これは、ソースデータが変更されるまで行われません（スナップショットは、デルタを除いて空のスパースファイルを使用します）。このメンテナンスは非常に高価になる可能性があります。データベーススナップショットのしくみをご覧ください。

— アーロンバートランド

@AaronBertrand OK、つまり、データベースが1日中に8 GBに増加した場合、スナップショットが復元されると、すべての新しいデータが削除されますが、データベースのサイズは8 GBのままです。それとも私は誤解していますか？

— Kittoes0124

@Kittoesスナップショットは読み取り専用なので、ソースデータベースに新しいデータを読み込むことしかできません。日中に8GBを追加すると、スナップショットからは見えなくなります。スナップショットを元に戻したり削除したりしても、ソースデータベースには8GBのデータが残り、それに応じてサイズが調整されます。その後、別のスナップショットを作成すると、新しいデータが表示されます。日中に8GBを削除すると、スナップショットに追加されます。

— アーロンバートランド

@Kittoesは、スナップショットが作成された時点に戻すことによって8 GBのデータロードを元に戻したい場合は、データファイルを元のサイズに戻す必要があります（ファイルを本当に小さくしたいかどうかにかかわらず、明日再び8GBをロードすると、さらに自動拡張できます）。しかし、私はそのシナリオを明示的にテストしていません。そして、私が言及した記事にあるように、これは基礎となるストレージの信頼性にも左右されるため、必ずしも絶対に確実なわけではありません。バックアップはそれを行うためのより安全な方法です。

— アーロンバートランド

それがあなたに役立つかどうかを確認するために私の数セントを追加させてください：

私の会社では、開発者が1日中使用していたデータベースを毎晩更新したいという同じ状況にあります。これは、Devが触れないデータベースのセットがあることを意味します-Aと言うと、正確にコピーAである別のデータベースのセットですが、彼らは自分の仕事をしていますが、毎晩更新したいです-Bとしましょう。これは、単一のサーバーインスタンスで発生します。

私が実装したのは、これを達成するためのNIGHTLY RESTOREプロセスです。以下はその仕組みです：

毎晩復元する必要があるデータベースのリストを含むドライバーテーブルを作成します（前述のとおり）。

テーブル：nightly_restore（OriginalDB、RestoreDB、backuplocation、enabled_YN、結果、PASS_FAIL）

次に、上記のテーブルからデータベースのリストをループし、リストアを実行して、成功または失敗を結果に記録し、ビット1 =パスまたは0 =失敗するTSQLを記述できます。Enabled_YNは、そのデータベースを復元する必要があるかどうかを決定します。

今後追加されるデータベースが他にもある場合は、それらをテーブルに挿入して、enabled_YNビットをY（有効）に設定するだけです。

これにより、プロセスはより柔軟で管理しやすくなります。

私が書いたSQLが必要な場合（きっと、あなたはそれを書くことができるでしょう:-)）、pingを実行するか、コメントを追加すれば共有します。

HTH

— キンシャー
ソース