Notifications d'événements

  • Article

S’applique à :SQL Server

Les notifications d’événements envoient des informations sur les événements à un service Service Broker. Les notifications d’événements s’exécutent en réponse à diverses instructions de langage de définition de données Transact-SQL (DDL) et aux événements de trace SQL en envoyant des informations sur ces événements à un service Service Broker.

Les notifications d'événements peuvent être utilisées pour effectuer les opérations suivantes :

  • enregistrer dans un journal et examiner les modifications ou l'activité de la base de données ;

  • réaliser une action en réponse à un événement de manière asynchrone plutôt que synchrone.

Les notifications d'événements peuvent constituer une alternative de programmation aux déclencheurs DDL et à Trace SQL.

Avantages des notifications d'événements

Elles sont exécutées de manière asynchrone, en dehors de la portée d'une transaction. Ainsi, contrairement aux déclencheurs DDL, les notifications d'événements peuvent être utilisées dans une application de base de données pour répondre à des événements sans recourir aux ressources définies par la transaction immédiate.

Contrairement à SQL Trace, les notifications d’événements peuvent être utilisées pour effectuer une action à l’intérieur d’une instance de SQL Server en réponse à un événement SQL Trace.

Les données d’événement peuvent être utilisées par les applications qui s’exécutent avec SQL Server pour suivre la progression et prendre des décisions. Par exemple, la notification d'événement suivante envoie un avis à un certain service chaque fois qu'une instruction ALTER TABLE est émise dans l'exemple de base de données AdventureWorks2022 .

USE AdventureWorks2022;  
GO  
CREATE EVENT NOTIFICATION NotifyALTER_T1  
ON DATABASE  
FOR ALTER_TABLE  
TO SERVICE '//Adventure-Works.com/ArchiveService' ,  
    '8140a771-3c4b-4479-8ac0-81008ab17984';

Concepts de notifications d'événements

Lorsqu’une notification d’événement est créée, une ou plusieurs conversations Service Broker entre une instance de SQL Server et le service cible que vous spécifiez sont ouvertes. Les conversations restent en général ouvertes tant que la notification d'événement existe en tant qu'objet sur l'instance de serveur. Dans certains cas d'erreur, les conversations peuvent être interrompues avant la suppression de la notification d'événement. Ces conversations ne sont jamais partagées entre les notifications d'événements. Toutes les notifications d'événements possèdent leurs propres conversations exclusives. L'interruption d'une conversation interdit explicitement au service cible de recevoir davantage de messages ; en outre, la conversation ne rouvrira pas au déclenchement suivant de la notification d'événement.

Les informations sur les événements sont fournies au service Service Broker sous la forme d’une variable de type xml qui fournit des informations sur le moment où un événement se produit, sur l’objet de base de données affecté, l’instruction batch Transact-SQL impliquée et d’autres informations. Pour plus d’informations sur le schéma XML généré par les notifications d’événements, consultez EVENTDATA (Transact-SQL).

Notifications d'événements et Déclencheurs

Le tableau suivant répertorie les similitudes et les différences entre les déclencheurs et les notifications d'événements.

Déclencheurs Notifications d'événements
Les déclencheurs DML répondent aux événements DML (Data Manipulation Language, ou langage de manipulation de données). Les déclencheurs DDL répondent aux événements DDL (Data Definition Language, ou langage de définition de données). Les notifications d'événements répondent aux événements DDL et à un sous-ensemble d'événements de Trace SQL.
Les déclencheurs peuvent exécuter Transact-SQL ou le code managé CLR (Common Language Runtime). Les notifications d'événements n'exécutent aucun code. En fait, elles envoient des messages xml à un service Service Broker.
Les déclencheurs sont traités de manière synchrone, dans le cadre des transactions qui provoquent leur déclenchement. Les notifications d'événements peuvent être traitées de manière synchrone, et elles ne sont pas exécutées dans le cadre des transactions qui provoquent leur déclenchement.
Le consommateur d'un déclencheur est étroitement lié à l'événement qui provoque son déclenchement. Le consommateur d'une notification d'événement est dissocié de l'événement qui provoque son déclenchement.
Les déclencheurs doivent être traités sur le serveur local. Les notifications d'événements peuvent être traitées sur un serveur distant.
Les déclencheurs peuvent être restaurés. Les notifications d'événements ne peuvent pas être restaurées.
Les noms de déclencheurs DML ont une portée de schéma. Les noms de déclencheurs DDL sont limités au niveau de la base de données ou du serveur. Les noms de notifications d'événements sont limités par le serveur ou la base de données. Les notifications d'événements sur un événement QUEUE_ACTIVATION sont limitées à une file d'attente spécifique.
Les déclencheurs DML sont détenus par le propriétaire des tables sur lesquelles ils sont appliqués. Le propriétaire d'une notification d'événements sur une file d'attente peut être différent de celui de l'objet auquel la notification est appliquée.
Les déclencheurs prennent en charge la clause EXECUTE AS. Les notifications d'événements ne prennent pas en charge la clause EXECUTE AS.
Les informations d’événement de déclencheur DDL peuvent être capturées à l’aide de la fonction EVENTDATA, qui retourne un type de données xml . Les notifications d’événements envoient des informations d’événement xml à un service Service Broker. Les informations sont mises en forme dans le même schéma que celui de la fonction EVENTDATA.
Les métadonnées concernant les déclencheurs se trouvent dans les affichages catalogue sys.triggers et sys.server_triggers . Les métadonnées concernant les notifications d’événements se trouvent dans les affichages catalogue sys.event_notifications et sys.server_event_notifications .

Notifications d'événements et Trace SQL

Le tableau suivant répertorie les similitudes et les différences dans l'utilisation des notifications d'événements et de Trace SQL dans le cadre de la surveillance des événements de serveur.

Trace SQL Notifications d'événements
Trace SQL n'engendre aucun surcroît d'utilisation de temps système lié aux transactions. L'empaquetage des données est efficace. Les ressources système sont sollicitées davantage lors de la création des données d'événements au format XML et de l'envoi des notifications d'événements.
Trace SQL peut surveiller toutes les classes d'événements de trace. Les notifications d'événements peuvent surveiller un sous-ensemble des classes d'événements de trace ainsi que tous les événements DDL (Data Definition Language).
Vous pouvez personnaliser les colonnes de données à générer dans l'événement de trace. Le schéma des données d'événements au format XML renvoyées par les notifications d'événements est fixe.
Les événements de trace générés par DDL sont toujours générés, même si l'instruction DDL est annulée. Les notifications d'événements ne se déclenchent pas si l'événement de l'instruction DDL correspondante est annulé.
La gestion du flux intermédiaire des données d'événement de trace implique le remplissage et la gestion de fichiers ou de tables de trace. La gestion intermédiaire des données de notification d'événements est accomplie automatiquement via les files d'attente de Service Broker.
Les traces doivent être redémarrées à chaque démarrage du serveur. Après avoir été inscrites, les notifications d'événements perdurent au fil des cycles serveur et sont incluses dans une transaction.
Après avoir été lancé, le déclenchement des traces ne peut plus être contrôlé. Les options d'heure d'arrêt et de filtrage permettent de spécifier l'heure de lancement. Les traces sont accessibles par interrogation du fichier de trace correspondant. Une notification d'événements peut être contrôlée en exécutant l'instruction WAITFOR sur la file d'attente qui reçoit le message généré par la notification. Elle est accessible par interrogation de la file d'attente.
ALTER TRACE est l'autorisation minimale requise pour créer une trace. Une autorisation permettant de créer un fichier de trace sur l'ordinateur est également nécessaire. L'autorisation minimale dépend du type de notification d'événements créée. L'autorisation RECEIVE sur la file d'attente correspondante est également requise.
Les traces peuvent être reçues à distance. Les notifications d'événements ne peuvent pas être reçues à distance.
Les événements de trace sont mis en œuvre au moyen de procédures stockées système. Les notifications d’événements sont implémentées à l’aide d’une combinaison d’instructions Transact-SQL du moteur de base de données et Service Broker.
Les données d’événement de trace sont accessibles par programmation en interrogeant la table de trace correspondante, en analysant le fichier de trace ou en utilisant la classe TraceReader (SMO) SQL Server Management Objects. Les données d'événements sont accessibles par programme en émettant une requête XQuery sur les données d'événements au format XML ou au moyen de classes Event SMO.

Tâches relatives aux notifications d'événements

Task Rubrique
Décrit comment créer et implémenter des notifications d'événements. Implémenter des notifications d'événements
Décrit comment configurer la sécurité de la boîte de dialogue Service Broker pour les notifications d’événements qui envoient des messages à un service Broker sur un serveur distant. Configurer la sécurité du dialogue pour les notifications d'événements
Décrit comment retourner des informations sur les notifications d'événements. Obtenir des informations concernant les notifications d'événements

Voir aussi

Déclencheurs DDL
Déclencheurs DML
Trace SQL