Mise en miroir et envoi de journaux dans SQL Server 2005

Question

Dans ce scénario, je souhaiterais connaître le pour et le contre de la mise en miroir de bases de données par rapport à l'envoi de journaux: nous devons configurer une situation de sauvegarde de base de données dans laquelle il existe exactement un serveur secondaire qui n'a pas besoin d'être détecté automatiquement. primaire échoue. Récupérer et commencer avec le secondaire ne devrait cependant pas prendre trop de temps.

Answer 1

Mise en miroir

• La mise en miroir de bases de données est limitée à deux serveurs.
• La mise en miroir avec un serveur témoin permet la haute disponibilité et le basculement automatique.
• Vous pouvez configurer votre chaîne DSN de manière à ce qu'elle contienne les deux serveurs en miroir afin que rien ne les empêche de basculer.
• La mise en miroir de votre base de données en miroir est impossible. Il est en mode de synchronisation / restauration.
• La mise en miroir avec l'édition standard de SQL Server 2005 n'est pas adaptée à l'équilibrage de charge (voir la phrase ci-dessus)

Envoi de journaux

• Vous pouvez vous connecter à plusieurs serveurs.
• Les envois de journaux sont aussi actuels que la fréquence d'exécution du travail. Si vous expédiez des journaux toutes les 15 minutes, le serveur secondaire peut atteindre 15 minutes. Faire en sorte qu’il s’agisse plutôt d’une mise en veille chaleureuse.
• Vous pouvez laisser la base de données en lecture seule pendant la mise à jour. Bon pour les serveurs de reporting.
• Bon pour la reprise après sinistre

Answer 2

À des fins de sauvegarde, je recommanderais la mise en miroir: elle conserve une copie de votre base de données à jour en toute simplicité. Si vous n'avez pas besoin de basculement automatique, vous n'avez besoin que de deux serveurs / instances. Notez que le mode Haute performance est uniquement disponible dans l'édition Enterprice (sp)!

Answer 3

Le passage à la base de données secondaire prend plus de temps avec l'envoi des journaux, mais ce n'est pas si mal. Vous devrez copier manuellement les fichiers de sauvegarde non copiés, appliquer les sauvegardes du journal des transactions à la base de données secondaire, récupérer la base de données secondaire et changer son rôle en principal. Si les anciennes bases de données primaires sont accessibles, vous devez sauvegarder son journal de transactions avant de commencer. Échouer avec la mise en miroir est un peu plus simple et peut être fait automatiquement si vous utilisez le mode Haute disponibilité. Même si vous utilisez le mode Haute performance, l'opération reste une instruction.