データベースを（全体として）別のサーバーに転送して、別のテスト環境をセットアップするために複製データベースを作成する必要があります。
次の2つの選択肢があります。
- ソースサーバーで完全バックアップを作成/ターゲットサーバーで復元。
- 移行元サーバーで切断/移行先サーバーで接続。
要件に応じた2つのソリューションの長所と短所は何ですか？
SQL Server 2008 Enterpriseを使用しています。
データベースを（全体として）別のサーバーに転送して、別のテスト環境をセットアップするために複製データベースを作成する必要があります。
次の2つの選択肢があります。
要件に応じた2つのソリューションの長所と短所は何ですか？
SQL Server 2008 Enterpriseを使用しています。
回答:
通常、バックアップ/復元が選択方法です。ほとんどの状況でより高速になります。
一貫して使用することもできますし、実稼働環境でもテストできます。
バックアップ/復元とデタッチ/アタッチが記載されているこの関連する質問も参照してください。
SQL Server移行の復元バックアップとデータおよびログファイルのコピー
WITH COPY_ONLY既存のメンテナンスプランのバックアップチェーンを壊さないように、バックアップにオプションを追加してください。
バックアップ/復元する場合は、バックアップ中にWITH COPY_ONLYオプションを使用して、既存のメンテナンスプランのバックアップチェーンが破損しないようにします。
.bakファイルは十分に圧縮されるため、バックアップを作成することにした場合、移動する前にバックアップを圧縮すると転送時間が節約される場合があります。
元のデータベースが操作可能な状態のままになるため、バックアップ/復元に進みます。
特に、「本番からテストへ」の変換を行う場合、本番データベースがオンラインのままであることが重要です。
バックアップ/復元もより安全なオプションです。デタッチの開始、コピー、アタッチなどの間にファイルが破損した場合はどうなりますか？少なくともバックアップを実行してファイルが破損した場合は、最初からやり直すことができます。デタッチで発生した場合、データベースは失われます。
また、私にとって（他の何よりも気持ちがいいのですが）、バックアップ/復元は「毎日の仕事」ですが、デタッチ/アタッチは例外的な状況で行うことです。私がこのアイデアをどこで得たのか私に尋ねないでください;-)
バックアップ/復元の「復元」の部分には常に問題があります。最終的にそれをあきらめ、それ以来切り離し/コピー/添付しているので、詳細を引用することはできません。
デタッチに関する唯一のことは、DBMSがデータベースも削除しないことを確認するために持っていることです。これは起こりましたが、見た目は良くありません。
copy_onlyDOSシェルからこの方法を使用したバックアップをお勧めします（トランザクションログを中断しないようにするため）。
C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Backupディレクトリから実行：
backup.bat SQLDBNAMEbackup.bat含む場所（読みやすくするために改行を追加）：
sqlcmd.exe -U username -P xxxxxxx -S SQL-SERVERNAME
-Q "BACKUP DATABASE %1 TO DISK = '%1_COPYONLY.BAK' WITH COPY_ONLY,INIT;"