Utiliser les alertes pour les événements des agents de réplication

S’applique à :SQL ServerAzure SQL Managed Instance

SQL Server Management Studio et Microsoft SQL Server Agent offrent un moyen de surveiller les événements, tels que les événements de l’agent de réplication, à l’aide d’alertes. SQL Server Agent surveille le journal des applications Windows pour les événements associés aux alertes. Si un tel événement se produit, SQL Server Agent répond automatiquement en exécutant une tâche que vous avez définie et/ou en envoyant un e-mail ou un message de pagineur à un opérateur spécifié. SQL Server inclut un ensemble d’alertes prédéfinies pour les agents de réplication que vous pouvez configurer pour exécuter une tâche et/ou notifier 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 :

En plus de ces alertes, le moniteur de réplication comprend un ensemble d'avertissements et d'alertes liées aux états et aux performances. Pour plus d’informations, voir Set Thresholds and Warnings in Replication Monitor. 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éer un événement défini par l’utilisateur.

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

• SQL Server Management Studio : Configurer des alertes de réplication prédéfinies (SQL Server Management Studio)

Affichage direct du journal des applications

Pour afficher le journal des applications Windows, utilisez l’Observateur d’événements Microsoft Windows. Le journal des applications contient des messages d’erreur SQL Server ainsi que des messages pour de nombreuses autres activités sur l’ordinateur. Contrairement au journal des erreurs SQL Server, un nouveau journal d’application n’est pas créé chaque fois que vous démarrez SQL Server (chaque session SQL Server écrit de nouveaux événements dans un journal d’application existant) ; Toutefois, vous pouvez spécifier la durée pendant laquelle les événements enregistrés seront conservé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 en cas d’échec de validation des données et est stocké dans le dossier Travaux de SQL Server Agent dans SQL Server Management Studio. Pour plus d’informations sur l’activation de ce travail de réponse, consultez 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.

Par exemple, si les données de la table Sales.SalesOrderHeader sur l’Abonné A échouent, SQL Server peut déclencher le message 20574, vous informant de cette défaillance. 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 deviez créer un travail de réponse dans Transact-SQL qui signale le 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  

Voir aussi

Administration de l’Agent de réplication
Best Practices for Replication Administration
Surveillance (réplication)