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

  • Article

S’applique à :SQL Server

Les applications de gestion accèdent aux événements SQL Server à l’aide du fournisseur WMI pour les événements serveur en émettant des instructions WMI Query Language (WQL). Le langage WQL est un sous-ensemble simplifié du langage SQL, avec quelques extensions spécifiques à WMI. En utilisant WQL, une application récupère un type d’événement sur une instance spécifique de SQL Server, d’une base de données ou d’un objet de base de données (le seul objet actuellement pris en charge est la file d’attente). Le fournisseur WMI pour les événements serveur traduit la requête en notification d’événement créée dans la base de données cible pour les notifications d’événements délimitées à la base de données ou dans l’étendue de l’objet, ou dans la base de données pour les master notifications d’événements au niveau du serveur.

Examinons, par exemple, la requête WQL suivante :

SELECT * FROM DDL_DATABASE_LEVEL_EVENTS WHERE DatabaseName = 'AdventureWorks2022'

À partir de cette requête, le fournisseur WMI tente de produire l'équivalent de cette notification d'événements sur le serveur cible :

USE AdventureWorks2022;
GO

CREATE EVENT NOTIFICATION SQLWEP_76CF38C1_18BB_42DD_A7DC_C8820155B0E9
    ON DATABASE
    WITH FAN_IN
    FOR DDL_DATABASE_LEVEL_EVENTS
    TO SERVICE
        'SQL/Notifications/ProcessWMIEventProviderNotification/v1.0',
        'A7E5521A-1CA6-4741-865D-826F804E5135';
GO

L'argument de la clause FROM de la requête WQL (DDL_DATABASE_LEVEL_EVENTS) peut être n'importe quel événement valide sur lequel il est possible de créer une notification d'événements. Les arguments des clauses SELECT et WHERE peuvent spécifier n'importe quelle propriété d'événement associée à un événement ou à son événement parent. Pour obtenir la liste des événements et des propriétés d’événement valides, consultez Notifications d’événements (Moteur de base de données).

La syntaxe WQL suivante est prise en charge explicitement par le fournisseur WMI pour les événements serveur. Une syntaxe WQL supplémentaire peut être spécifiée, mais elle n’est pas spécifique à ce fournisseur et est analysée à la place par le service hôte WMI. Pour plus d'informations sur le langage de requêtes WMI (WQL), consultez la documentation WQL sur MSDN (Microsoft Developer Network).

Syntaxe

SELECT { event_property [ , ...n ] | * }
FROM event_type
WHERE where_condition
[ ; ]

Arguments

event_property [ , ... n ] | *

Propriété d’un événement. PostTime, SPID et LoginName en sont des exemples. Recherchez chaque événement répertorié dans le fournisseur WMI pour les classes et propriétés Événements serveur pour déterminer les propriétés qu’il contient. Par exemple, l'événement DDL_DATABASE_LEVEL_EVENTS contient les propriétés DatabaseName et UserName. Il hérite également des propriétés SQLInstance, LoginName, PostTime, SPID et ComputerName de ses événements parents.

  • , ... ¡n

    Indique que event_property peut être interrogé plusieurs fois, séparés par des virgules.

  • *

    Spécifie que toutes les propriétés associées à un événement sont interrogées.

event_type

Tout événement sur lequel une notification d’événement peut être créée. Pour obtenir la liste des événements disponibles, consultez WMI Provider for Server Events classes and properties. Les noms de type d’événement correspondent au même event_type event_group | qui peut être spécifié lorsque vous créez manuellement une notification d’événement à l’aide CREATE EVENT NOTIFICATIONde . Exemples de type d’événement : , DDL_USER_EVENTSCREATE_TABLELOCK_DEADLOCK, et .TRC_DATABASE

Remarque

Certaines procédures stockées système qui exécutent des opérations de type DDL peuvent également déclencher des notifications d'événements. Testez vos notifications d'événements pour déterminer leur réponse aux procédures stockées du système qui sont exécutées. Par exemple, l’instruction et sp_addtype la CREATE TYPE procédure stockée déclenchent toutes deux une notification d’événement créée sur un CREATE_TYPE événement. Toutefois, la sp_rename procédure stockée ne déclenche aucune notification d’événement. Pour plus d’informations, consultez Événements DDL.

where_condition

Prédicat WHERE de requête de clause, composé de noms event_property et d’opérateurs logiques et de comparaison. L’where_condition détermine l’étendue dans laquelle la notification d’événement correspondante est inscrite dans la base de données cible. Il peut également agir en tant que filtre pour cibler un schéma ou un objet particulier à partir duquel interroger event_type. Pour plus d’informations, consultez la section Remarques .

Seul l'opérande = peut être utilisé avec DatabaseName, SchemaName et ObjectName. D’autres expressions ne peuvent pas être utilisées avec ces propriétés d’événement.

Notes

La where_condition de la syntaxe des événements du fournisseur WMI pour serveur détermine les éléments suivants :

  • Étendue par laquelle le fournisseur tente de récupérer le event_type spécifié : le niveau du serveur, le niveau de la base de données ou l’objet (le seul objet actuellement pris en charge est file d’attente). En dernier ressort, cette étendue détermine le type de notification d'événements créé dans la base de données cible. Ce processus est appelé inscription de notification d'événements.

  • La base de données, le schéma et l'objet, le cas échéant, sur lequel s'effectue l'inscription.

Le fournisseur WMI pour les événements de serveur utilise un algorithme bas en haut et en premier pour produire l’étendue la plus étroite possible pour le sous-jacent EVENT NOTIFICATION. L’algorithme tente de réduire l’activité interne sur le serveur et le trafic réseau entre l’instance de SQL Server et le processus hôte WMI. Le fournisseur examine la event_type spécifiée dans la FROM clause et les conditions de la WHERE clause, et tente d’inscrire le sous-jacent EVENT NOTIFICATION avec la portée la plus étroite possible. Si le fournisseur ne peut pas s’inscrire à l’étendue la plus étroite, il tente de s’inscrire successivement à des étendues plus élevées jusqu’à ce qu’une inscription réussisse finalement. S'il atteint l'étendue la plus élevée (niveau serveur) et échoue, il retourne une erreur au consommateur.

Par exemple, si DatabaseName='AdventureWorks2022' elle est spécifiée dans la WHERE clause, le fournisseur tente d’inscrire une notification d’événement dans la AdventureWorks2022 base de données. Si la base de données AdventureWorks2022 existe et que le client appelant a les autorisations requises pour créer une notification d'événements dans AdventureWorks2022, l'inscription est réussie. Sinon, une tentative a lieu pour enregistrer la notification d'événements au niveau serveur. L'inscription réussit si le client WMI a les autorisations requises. Toutefois, dans ce scénario, les événements ne sont pas retournés au client tant que la AdventureWorks2022 base de données n’a pas été créée.

Le where_condition peut également servir de filtre pour limiter la requête à une base de données, un schéma ou un objet spécifique. Examinons, par exemple, la requête WQL suivante :

SELECT * FROM ALTER_TABLE
WHERE DatabaseName = 'AdventureWorks2022' AND SchemaName = 'Sales'
    AND ObjectType='Table' AND ObjectName = 'SalesOrderDetail'

Selon le résultat du processus d’inscription, cette requête WQL peut être inscrite au niveau de la base de données ou du serveur. Toutefois, même s’il est inscrit au niveau du serveur, le fournisseur filtre finalement les ALTER_TABLE événements qui ne s’appliquent pas à la Sales.SalesOrderDetail table. En d'autres termes, le fournisseur ne retourne que les propriétés des événements ALTER_TABLE qui se produisent sur cette table spécifique.

Si une expression composée telle qu’elle DatabaseName='AW1' OR DatabaseName='AW2' est spécifiée, une tentative est effectuée pour inscrire une notification d’événement unique au niveau de l’étendue du serveur au lieu de deux notifications d’événements distinctes. L'inscription réussit si le client appelant a les autorisations requises.

Si SchemaName='X' AND ObjectType='Y' AND ObjectName='Z' tous sont spécifiés dans la clause, une tentative est effectuée pour inscrire la notification d’événement directement sur l’objet Z dans le WHERE schémaX. L'inscription réussit si le client a les autorisations requises. Actuellement, les événements au niveau de l’objet sont pris en charge uniquement sur les files d’attente et uniquement pour les QUEUE_ACTIVATIONevent_type.

Tous les événements ne peuvent pas être interrogés dans une étendue particulière. Par exemple, une requête WQL sur un événement de trace tel que Lock_Deadlock, ou un groupe d’événements de trace tel que TRC_LOCKS, ne peut être inscrit qu’au niveau du serveur. De même, l’événement CREATE_ENDPOINT et le DDL_ENDPOINT_EVENTS groupe d’événements peuvent également être inscrits uniquement au niveau du serveur. Pour plus d’informations sur l’étendue appropriée pour l’inscription d’événements, consultez Conception de notifications d’événements. Une tentative d’inscription d’une requête WQL dont les event_type ne peuvent être inscrites qu’au niveau du serveur est toujours effectuée au niveau du serveur. L'inscription réussit si le client WMI a les autorisations requises. Sinon, une erreur est retournée au client. Dans certains cas, toutefois, vous pouvez toujours utiliser la WHERE clause comme filtre pour les événements au niveau du serveur en fonction des propriétés qui correspondent à l’événement. Par exemple, de nombreux événements de trace ont une DatabaseName propriété qui peut être utilisée dans la WHERE clause en tant que filtre.

Les notifications d’événements au niveau du serveur sont créées dans la master base de données et peuvent être interrogées pour les métadonnées à l’aide de l’affichage catalogue sys.server_event_notifications .

Les notifications d’événements délimitées à la base de données ou à portée d’objet sont créées dans la base de données spécifiée et peuvent être interrogées pour les métadonnées à l’aide de l’affichage catalogue sys.event_notifications . (Vous devez préfixer l'affichage catalogue avec le nom correspondant de la base de données.)

Exemples

Cet article requiert l'exemple de bases de données AdventureWorks2022, que vous pouvez télécharger à partir de la page d'accueil des exemples et projets de communautés Microsoft SQL Server.

A. Rechercher des événements au niveau de l’étendue du serveur

La requête WQL suivante récupère toutes les propriétés d’événement pour tout SERVER_MEMORY_CHANGE événement de trace qui se produit sur l’instance de SQL Server.

SELECT * FROM SERVER_MEMORY_CHANGE

B. Rechercher des événements dans l’étendue de la base de données

La requête WQL suivante extrait les propriétés d'événement spécifiques pour tout événement qui se produit dans la base de données AdventureWorks2022 et qui existe sous le groupe d'événements DDL_DATABASE_LEVEL_EVENTS.

SELECT SPID, SQLInstance, DatabaseName FROM DDL_DATABASE_LEVEL_EVENTS
WHERE DatabaseName = 'AdventureWorks2022'

C. Rechercher des événements dans l’étendue de la base de données, filtrer par schéma et objet

La requête suivante extrait toutes les propriétés d'événement pour tout événement ALTER_TABLE qui se produit sur la table Sales.SalesOrderDetail.

SELECT * FROM ALTER_TABLE
WHERE DatabaseName = 'AdventureWorks2022' AND SchemaName = 'Sales'
    AND ObjectType='Table' AND ObjectName = 'SalesOrderDetail'

Contenu connexe