Partager via


Qu’est-ce que la copie des journaux de transaction BizTalk Server ?

BizTalk Server procédures de récupération d’urgence sont conçues autour de l’expédition des journaux BizTalk. La copie des journaux BizTalk simplifie la restauration de la base de données en cas de sinistre en appliquant en permanence les mises à jour du journal des transactions aux bases de données de site de récupération d’urgence.

Bien que la copie des journaux BizTalk soit basée sur des principes similaires à SQL Server la copie des journaux, SQL Server la copie des journaux n’est pas prise en charge pour les bases de données BizTalk Server sauvegardées dans le cadre du travail de sauvegarde BizTalk Server SQL Agent.

Comment fonctionne l’expédition des journaux bizTalk ?

La copie des journaux BizTalk fonctionne de la même manière que SQL Server la copie des journaux. Le groupe de BizTalk Server de production est configuré pour sauvegarder les bases de données BizTalk Server dans un emplacement UNC. Par défaut, le travail De sauvegarde BizTalk SQL Agent effectue une sauvegarde complète toutes les heures et une sauvegarde de journal toutes les 15 minutes. Le travail de sauvegarde BizTalk Server implémente une logique pour démarrer automatiquement une sauvegarde complète en cas d’échec de sauvegarde.

Lorsque les instances de récupération d’urgence SQL Server sont configurées pour la copie des journaux BizTalk, les fichiers de sauvegarde créés par le travail De sauvegarde BizTalk Server SQL Agent sont restaurés sur le site de récupération d’urgence toutes les 15 minutes par défaut. Les fichiers de sauvegarde sont copiés sur le réseau par une commande SQL RESTORE. Les fichiers de sauvegarde complète sont copiés uniquement dans les situations suivantes :

  • Lors de la première configuration de la copie des journaux de transaction BizTalk

  • Lorsqu’une nouvelle base de données est ajoutée au BizTalk Server de sauvegarde.

  • Lorsqu’une défaillance RESTORE se produit sur le site de récupération d’urgence

    Chaque SQL Server instance sur le site de récupération d’urgence est configuré individuellement dans le cadre de la copie des journaux BizTalk pour restaurer des bases de données hébergées sur un instance de base de données de production SQL Server. Lorsqu’un SQL Server instance est configuré pour BizTalk Server la copie des journaux et que le travail BTS Log Shipping Restore Databases est activé, le travail BTS Log Shipping Restore Databases se connecte à la base de données de gestion BizTalk sur le groupe de BizTalk Server de production.

    Comme décrit ci-dessus, lorsque le serveur de destination est configuré pour la première fois, la sauvegarde complète de la base de données est restaurée sur le serveur de destination. La plupart du temps, seuls les journaux d’activité sont restaurés lors de l’exécution du travail bts Log Shipping Restore Databases .

    Lors de l’affichage de la récupération d’urgence SQL Server instances avec SQL Server Management Studio, les bases de données s’affichent dans un état « Chargement ». En effet, le dernier journal d’un jeu de sauvegarde n’est jamais restauré automatiquement. Une fois qu’un nouveau journal est disponible, BizTalk Server copie des journaux restaure l’avant-dernier journal. Lorsqu’un événement de récupération d’urgence se produit et que le site de récupération d’urgence doit être mis en ligne, le dernier journal est restauré à l’aide de la commande STOPATMARK pour récupérer les bases de données et les bases de données ne sont plus affichées comme étant dans un état « Chargement ».