Partager via


Utilisation des alertes pour les événements de l'Agent de réplication

SQL Server Management Studio et l'Agent Microsoft SQL Server permettent de surveiller les événements, par exemple, les événements de l'Agent de réplication, à l'aide d'alertes. L'Agent SQL Server surveille, dans le journal des applications, des événements associés à des alertes. Si un tel événement se produit, l'Agent SQL Server répond automatiquement, en exécutant une tâche que vous avez définie et/ou en envoyant un e-mail ou un message par radio-messagerie à un opérateur spécifié. SQL Server inclut un ensemble d'alertes prédéfinies d'Agents de réplication que vous pouvez configurer pour exécuter une tâche et/ou avertir un opérateur. Pour plus d'informations sur la définition d'une tâche à exécuter, consultez la section « Automatisation d'une réponse à une alerte » de la présente rubrique.

Les alertes suivantes sont installées lorsqu'un ordinateur est configuré en tant que serveur de distribution :

ID du message

Alerte prédéfinie

Condition provoquant le déclenchement de l'alerte

Entrée d'informations supplémentaires dans msbd..sysreplicationalerts

14150

Réplication : Succès de l'Agent

Arrêt normal de l'Agent.

Oui

14151

Réplication : Échec de l'Agent

Arrêt de l'Agent en raison d'une erreur.

Oui

14152

Réplication : Nouvelle tentative de l'Agent

L'agent s'arrête après l'échec du renouvellement d'une opération (l'Agent a rencontré une erreur de type serveur non disponible, interblocage, échec de la connexion, ou dépassement du délai d'attente).

Oui

14157

Réplication : Suppression de l'abonnement expiré

Suppression de l'abonnement expiré

Non

20572

Réplication : Réinitialisation de l'abonnement après échec de la validation

Le travail de réponse « Réinitialiser les abonnements après échec de la validation des données » a réussi à réinitialiser un abonnement.

Non

20574

Réplication : L'Abonné n'a pas réussi la validation des données

L'Agent de distribution ou de fusion n'a pas réussi la validation des données.

Oui

20575

Réplication : L'Abonné a réussi la validation des données

L'Agent de distribution ou de fusion a réussi la validation des données.

Oui

20578

Réplication : Arrêt personnalisé de l'Agent

 

 

22815

Alerte de détection de conflit d'égal à égal

L'Agent de distribution a détecté un conflit lorsqu'il essaie d'appliquer une modification à un nœud d'égal à égal.

Oui

Outre ces alertes, le Moniteur de réplication fournit un ensemble d'avertissements et d'alertes liés à l'état et aux performances. Pour plus d'informations, consultez Définition de seuils et d'avertissements dans le moniteur de réplication. Vous pouvez également définir des alertes pour d'autres événements de réplication à l'aide de l'infrastructure des alertes SQL Server. Pour plus d'informations, consultez Création d'un événement défini par l'utilisateur.

Pour configurer des alertes de réplication prédéfinies

Affichage direct du journal des applications

Pour consulter le journal des applications Windows, utilisez l'Observateur d'événements Microsoft Windows. Le journal des applications comporte les messages d'erreur SQL Server ainsi que des messages se rapportant à toutes les activités de l'ordinateur. À la différence du journal des erreurs SQL Server, chaque démarrage de SQL Server ne crée pas un nouveau journal des applications (chaque session SQL Server écrit des nouveaux événements dans un journal des applications existant) ; en revanche, vous pouvez spécifier la durée de rétention des événements enregistrés. Lorsque vous affichez le journal des applications Windows, vous pouvez filtrer le journal en fonction d'événements spécifiques. Pour plus d'informations, consultez la documentation Windows.

Automatisation d'une réponse à une alerte

La réplication fournit un travail de réponse aux abonnements dont la validation des données échoue ainsi qu'une infrastructure permettant de créer des réponses automatiques supplémentaires aux alertes. Le travail de réponse est intitulé Réinitialiser les abonnements après échec de la validation des données et stocké dans le dossier Travaux de l'Agent SQL Server de SQL Server Management Studio. Pour plus d'informations sur l'activation de ce travail de réponse, consultez Procédure : configurer des alertes de réplication prédéfinies (SQL Server Management Studio). Si certains articles d'une publication transactionnelle ne peuvent pas être validés, le travail de réponse ne réinitialise que ces articles. Si certains articles d'une publication de fusion ne peuvent pas être validés, le travail de réponse réinitialise tous les articles de la publication.

Infrastructure d'automatisation des réponses

Généralement, lorsqu'une alerte survient, la seule information dont vous disposez pour vous aider à comprendre la raison de l'alerte et l'action appropriée à entreprendre, se trouve dans le message d'alerte lui-même. L'analyse de ces informations peut être fastidieuse et sujette à erreurs. La réplication facilite l'automatisation des réponses en fournissant des informations supplémentaires sur l'alerte dans la table système sysreplicationalerts ; les données fournies sont déjà analysées dans une forme facilement utilisable pour les programmes personnalisés.

Si, par exemple, les données de la table Sales.SalesOrderHeader de l'Abonné A ne peuvent pas être validées, SQL Server peut déclencher le message 20574, qui vous avertit de l'échec. Le message que vous recevez peut se présenter comme suit : « L'Abonné 'A' avec un abonnement à l'article 'SalesOrderHeader' de la publication 'MyPublication' n'a pas réussi la validation de données. »

Si vous créez une réponse basée sur le message, vous devez extraire manuellement du message, le nom de l'Abonné, le nom de l'article, le nom de la publication et l'erreur. Cependant, puisque l'Agent de distribution et l'Agent de fusion écrivent ces mêmes informations dans la table sysreplicationalerts, ainsi que les détails comme le type d'Agent, l'heure de l'alerte, la base de données de publication, la base de données Abonné et le type de publication, le travail de réponse peut obtenir directement ces informations à partir de la table. Il n'est pas possible d'associer la ligne exacte correspondant à une instance précise de l'alerte, mais la table possède une colonne status qui peut être utilisée pour assurer le suivi des entrées. Les entrées de cette table sont conservées pendant la période de rétention de l'historique.

Par exemple, si vous voulez créer un travail dans Transact-SQL, en réponse au message d'alerte 20574, vous pouvez utiliser la logique suivante :

declare @publisher sysname, @publisher_db sysname, @publication sysname, @publication_type int, @article sysname, @subscriber sysname, @subscriber_db sysname, @alert_id int
declare hc cursor local for select publisher, publisher_db, publication, publication_type, article, subscriber, 
  subscriber_db, alert_id from 
  msdb..sysreplicationalerts where
  alert_error_code = 20574 and status = 0
  for read only
open hc
fetch hc into  @publisher, @publisher_db, @publication, @publication_type, @article, @subscriber, @subscriber_db, @alert_id
while (@@fetch_status <> -1)
begin
/* Do custom work  */
/* Update status to 1, which means the alert has been serviced. This prevents subsequent runs of this job from doing this again */
update msdb..sysreplicationalerts set status = 1 where alert_id = @alert_id
 fetch hc into  @publisher, @publisher_db, @publication, @publication_type, @article, @subscriber, @subscriber_db, @alert_id
end
close hc
deallocate hc