web-dev-qa-db-ja.com

接続/切り離しとバックアップ/復元

データベースを(全体として)別のサーバーに転送して、別のテスト環境をセットアップするための複製データベースを作成する必要があります。

私には2つの選択肢があります。

  1. ソースサーバーで完全バックアップを作成し、宛先サーバーで復元します。
  2. ソースサーバーでデタッチ/デスティネーションサーバーでアタッチ。

私の要件によると、2つのソリューションの長所と短所は何ですか?

SQL Server 2008 Enterpriseを使用しています。

14
George2

バックアップ/復元は通常、選択する方法です。それはほとんどの状況でより速くなります。

また、本番環境でのテストにも使用できます。

この関連する質問も参照してください。バックアップ/復元とデタッチ/アタッチが言及されています。

SQL Server Migration Restoreバックアップvsコピーデータとログファイル

バックアップにWITH COPY_ONLYオプションを追加して、既存の保守計画のバックアップチェーンが壊れないようにしてください。

12
gbn
  1. データベースをデタッチすると、オフラインになります。別のサーバーにコピーする間、データベースをオンラインのままにする必要がある場合は、バックアップを作成してください。
  2. バックアップファイル(.bak)の移動と復元は、複数のmdf/ldfファイルの移動と添付(データベースをデタッチした場合のように)よりも簡単で簡単な場合があります。
  3. 紙の上では、データベースのデタッチ/アタッチは技術的には速いかもしれませんが、実際には、バックアップ/復元はより速く簡単です。データベースをデタッチするときは、最初に元のデータベースをオフラインにして(全員とすべてを切断)、その後、再接続するまでデータベースを使用できません。また、すべてのファイルを追跡する必要がありますが、バックアップを使用すると、すべてのファイルがグループ化されます。

バックアップ/復元する場合は、バックアップ中にWITH COPY_ONLYオプションを使用して、既存の保守計画のバックアップチェーンが壊れていないことを確認します。

.bakファイルは適切に圧縮されるため、バックアップを作成することにした場合は、移動する前にバックアップを圧縮することで、転送時間を節約できます。

6
Bob Black

元のデータベースを操作可能な状態にしておくので、バックアップ/復元を行います。

特に、「本番からテスト」への変換を行う場合は、本番データベースをオンラインにしておくことが重要です。

バックアップ/復元もsaferオプションです。デタッチ、コピー、アタッチなどの開始の間にファイルが破損するとどうなりますか?少なくともバックアップを実行してファイルが破損した場合は、最初からやり直すことができます。デタッチでそれが発生した場合、データベースは失われます。

また、私にとっては(他の何よりも感じがいいですが)、バックアップ/復元は「日常の仕事」ですが、分離/アタッチは例外的な状況で行うものです。私がどこでこのアイデアを得たのか私に尋ねないでください;-)

4
Brimstedt

バックアップ/復元の「復元」の部分で常に問題がありました。最終的にそれをあきらめ、それ以来、切り離し/コピー/アタッチを行ってきたので、詳細を引用することはできません。

デタッチについての唯一のことは、DBMSがデータベースも削除しないことを確認する必要があることです。これが起こった、そしてそれはかなりの光景ではありません。

1
Ripped Off

DOSシェルからこの方法を使用してcopy_onlyバックアップをお勧めします(トランザクションログを中断しないように)

C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Backupディレクトリから実行:

backup.bat SQLDBNAME

ここで、backup.batには(読みやすくするために改行が追加されています)が含まれています。

sqlcmd.exe -U username -P xxxxxxx -S SQL-SERVERNAME 
    -Q "BACKUP DATABASE %1 TO DISK = '%1_COPYONLY.BAK' WITH COPY_ONLY,INIT;"
1
djangofan