Sauvegarde / restauration de SQL Server par rapport à détacher / attacher

Question

J'ai une base de données contenant les données les plus récentes et je souhaite répliquer le contenu de la base de données sur d'autres serveurs. Pour des raisons non techniques, je ne peux pas utiliser directement la fonction de réplication ni la fonction de synchronisation pour la synchronisation avec d'autres instances de SQL Server.

Maintenant, j'ai deux solutions et je souhaite connaître les avantages et les inconvénients de chaque solution. Merci!

Solution 1: détachez la base de données source contenant les données les plus récentes, puis copiez-la sur les serveurs de destination ayant besoin des données les plus récentes, puis attachez la base de données aux serveurs de destination;

Solution 2: effectuez une sauvegarde complète du serveur source pour l'ensemble de la base de données, puis copiez les données sur les serveurs de destination et effectuez une récupération complète du côté du serveur de destination.

merci d'avance, George

Answer 1

L'option Détacher / Attacher est souvent plus rapide que d'effectuer une sauvegarde car il n'est pas nécessaire de créer un nouveau fichier. Par conséquent, le temps écoulé entre les serveurs A et B correspond presque uniquement à la copie des fichiers.

L'option Sauvegarder / Restaurer vous permet d'effectuer une sauvegarde complète, de la restaurer, puis d'effectuer une sauvegarde différentielle, ce qui signifie que votre temps d'arrêt peut être réduit entre les deux.

Si vous recherchez une solution de réplication de données, cela signifie-t-il que vous souhaitez que la base de données soit fonctionnelle aux deux emplacements? Dans ce cas, vous voudrez probablement l'option de sauvegarde / restauration car cela laissera la base de données actuelle entièrement fonctionnelle.

EDIT: Juste pour clarifier quelques points. Par temps d'arrêt, je veux dire que si vous migrez une base de données d'un serveur à un autre, vous empêcherez généralement les utilisateurs de l'utiliser pendant son transit. Par conséquent, à partir du & stop; stop " pointez sur le serveur A jusqu’à "Démarrer". point sur le serveur B cela pourrait être considéré comme un temps d'arrêt. Sinon, les actions effectuées sur la base de données sur le serveur A pendant le transit ne seront pas répliquées sur le serveur B.

En ce qui concerne le "créer un nouveau fichier". Si vous détachez une base de données, vous pouvez copier le fichier MDF immédiatement. Il est déjà prêt à être copié. Toutefois, si vous effectuez une sauvegarde, vous devez attendre la création du fichier .BAK, puis le déplacer vers son nouvel emplacement pour une restauration. Encore une fois, tout se résume à ceci est-il une copie instantanée ou une migration.

Answer 2

La sauvegarde et la restauration ont beaucoup plus de sens, même si vous pouvez gagner quelques minutes de plus avec une option de détachement. Vous devez mettre hors ligne la base de données d'origine (déconnecter tout le monde) avant un détachement, puis la base de données est indisponible jusqu'à ce que vous vous rattachez. Vous devez également garder une trace de tous les fichiers, alors qu'avec une sauvegarde, tous les fichiers sont regroupés. Et avec les versions les plus récentes de SQL Server, les sauvegardes sont compressées.

Et juste pour corriger quelque chose: les sauvegardes de base de données et les sauvegardes différentielles ne tronquent pas le journal et ne cassent pas la chaîne du journal.

De plus, la fonctionnalité COPY_ONLY n’a d’importance que pour la base différentielle, pas pour le journal. Toutes les sauvegardes de journaux peuvent être appliquées en séquence à partir de n'importe quelle sauvegarde, à condition que la chaîne de journaux ne soit pas interrompue. Il y a une légère différence avec le point d'archivage, mais je ne vois pas où cela compte.

Answer 3

La solution 2 serait mon choix ... Principalement parce qu’elle ne créera aucun temps mort sur la base de données source. Le seul inconvénient que je puisse constater est que, selon le modèle de récupération de la base de données, le journal des transactions sera tronqué, ce qui signifie que si vous souhaitez restaurer des données à partir du journal des transactions que vous voulez remplir, vous devez utiliser votre fichier de sauvegarde.

EDIT: trouvé un bon lien; http://sql-server-performance.com/Community/ forums / p / 5838 / 35573.aspx