Comment SQL Server peut-il envoyer un message d'erreur par courrier électronique lorsqu'un éditeur de réplication ne parvient pas à se connecter à un système d'abonné

Question

Nous avons configuré plusieurs sites distants pour la réplication SQL Server 2005. Parfois, l'éditeur ne parvient pas à se répliquer pour diverses raisons, par exemple

.

1) problèmes de réseau,

2) arrêts incorrects de l'abonné,

3) changer les mots de passe du domaine,

4) modification des mots de passe SQL,

5) échec de l'activation du système d'abonné.

Existe-t-il un moyen quelconque pour que le serveur SQL envoie un courrier électronique à l'administrateur lorsque cela se produit afin qu'il puisse vérifier?

Merci, Chak.

Answer 1

La façon dont je gère généralement cette situation consiste à modifier le (s) travail (s) Agent (s) responsable (s) du démarrage / de l'exécution des agents de réplication (en fonction de votre topologie de réplication, vous en aurez une variété à des emplacements potentiellement différents). Ajoutez simplement une étape de travail au (x) travail (s) d’agent approprié (par exemple, un agent de lecture de journal, un agent de distribution, un agent de fusion, un agent de file d’attente, etc.) après "Agent d'exécution". étape exécutée si / quand cette étape est terminée / échoue (selon que vous utilisez ou non une planification continue).

Par exemple, si j'ai une configuration de publication push unidirectionnelle transactionnelle, l'agent de distribution s'exécutera sur le serveur de distribution. Si je me connecte au serveur de distribution et que je trouve le travail SQL Agent chargé de l'exécution de l'agent de distribution pour cette publication, je peux le modifier et ajouter une étape permettant d'envoyer un courrier électronique à un groupe particulier si l'option "Agent d'exécution" est activée. l'étape échoue / se termine. Si j'utilise une planification de réplication continue, j'ajouterai simplement l'étape à un e-mail si l'option < exécuter l'agent " l’étape se termine (car je souhaite être averti si l’agent s’arrête pour une raison quelconque). Si j'utilise une planification non continue, l'étape de messagerie peut être exécutée uniquement en cas d'échec de l'agent & run; agent " étape. Vous pouvez même configurer ce & email; email " étape pour envoyer un e-mail, suspendez un instant, puis essayez de redémarrer l’agent automatiquement (en configurant simplement l’étape pour "passer à l’étape 1" en cas de succès ").

Voici une capture d'écran illustrant les étapes d'un travail d'agent de distribution configuré comme indiqué ci-dessus:

Vous remarquerez dans l'illustration ci-dessus que j'ai ajouté une étape intitulée "Avertir, suspendre, réessayer". qui sera exécuté chaque fois que l'agent s'arrêtera (succès ou échec - ceci est intentionnel, car j'utilise un calendrier de réplication continu et je veux simplement savoir quand l'agent de distribution ne s'exécute pas, quelle qu'en soit la raison). Cette étape consiste essentiellement à envoyer un courrier électronique à un groupe spécifique, à attendre une minute ou deux, puis à redémarrer l'agent. Vous pouvez ajouter du code pour faire tout ce que vous voulez, y compris la journalisation, le redémarrage seulement un certain nombre de fois dans une tranche de temps donnée, etc. Il est facilement scripté et reproductible pour un nombre quelconque d'agents, de publications, etc. (J'ai des scripts pour garantir toute nouvelle Dans n'importe quel type de topologie, l'agent de réplication inclut ce type de configuration. Il suffit ensuite de les ajouter à un outil d'édition ou de planifier leur exécution, en fonction de la manière dont vous déployez votre environnement).

Answer 2

En ce qui concerne la détection des problèmes d'agent, vous souhaitez savoir quand le lecteur de journal et le distributeur sont arrêtés. Le mien est aussi une réplication continue comme chadhoc, mais je trouve plus facile d’utiliser une alerte pour me dire si les agents sont arrêtés.

USE [msdb] 
GO 
EXEC msdb.dbo.sp_add_alert  
    @name=N'Distribution agent stopped',   
    @message_id=0,  
    @severity=0,  
    @enabled=1,   
    @delay_between_responses=2160, 
    @include_event_description_in=1,   
    @category_name=N'[Uncategorized]',  
    @performance_condition=N'MSSQL$MYDATABASE:Replication Agents|Running|Distribution|=|0', 
    @job_id=N'00000000-0000-0000-0000-000000000000' 
GO 
EXEC msdb.dbo.sp_update_notification 
    @alert_name=N'Distribution agent stopped',   
    @operator_name=N'Amit',  
    @notification_method = 1 

Les erreurs de validation / synchronisation ne sont pas si simples à détecter. Vous pouvez configurer un travail nocturne pour exécuter sp_publication_validation et configurez une autre alerte sur "Validation en échec".

Answer 3

Je ne connais pas grand-chose à la réplication, mais sp_readerrorlog est un très procédure stockée utile vous permettant d'accéder aux journaux de la base de données depuis l'instance de base de données. Si nécessaire, cela peut vous permettre de répondre de manière plus appropriée en fonction des messages d'erreur spécifiques plutôt que de simplement des branches SUCCESS / FAIL à partir d'un travail d'agent. Vous pouvez bien sûr également envoyer un e-mail directement à partir d'un processus stocké, en personnalisant les destinataires en fonction de la personne qui peut le mieux répondre à l'erreur (ou des coordinateurs de l'équipe de jour, de nuit ou de nuit, par exemple).

Par ailleurs, il serait peut-être plus approprié d’envoyer un courrier électronique si le travail aboutit plutôt qu’échoue, étant donné que vos défaillances potentielles incluent la déconnexion du réseau. Vous voudrez peut-être configurer une règle d’échange pour surveiller cette boîte de réception et émettre une notification d’erreur à votre administrateur si elle ne reçoit pas le message de succès attendu ... les humains sont très efficaces pour filtrer les stimulus constants et le manque de sécurité. un message de réussite pourrait facilement être manqué. En revanche, l'échange est toujours (généralement) vigilant.