Exporter (0) Imprimer
Développer tout

Vue d'ensemble de la copie des journaux de transaction

La copie des journaux de transaction permet d'envoyer automatiquement les sauvegardes du journal des transactions à partir d'une base de données primaire sur une instance du serveur principal vers une ou plusieurs bases de données secondaires sur des instances distinctes du serveur secondaire. Les sauvegardes du journal des transactions sont appliquées individuellement à chacune des bases de données secondaires. Une troisième instance de serveur facultatif, appelée serveur moniteur, enregistre l'historique et l'état des opérations de sauvegarde ainsi que de restauration, puis déclenche éventuellement des alertes si ces opérations ne sont pas effectuées selon la planification établie.

La copie des journaux de transaction comprend trois opérations :

  1. sauvegarde du journal des transactions au niveau de l'instance du serveur principal ;

  2. copie du fichier du journal des transactions sur l'instance du serveur secondaire ;

  3. restauration de la sauvegarde du journal sur l'instance du serveur secondaire.

Le journal peut être envoyé à plusieurs instances de serveur secondaire. Dans ce cas, les opérations 2 et 3 sont répétées pour chaque instance de serveur secondaire.

Une configuration de la copie des journaux de transaction ne bascule pas automatiquement du serveur principal au serveur secondaire. Si la base de données primaire devient indisponible, toute base de données secondaire peut être mise en ligne manuellement.

Vous pouvez utiliser une base de données secondaire pour générer des rapports. Pour plus d'informations, consultez Utilisation de serveurs secondaires pour le traitement des requêtes.

En outre, vous pouvez configurer des alertes pour votre configuration de copie des journaux de transaction.

Dans une configuration de copie des journaux de transaction, le serveur principal est l'instance du moteur de base de données SQL Server qui est votre serveur de production. La base de données primaire est celle située sur le serveur principal que vous souhaitez sauvegarder sur un autre serveur. Toute l'administration de la configuration de la copie des journaux de transaction à l'aide de SQL Server Management Studio s'exécute à partir de la base de données primaire.

La base de données primaire doit utiliser le mode de récupération complète ou de récupération utilisant les journaux de transactions ; le basculement de la base de données vers une récupération simple empêcherait toute copie des journaux de transaction.

Dans une configuration de copie des journaux de transaction, le serveur secondaire est celui sur lequel vous souhaitez conserver une copie de secours semi-automatique de votre base de données primaire. Un serveur secondaire peut contenir des copies de sauvegarde de bases de données provenant de plusieurs serveurs principaux différents. Par exemple, le service d'une entreprise peut disposer de cinq serveurs, chacun d'entre eux utilisant un système de bases de données adapté aux besoins. Il est recommandé dans ce cas d'utiliser un seul serveur secondaire plutôt que cinq serveurs secondaires distincts. Les sauvegardes de base de données des cinq systèmes principaux peuvent être chargées sur l'unique système de sauvegarde, ce qui permet de réduire le nombre de ressources nécessaires et de limiter les coûts. Il est peu probable que plusieurs systèmes principaux tombent en panne en même temps. De plus, le serveur secondaire peut être plus puissant que les serveurs principaux, afin de parer à l'éventualité (à faible probabilité) d'une panne de plusieurs serveurs principaux en même temps.

La base de données secondaire doit être initialisée en restaurant une sauvegarde complète de la base de données primaire. La restauration peut être exécutée à l'aide de l'option NORECOVERY ou STANDBY. Cette opération peut s'effectuer manuellement ou via SQL Server Management Studio.

Le serveur moniteur facultatif assure le suivi de tous les détails de la copie des journaux de transaction, tels que :

  • le jour et l'heure de la dernière sauvegarde du journal des transactions de la base de données primaire ;

  • le jour et l'heure de la dernière copie ou restauration des fichiers de sauvegarde par les serveurs secondaires ;

  • les informations concernant les alertes éventuelles d'échec de la sauvegarde.

Le serveur moniteur doit se trouver sur un serveur distinct du serveur principal ou secondaire afin d'éviter toute perte d'informations essentielles et toute interruption de la surveillance en cas de perte du serveur principal ou secondaire. Un serveur moniteur unique peut surveiller plusieurs configurations de la copie des journaux de transaction. Dans ce cas, toutes celles qui utilisent ce serveur moniteur doivent partager un travail d'alerte unique.

ImportantImportant

Une fois que le serveur moniteur a été configuré, il ne peut pas être modifié sans suppression préalable de la copie des journaux de transaction.

Pour plus d'informations, consultez Analyse de l'envoi de journaux.

La copie des journaux de transaction implique quatre opérations qui sont gérées par des travaux dédiés de l'Agent SQL Server. Ces opérations incluent le travail de sauvegarde, le travail de copie, le travail de restauration et le travail d'alerte.

L'utilisateur contrôle à quelle fréquence les sauvegardes du journal sont effectuées, à quelle fréquence elles sont copiées sur chaque serveur secondaire et à quelle fréquence elles sont appliquées à la base de données secondaire. Pour réduire le travail requis pour mettre en ligne un serveur secondaire, par exemple après une défaillance du système de production, vous pouvez copier et restaurer chaque sauvegarde du journal des transactions peu de temps après sa création. Vous pouvez également, peut-être sur un deuxième serveur secondaire, retarder l'application des sauvegardes du journal des transactions à la base de données secondaire. Ce retard ouvre un intervalle pendant lequel vous pouvez remarquer une défaillance sur le serveur principal et y répondre, comme par exemple la suppression accidentelle de données essentielles.

Travail de sauvegarde

Un travail de sauvegarde est créé pour chaque base de données primaire sur l'instance du serveur principal. Il exécute l'opération de sauvegarde, enregistre l'historique sur le serveur local et sur le serveur moniteur, puis supprime les fichiers de sauvegarde et informations d'historiques obsolètes. Par défaut, ce travail s'exécute toutes les 15 minutes, mais l'intervalle peut être personnalisé.

Si la copie des journaux de transaction est activée, la catégorie de travaux de l'Agent SQL Server « Sauvegarde de l'envoi de journaux » est créée sur l'instance du serveur principal.

SQL Server 2008 Enterprise et versions ultérieures prennent en charge la compression de la sauvegarde. Lorsque vous créez une configuration de la copie des journaux de transaction, vous pouvez contrôler le comportement de compression de la sauvegarde pour les sauvegardes de journaux. Pour plus d'informations, consultez Compression de sauvegardes (SQL Server).

Travail de copie

Un travail de copie est créé sur chaque instance du serveur secondaire dans une configuration de la copie des journaux de transaction. Ce travail copie les fichiers de sauvegarde à partir du serveur principal vers une destination configurable sur le serveur secondaire, puis enregistre l'historique sur le serveur secondaire ainsi que sur le serveur moniteur. La planification du travail de copie, qui est personnalisable, doit être semblable à la planification de sauvegarde.

Si la copie des journaux de transaction est activée, la catégorie de travaux de l'Agent SQL Server « Copie des journaux » est créée sur l'instance du serveur secondaire.

Travail de restauration

Un travail de restauration est créé sur l'instance du serveur secondaire pour chaque configuration de la copie des journaux de transaction. Ce travail restaure les fichiers de sauvegarde copiés dans les bases de données secondaires. Il enregistre l'historique sur le serveur local et sur le serveur moniteur, puis supprime les fichiers et informations d'historiques obsolètes. La catégorie de travaux de l'Agent SQL Server « Restauration de la copie des journaux de transaction » est créée sur l'instance du serveur secondaire si la copie des journaux de transaction est activée.

Sur une instance du serveur secondaire donnée, le travail de restauration peut être planifié aussi fréquemment que le travail de copie ou il peut être retardé. La planification de ces travaux selon une même fréquence permet de conserver la base de données secondaire aussi étroitement alignée avec la base de données primaire que possible, afin de créer une base de données de secours semi-automatique.

À l'inverse, retarder des travaux de restauration, éventuellement de plusieurs heures, peut être utile en cas de grave erreur de l'utilisateur, telle que la suppression inappropriée d'une table ou d'une ligne de table. Si l'heure de l'erreur est connue, vous pouvez avancer cette base de données secondaire jusqu'à une heure légèrement antérieure à celle de l'erreur. Vous pouvez alors exporter les données perdues et les importer de nouveau dans la base de données primaire.

Travail d'alerte

Si un serveur moniteur est utilisé, un travail d'alerte est créé sur l'instance du serveur moniteur. Ce travail d'alerte est partagé par les bases de données primaire et secondaire de toutes les configurations de copie des journaux de transaction à l'aide de cette instance du serveur moniteur. Toute modification apportée au travail d'alerte (par exemple la replanification, la désactivation ou l'activation du travail) affecte toutes les bases de données qui utilisent ce serveur moniteur. Ce travail déclenche des alertes (que vous devez numéroter) pour les bases de données primaire et secondaire lorsque les opérations de sauvegarde et de restauration ne se sont pas achevées correctement dans les seuils spécifiés. Vous devez configurer ces alertes afin qu'un opérateur reçoive une notification en cas d'échec de la copie des journaux de transaction. La catégorie de travaux de l'Agent SQL Server « Alerte de la copie des journaux de transaction » est créée sur l'instance du serveur moniteur si la copie des journaux de transaction est activée.

Si aucun serveur moniteur n'est utilisé, les travaux d'alerte sont créés localement sur l'instance du serveur principal et sur chaque instance du serveur secondaire. Le travail d'alerte de l'instance du serveur principal déclenche des erreurs lorsque les opérations de sauvegarde ne se sont pas achevées correctement dans un seuil spécifié. Le travail d'alerte de l'instance du serveur secondaire déclenche des erreurs lorsque les opérations de copie et de restauration locales ne se sont pas achevées correctement dans un seuil spécifié.

La figure ci-dessous illustre une configuration de la copie des journaux de transaction avec une instance du serveur principal, trois instances du serveur secondaire et une instance de serveur moniteur. La figure illustre les étapes des travaux de sauvegarde, copie et restauration :

  1. L'instance du serveur principal effectue le travail de sauvegarde pour sauvegarder le journal des transactions sur la base de données primaire. Cette instance de serveur place ensuite la sauvegarde du journal dans un fichier journal primaire de sauvegarde, qu'il envoie vers le dossier de sauvegarde. Dans cette figure, le dossier de sauvegarde se trouve dans un répertoire partagé — le partage de sauvegarde.

  2. Chacune des trois instances du serveur secondaire effectue son propre travail de copie pour copier le fichier journal primaire de sauvegarde dans son dossier local de destination propre.

  3. Chaque instance du serveur secondaire effectue son propre travail de restauration pour restaurer la sauvegarde du journal à partir du dossier local de destination vers la base de données secondaire locale.

Les instances des serveurs principal et secondaire envoient leur propre historique et leur propre état vers l'instance du serveur moniteur.

Configuration affichant les travaux de sauvegarde, de copie & de restauration

Pour activer la copie des journaux de transaction

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft