サーバー間で定期的にデータをコピーするためのオプションは何ですか？
これがすでに回答されている場合、私の謝罪。私はSOを検索しましたが、もちろんここDBAで検索しましたが、類似するものが見つからないことに驚いています。具体的には、スキーマの違いを乗り越えた解決策を探しています。
ようやく、本番データウェアハウスサーバーをシャドウイングするための開発サーバーを手に入れました。ここではスキーマとsprocの変更をテストし、最終的にそのような変更をprodサーバーに公開します。そのためには、かなり最新のデータが必要ですが、リアルタイムで更新する必要はありません。私の計画は、終夜ETLの最終ステップとして、メインサーバーから開発サーバーに最終状態データをコピーすることです。これを達成するための最良の方法は何ですか？
パラメーター
自動コピーはすべて、prodからdevに行われます。 devからprodへのコピーはすべて手作業で行われ、通常は単なるDDLです。
開発サーバーのスキーマは本番サーバーとは独立して変更されることが予想されるため、ターゲットスキーマが異なる場合にコピープロセスが失敗しないようにしたい（もちろん、flux内の特定のテーブルを同期できない場合は問題ありません） 。それ以外の場合は、DROP DATABASEを使用して、昨日のバックアップを復元します。
スキーマ、SP、ビュー、UDFの同期を維持する必要はなく、望ましいこともありません。それらは、私が特に変更した場合にのみ変更する必要があります。
ほとんどのテーブルではレコードを遡及的に変更できるため、増分更新はおそらく実用的ではありません。
最も重要なテーブルのデータ量は14 GBで、毎週更新できる重要度の低いデータは約200 GBです。
私の目標は、プロセスを2時間以内に完了することです。サーバーは同じ場所に配置されており、高いスループットが必要です。 600 MBのデータと300のインデックスを含む単一のテーブルのコピー（INSERT INTO..SELECT * FROM ProdServer..）には7.5分かかりました。よくない。一部の懸念事項として、11 GBのデータと8 GBのインデックスを含む別のテーブルがキャンセルされたとき、130分で完了しませんでした。インデックスなしでこれをもう一度テストします。
Prodデータベースをオフラインにすることは、30分以内に短時間で済むのであれば許容されます。必要に応じて、devデータベースを数時間オフラインにすることができます。
テスト中に特定のテーブルを一時的に除外して、数日間静的に保つことができれば、それは価値があります。
オプション
1：レプリケーション
ETLの終了後に毎日のスナップショットを作成し、それを開発サーバーに公開できます。私は以前にレプリケーションを使用したことがありませんが、これはそれが意味する種類のシナリオのようです。テクノロジーの新しい側面を学ぶ時間はありますか？
2：一括コピーと一括挿入
Prodデータベースのすべてのテーブルを反復処理し、コンテンツを一意の名前のファイルに吐き出すスクリプトを作成できます。開発者側では、これらのファイルをループし、TRUNCATE/BULK INSERTをターゲットテーブルにループします。スキーマが変更された場合は、TRY..CATCHブロックを使用します。これが許容範囲内で実行されるかどうかはわかりませんが、実装はかなり簡単です。
3：リンクサーバーから挿入
おそらく開発側からプルして、テーブルごとにTRUNCATE/INSERT..SELECTを実行できます。これは簡単で、特にインデックスを削除して再作成した場合は、高速になるはずです。スキーマの変更に対処するために、テーブルの各ペアのフィールドリストの共通部分を識別し、それらのフィールドのみをコピーすることができます。これは、多くのフィールドがNULL可能である場合に役立ちます。
他のオプションはありますか？私が見落としている簡単な方法はありますか？同様のプロジェクトに取り組んでいるときに遭遇した落とし穴はありますか？
この質問 はエクスポート側について説明しますが、必要な出力はCSVだったため、オプションは制限されています（回答どおり、BCPは適切に機能します）。
この質問 は、スキーマを含むデータベース全体をすばやくコピーすることについて話します。具体的にはレプリケーションを除外します。
この質問 双方向の同期について説明します。これについてはレプリケーションが推奨されます。
Prodからdevへの完全バックアップと差分バックアップの混合のバックアップ/復元を検討します。次に、この復元されたコピーを実際の開発データベースと同期します
SQL Server 2008 R2 +は、Standard Edition（SQL Server 2008ではEnterprise Editionのみでした）でのバックアップ圧縮をサポートしているため、これが容易になります。
理由：
- バックアップの整合性と復元機能をテストします
- いくつかのコードモンキーがbollixする場合、開発データベースを簡単にリセットできます
- 「前」と「後」のDDL、パフォーマンスなどを比較できます。
- 変更を加えた場合、必要に応じて復元されたデータベースのスナップショットを取り、これをロールバックできます。
私は以前これを使用したことがあり、これらの理由のために再び使用します
連続的統合マイグレーション V. Nextの展開とは、V。Prevからv。Nextへのアップグレードスクリプトを実行することを意味します。スクリプトはソースであり、チェックインされています。データベースバイナリファイル（MDF、LDF）を真のスキーマと見なさないでください。ソース（.sql）をスキーマと見なし、常に.sqlファイルを操作し、アップグレードに自信があるまで.sqlファイルをテストしてから、.sqlファイルを実行してアップグレードを展開します。
差分ベースの展開は、diffツールのなすがままになっているので、問題に悩まされています（一部は他よりも優れており、個人的には自分のライブ展開を信頼しません）。コピーベースの導入は言及する価値すらありません。
このプロセスを実行しない場合、肝臓のサーバーで変更は発生しません。 Ever。
開発サーバーへの本番サーバーのコピーはどうですか？権限のない目にさらしてデータを危険にさらす以外に、なぜそれをする必要があるのでしょうか？同じ手順、連続した統合と移行を使用して、テスト/開発サーバーをデプロイします。
一部のシナリオでは、prodのテストレプリカまたはprodのdevレプリカを使用できます。隣接する統合ビルドドロップの一部にします。毎晩のドロップは、prodバックアップから始まり、v。prodからv。devへの移行を実行します。結果は、新たにドロップされたprodデータベースのdevバリアントです。ところで、ドロップがv。prodからv。devへの移行もテストしただけだということに気づきましたか？開発環境では、データを匿名化するか、その他の変換を行う必要がありますか？もちろん、ソースツリーにチェックインされたスクリプトによって制御される、開発固有のデプロイメントステップにします。
スナップショットレプリケーションは、機能する唯一のレプリケーションです。しかし、他のバージョンのようにスキーマを変更できない可能性があります（トランザクション、マージ/ピアツーピア）。ただし、このシナリオのレプリケーションでは何も得られないので、バックアップと復元（Remusのアイデアは点在しているように見えます）のほうがよいでしょう。
このタイプの要件には、SQL Server Integration Services（SSIS）の使用をお勧めします。 SSISの優れた点は、エラーの処理の容易さ（質問で要求されているとおり）、それをスケジュールする機能、およびDTSXパッケージの完全な保守性です。サーバーの明示的なリンクやダウンタイムについて心配する必要はありません。
SSISは、懸念の分離を適切に処理します。これは独立したパッケージであり、SQL Serverエージェントと共に使用すると、毎晩スケジュールしたり、オンデマンドで実行したりできます。