Attacher / détacher ou sauvegarder / restaurer

14

J'ai besoin de transférer la base de données (dans son ensemble) vers un autre serveur, pour créer une base de données en double pour configurer un autre environnement de test.

J'ai deux choix:

  1. Faire une sauvegarde complète sur le serveur source / restaurer sur le serveur de destination;
  2. Détacher sur le serveur source / attacher sur le serveur de destination.

Quels sont les avantages et les inconvénients des deux solutions selon mes besoins?

J'utilise SQL Server 2008 Enterprise.

sql-server sql-server-2008 backup restore Paul White 9
la source

Réponses:

12

La sauvegarde / restauration devrait normalement être votre méthode de choix. Ce sera plus rapide dans la plupart des situations.

Vous pouvez l'utiliser de manière cohérente, également pour la production à tester également.

Voir également cette question connexe, où la sauvegarde / restauration vs détachement / attachement est mentionnée:

Migration SQL Server restaurer la sauvegarde vs copier les données et les fichiers journaux

Assurez-vous d'ajouter l' WITH COPY_ONLYoption à la sauvegarde afin qu'elle ne casse pas la chaîne de sauvegarde du plan de maintenance existant.

gbn
la source
SQL 2008 Enterprise a introduit la compression de sauvegarde; il est probable que la sauvegarde compressée soit nettement inférieure à 100 Go, et donc plus rapide à écrire / copier / charger qu'à copier sur les MDF / LDF.
Thomas Rushton
6
  1. Le détachement de la base de données la mettra hors ligne. Effectuez une sauvegarde si vous avez besoin que la base de données reste en ligne pendant que vous la copiez sur un autre serveur.
  2. Déplacer et restaurer un fichier de sauvegarde (.bak) peut être plus simple / plus facile que de déplacer et de joindre plusieurs fichiers mdf / ldf (comme vous le feriez si vous détachez la base de données).
  3. Sur le papier, un détachement / attachement de base de données peut être plus rapide techniquement, mais en pratique, une sauvegarde / restauration est susceptible d'être plus rapide et plus facile. Lorsque vous détachez une base de données, vous devez d'abord mettre la base de données d'origine hors ligne (déconnecter tout le monde et tout), puis la base de données n'est pas disponible jusqu'à ce que vous la rattachiez. Vous devez également garder une trace de tous les fichiers, alors qu'avec une sauvegarde, tous les fichiers sont regroupés.

Si vous décidez de sauvegarder / restaurer, utilisez l'option WITH COPY_ONLY pendant la sauvegarde pour vous assurer que la chaîne de sauvegarde d'un plan de maintenance existant n'est pas interrompue.

Un fichier .bak se comprime bien, donc si vous décidez de faire une sauvegarde, la compression de la sauvegarde avant de la déplacer peut économiser du temps de transfert.

Bob Black
la source
4

J'irais pour la sauvegarde / restauration car elle laisse la base de données d'origine dans un état opérationnel.

Surtout si vous effectuez une conversion `` production à tester '', il est important que la base de données de production reste en ligne.

La sauvegarde / restauration est également une option plus sûre : que se passe-t-il si le fichier est corrompu quelque part entre le début du détachement, la copie, la pièce jointe, etc.? Au moins, si vous effectuez une sauvegarde et que le fichier est corrompu, vous pouvez recommencer. Si cela se produit avec un détachement, votre base de données a disparu.

De plus, pour moi (bien que ce soit plus un sentiment qu'autre chose), la sauvegarde / restauration est un "travail quotidien" alors que le détachement / attachement est quelque chose que vous faites dans des circonstances exceptionnelles. Ne me demandez pas où j'ai eu cette idée ;-)

Brimstedt
la source
1

J'ai toujours eu des problèmes avec la partie "restaurer" de la sauvegarde / restauration. Je ne peux pas citer de détails car j'ai finalement abandonné et je détache / copie / attache depuis.

La seule chose à propos de la déconnexion est que vous devez avoir pour vous assurer que le SGBD ne supprimera pas également la base de données. Cela s'est produit, et ce n'est pas une jolie vue.

Arnaqué
la source
5
Le SGBD ne supprimera pas la base de données lors du détachement. Dans quel type de boutique êtes-vous si le détachement supprime des fichiers et que la restauration a des problèmes?
gbn le
@Will: sp_detach_db n'est pas DROP: 2 commandes distinctes et non liées qui doivent être émises séparément. Une base de données détachée ne peut pas être supprimée ou les fichiers supprimés via SQL. Une base de données supprimée ne peut pas être détachée. Détacher n'a pas l'option "supprimer les fichiers" via le code ou via SSMS. Je peux donc justifier mon premier commentaire car il faut délibérément choisir l'option de supprimer les fichiers sur DROP. Ne pas détacher
GBN
1

Je recommande une copy_onlysauvegarde en utilisant cette méthode à partir d'un shell DOS (afin de ne pas interrompre les journaux de transactions) :

Exécuter à partir du C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Backuprépertoire:

backup.bat SQLDBNAME

Où backup.batcontient (saut de ligne ajouté pour plus de lisibilité) :

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