À propos de l’expédition de journaux (SQL Server)

  • Article

S'applique à : SQL Server

SQL Server 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.

Avantages

  • Fournit une solution de récupération d'urgence pour une base de données primaire unique et une ou plusieurs bases de données secondaires, chacune sur une instance distincte de SQL Server.

  • Prend en charge un accès limité en lecture seule aux bases de données secondaires (pendant l'intervalle entre des travaux de restauration).

  • Possibilité de spécifier un délai défini par l'utilisateur entre la sauvegarde du fichier journal de la base de données primaire par le serveur principal et la restauration (application) de la sauvegarde du fichier journal par les serveurs secondaires. Un délai plus long peut s'avérer utile en cas, par exemple, de modification accidentelle des données sur la base de données primaire. Si la modification accidentelle est remarquée rapidement, un délai peut vous permettre de récupérer à partir de la base de données secondaire les données n'ayant pas encore été modifiées, avant que la modification n'y soit reflétée.

Termes et définitions

  • serveur principal: l’instance de SQL Server qui est votre serveur de production.

  • base de données principale: la base de données du 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.

  • serveur secondaire: l’instance de SQL Server où vous souhaitez conserver une copie de secours de votre base de données principale.

  • base de données secondaire: La copie de secours à chaud de la base de données primaire. La base de données secondaire peut être dans l'état RECOVERING ou STANDBY, dans lequel elle est disponible pour un accès limité en lecture seule.

  • moniteur de serveur: une instance optionnelle de SQL Server qui suit tous les détails de l’expédition des journaux, y compris :

    • 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.

    Important

    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.

  • travail de sauvegarde: travail de SQL Server Agent qui exécute l’opération de sauvegarde, enregistre l’historique sur le serveur local et sur le serveur de surveillance. Il supprime également les anciens fichiers de sauvegarde et les informations d’historique. Si la copie des journaux de transaction est activée, la catégorie de travaux « Sauvegarde de l'envoi de journaux » est créée sur l'instance du serveur principal.

  • tâche de copie: une tâche de l’agent SQL Server qui copie les fichiers de sauvegarde du serveur primaire vers une destination configurable sur le serveur secondaire et enregistre l’historique sur le serveur secondaire et le serveur de surveillance. Si la copie des journaux de transaction est activée sur une base de données, la catégorie de travaux « Copie des journaux de transaction » est créée sur chaque serveur secondaire dans une configuration de la copie des journaux de transaction.

  • tâche de restauration : une tâche de l’agent SQL Server qui 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. Lorsque la copie des journaux de transaction est activée sur une base de données, la catégorie de travaux « Restauration de la copie des journaux de transaction » est créée sur l'instance du serveur secondaire.

  • tâche d’alerte: une tâche de l’agent SQL Server qui déclenche des alertes pour les bases de données primaires et secondaires lorsqu’une opération de sauvegarde ou de restauration ne s’achève pas avec succès dans un délai spécifié. Lorsque la copie des journaux de transaction est activée sur une base de données, la catégorie de travaux « Alerte de la copie des journaux de transaction » est créée sur l'instance du serveur moniteur.

    Conseil

    Pour chaque alerte, vous devez spécifier un numéro d'alerte. En outre, veillez à configurer l'alerte de manière à avertir un opérateur lorsqu'une alerte est générée.

Vue d’ensemble de l’expédition des journaux

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.

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

Une configuration typique d’expédition de journaux

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 exécutées par les tâches de sauvegarde, de copie et de restauration, comme suit :

  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.

Diagramme de configuration affichant les travaux de sauvegarde, copie et de restauration.

Interopérabilité

La copie des journaux de transaction peut être utilisée avec les fonctionnalités ou les composants de SQL Serversuivants :

Notes

Groupes de disponibilité Always On et la mise en miroir de bases de données s’excluent mutuellement. Une base de données configurée pour une de ces fonctionnalités ne peut pas être configurée pour l'autre.

Attention

Problème connu : pour les bases de données avec des tables mémoire optimisées, l’exécution d’une sauvegarde de journal transactionnelle sans récupération, puis l’exécution ultérieure d’une restauration du journal des transactions avec récupération, peut entraîner un processus de restauration de base de données non satisfait. Ce problème peut également affecter la fonctionnalité d’expédition de journaux. Pour contourner ce problème, l’instance SQL Server peut être redémarrée avant de lancer le processus de restauration.

Contenu connexe