Utiliser le fournisseur WMI pour les événements de serveur

  • Article

S’applique à :SQL Server

Cet article fournit des instructions à prendre en compte avant de programmer à l’aide du fournisseur WMI pour les événements de serveur.

Activer Service Broker

Le fournisseur WMI pour les événements de serveur fonctionne en traduisant les requêtes WQL pour les événements en notifications d'événements dans la base de données que vous ciblez. Il peut être utile de comprendre comment les notifications d'événements fonctionnent lorsque vous programmez en fonction du fournisseur. Pour plus d’informations, consultez les concepts du fournisseur WMI pour les événements de serveur.

En particulier, étant donné que les notifications d’événements créées par le fournisseur WMI utilisent SQL Server pour envoyer des messages sur les événements du serveur, ce service doit être activé partout où les événements sont générés. Si votre programme interroge des événements sur une instance de serveur, le Service Broker msdb de cette instance doit être activé, car il s’agit de l’emplacement du service Service Broker cible (nommé SQL/Notifications/ProcessWMIEventProviderNotification/v1.0) créé par le fournisseur. Si votre programme interroge des événements dans une base de données ou sur un objet de base de données particulier, Service Broker dans cette base de données cible doit être activé. Si service Broker correspondant n’est pas activé une fois votre application déployée, tous les événements générés par la notification d’événement sous-jacente sont envoyés à la file d’attente du service utilisé par la notification d’événement, mais ne sont pas retournés à votre application de gestion WMI tant que Service Broker n’est pas activé.

La requête suivante détermine quelles instances Service Broker sont activées sur une instance de serveur, ainsi que le GUID des instances Service Broker :

SELECT name, is_broker_enabled, service_broker_guid FROM sys.databases;

Le GUID msdb du service Broker est d’un intérêt particulier, car il s’agit de l’emplacement du service cible du fournisseur.

Pour activer Service Broker dans une base de données, utilisez l’option ENABLE_BROKER SET de l’instruction ALTER DATABASE .

Spécifier une chaîne de connexion

Les applications dirigent le fournisseur WMI pour les événements serveur vers une instance de SQL Server en se connectant à un espace de noms WMI défini par le fournisseur. Le service WMI de Windows mappe cet espace de noms à la DLL de fournisseur, Sqlwep.dll, puis la charge en mémoire. Chaque instance de SQL Server a son propre espace de noms WMI, qui est par défaut : \\.\root\Microsoft\SqlServer\ServerEvents\instance_name. instance_name la valeur par défaut MSSQLSERVER dans une installation par défaut de SQL Server.

Autorisations et authentification du serveur

Pour accéder au fournisseur WMI pour les événements de serveur, le client sur lequel provient une application de gestion WMI doit correspondre à la connexion ou au groupe authentifié Windows dans l’instance de SQL Server spécifiée dans la chaîne de connexion de l’application.

Autorisations et étendue de notification d’événement

Le fournisseur WMI pour les événements de serveur traduit des requêtes WQL en notifications d'événements dans la base de données cible. En raison de cela, l’application appelante ne doit pas seulement disposer des autorisations minimales requises pour accéder au fournisseur, mais doit également disposer des autorisations appropriées dans la base de données pour créer les notifications d’événements requises. Les autorisations sont les suivantes :

  • Pour créer une notification d'événements dont l'étendue correspond à la base de données, au minimum, l'autorisation CREATE DATABASE DDL EVENT NOTIFICATION est requise sur la base de données actuelle.

  • Pour créer une notification d'événements sur une instruction DDL dont l'étendue correspond au serveur, au minimum, l'autorisation CREATE DDL EVENT NOTIFICATION est requise sur le serveur.

  • Pour créer une notification d'événements sur un événement de trace, au minimum, l'autorisation CREATE TRACE EVENT NOTIFICATION est requise sur le serveur.

  • Pour créer une notification d'événements dont l'étendue correspond à une file d'attente, au minimum, l'autorisation ALTER est requise sur la file d'attente.

Pour plus d’informations sur l’étendue des requêtes WQL, consultez Utilisation de WQL avec le fournisseur WMI pour les événements de serveur.

Pour illustrer l'étendue, considérez une application de fournisseur WMI qui inclut la requête WQL suivante :

SELECT * FROM ALTER_TABLE
WHERE DatabaseName = "AdventureWorks2022"
    AND SchemaName = "Person"
    AND ObjectName = "Person"
    AND ObjectType = "TABLE";

Le fournisseur WMI traduit cette requête en une notification d'événements créée dans la base de données AdventureWorks2022. Cela signifie que l'appelant doit avoir les autorisations requises pour créer une telle notification d'événements, notamment l'autorisation CREATE DATABASE DDL EVENT NOTIFICATION dans la base de données AdventureWorks2022.

Si une requête WQL spécifie une notification d'événements dont l'étendue correspond au niveau serveur, par exemple en émettant la requête SELECT * FROM ALTER_TABLE, l'application appelante doit avoir l'autorisation CREATE DDL EVENT NOTIFICATION au niveau du serveur. Les notifications d’événements au niveau du serveur sont stockées dans la master base de données. Vous pouvez utiliser l’affichage catalogue sys.server_event_notifications pour afficher leurs métadonnées.

Remarque

L'étendue de la notification d'événements qui est créée par le fournisseur WMI (serveur, base de données ou objet) dépend finalement du résultat du processus de vérification des autorisations qui est utilisé par le fournisseur WMI. Cela est affecté par le jeu d'autorisations de l'utilisateur qui appelle le fournisseur et sur la vérification de la base de données interrogée.

Dans l'exemple précédent, le fournisseur commence par essayer de créer une notification d'événements dont l'étendue est la base de données (ON DATABASE). Si le fournisseur vérifie que la base de données existe et que l'appelant possède les autorisations requises pour créer une notification d'événements dessus, l'inscription réussit. S’il ne réussit pas, le fournisseur tente de créer une notification d’événement sur le serveur (ON SERVER). En supposant que cette tentative réussit, tous les ALTER_TABLE événements qui se produisent sur le serveur sont envoyés du processus SQL Server au processus de service WMI. Toutefois, le fournisseur filtre les événements qui ne s’appliquent pas à la AdventureWorks2022 base de données. Bien que ce processus augmente potentiellement la quantité de trafic réseau nécessaire pour l'étendue de l'événement, il vous apporte également la souplesse d'enregistrer des requêtes WQL sur les bases de données avant qu'elles soient créées, puis de recevoir les données d'événement après la création de la base de données et le démarrage de l'activité DDL sur cette dernière.

Autorisations et vérification des messages

Le fournisseur WMI n’envoie pas de messages pour les notifications d’événements si les deux conditions suivantes sont remplies :

  • L'utilisateur qui a créé la notification d'événements par le biais du fournisseur WMI n'existe plus dans la base de données ou ne possède plus l'autorisation requise pour créer une notification d'événements semblable.

  • Les notifications d'événements sont créées sur les événements suivants :

    • DROP_LOGIN

    • ALTER_LOGIN

    • DROP_USER

    • ALTER_USER

    • ADD_ROLE_MEMBER

    • DROP_ROLE_MEMBER

    • ADD_SERVER_ROLE_MEMBER

    • DROP_SERVER_ROLE_MEMBER

    • DENYou REVOKE (S’applique uniquement à ALTER DATABASE, , CREATE DATABASE DDL EVENT NOTIFICATIONALTER ANY DATABASE EVENT NOTIFICATION, CONTROL SERVERALTER ANY EVENT NOTIFICATION, CREATE DDL EVENT NOTIFICATIONou CREATE TRACE EVENT NOTIFICATION autorisations.)

Utiliser des données d’événement côté client

Une fois que le fournisseur WMI pour les événements serveur a créé la notification d’événement requise dans la base de données cible, la notification d’événement envoie des données d’événement au service cible nommé msdbSQL/Notifications/ProcessWMIEventProviderNotification/v1.0. Le service cible place l’événement dans msdb une file d’attente nommée WMIEventProviderNotificationQueue. (Le service et la file d’attente sont créés dynamiquement par le fournisseur lors de sa première connexion à SQL Server.) Le fournisseur lit ensuite les données d’événement XML de cette file d’attente et les transforme en format d’objet managé (MOF) avant de les renvoyer à l’application cliente. Les données MOF sont composées des propriétés de l'événement demandé par la requête WQL comme une définition de classe CIM (Common Information Model). Chaque propriété a un type CIM correspondant. Par exemple, la SPID propriété est retournée en tant que type CIM Sint32. Les types CIM pour chaque propriété sont répertoriés sous chaque classe d’événements dans le fournisseur WMI pour les classes et propriétés des événements serveur.

Contenu connexe