Ce moniteur détecte quand la destination d'une copie des journaux de transaction n'a pas eu de journal restauré avant le seuil défini dans le cadre de la configuration de la copie des journaux de transaction.
Notez que la copie des journaux de transaction n'est pas prise en charge par les éditions de SQL Server Express.
Knowledge Base article:
Récapitulatif
Ce moniteur détecte quand la destination d'une copie des journaux de transaction n'a pas eu de journal restauré avant le seuil défini dans le cadre de la configuration de la copie des journaux de transaction. Quand cette situation se produit, le moniteur passe à l'état critique. Quand les restaurations de journal reprennent dans les seuils définis, le moniteur retourne à l'état sain. Par défaut, ce moniteur génère des alertes quand il est dans un état d'erreur.
Causes
La copie des journaux de transaction n'est pas synchronisée au-delà du seuil de restauration. Le seuil de restauration est le nombre de minutes pouvant s'écouler entre les opérations de restauration avant qu'un message soit généré.
Résolutions
Pour résoudre ce problème :
Assurez-vous que le service Agent SQL Server est en cours d'exécution pour l'instance du serveur secondaire et que le travail de restauration pour cette base de données secondaire est activé et est planifié pour s'exécuter à la fréquence appropriée.
Le travail de restauration sur le serveur secondaire est peut-être défectueux. Dans ce cas, examinez l'historique du travail de restauration pour rechercher la cause.
Le travail de restauration de copie des journaux de transaction, qui s'exécute sur l'instance du serveur secondaire, ne peut peut-être pas se connecter à l'instance du serveur moniteur pour mettre à jour la table log_shipping_monitor_secondary. Il peut s'agir d'un problème d'authentification entre l'instance du serveur moniteur et l'instance du serveur secondaire.
Le seuil d'alerte de sauvegarde a peut-être une valeur incorrecte. Idéalement, cette valeur est définie sur au moins trois fois la fréquence du travail de restauration. Si vous changez la fréquence du travail de restauration une fois la copie des journaux de transaction configurée et opérationnelle, vous devez mettre à jour la valeur du seuil d'alerte de sauvegarde en conséquence.
Quand l'instance du serveur moniteur est mise hors connexion, puis remise en ligne, la table log_shipping_monitor_secondary n'est pas mise à jour avec les valeurs actuelles avant l'exécution du travail de message d'alerte. L'erreur 14421 peut être déclenchée quand un travail de restauration est effectué et retourne le message « Impossible de trouver un fichier de sauvegarde du journal pouvant être appliqué à la base de données secondaire ». Quand cela se produit, la durée de restauration n'est pas mise à jour. La cause de l'erreur dans ce cas peut être un problème lié au travail de copie.
Pour mettre à jour les tables du moniteur avec les dernières données de la base de données secondaire, exécutez sp_refresh_log_shipping_monitor sur l'instance du serveur secondaire.
La date ou l'heure est incorrecte sur l'instance du serveur secondaire ou du serveur moniteur. Ceci peut également générer des messages d'alerte. Il est possible que la date ou l'heure système ait été modifiée sur l'une des deux instances.
Remarque : Une différence de fuseaux horaires sur les deux instances de serveur ne doit pas générer de problème.
Externe
Rubrique sur la copie des journaux de transaction dans la documentation en ligne de SQL Server :
Home
FRA