Partager via

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

  • Article

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 master pour les notifications d’événements délimitées par le serveur.

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

SELECT * FROM DDL_DATABASE_LEVEL_EVENTS WHERE DatabaseName = 'AdventureWorks'

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

USE AdventureWorks ;  
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 additionnelle 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
Est la 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 d’é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
Est un événement sur lequel une notification d'événements peut être créée. Pour obtenir la liste des événements disponibles, consultez le fournisseur WMI pour les classes et propriétés d’événements serveur. Notez que les noms de type d’événement correspondent aux mêmes event_type event_group | qui peuvent être spécifiés lorsque vous créez manuellement une notification d’événement à l’aide de CREATE EVENT NOTIFICATION. Les exemples de type d’événement incluent CREATE_TABLE, LOCK_DEADLOCK, DDL_USER_EVENTS 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 CREATE TYPE et sp_addtype procédure stockée déclenchent toutes deux une notification d’événement créée sur un événement CREATE_TYPE. Toutefois, la procédure stockée sp_rename ne déclenche aucune notification d’événement. Pour plus d’informations, consultezÉvénements DDL.

where_condition
Prédicat de requête de clause WHERE 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 plus loin dans cette rubrique.

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 serveur utilise un algorithme ascendant pour produire l'étendue la plus étroite possible pour l'EVENT NOTIFICATION sous-jacent. 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 clause FROM et les conditions de la clause WHERE, et tente d’inscrire la notification EVENT sous-jacente avec la portée la plus étroite possible. Si le fournisseur ne peut pas effectuer l'inscription avec l'étendue la plus étroite, il essaie de s'inscrire successivement à des étendues supérieures jusqu'à ce qu'une inscription réussisse enfin. S'il atteint l'étendue la plus élevée (niveau serveur) et échoue, il retourne une erreur au consommateur.

Par exemple, si DatabaseName=**'AdventureWorks'***est spécifié dans la clause WHERE, le fournisseur tente d’inscrire une notification d’événement dans la base de données AdventureWorks2012. Si la base de données AdventureWorks2012 existe et que le client appelant dispose des autorisations requises pour créer une notification d’événement dans AdventureWorks2012, l’inscription réussit. 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 base de données AdventureWorks2012 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 = 'AdventureWorks' AND SchemaName = 'Sales'   
    AND ObjectType='Table' AND ObjectName = 'SalesOrderDetail'

Selon le résultat de la procédure d'inscription, cette requête WQL peut être inscrite au niveau base de données ou au niveau serveur. Toutefois, même si elle est inscrite au niveau serveur, le fournisseur filtre en fin de compte tous les événements ALTER_TABLE qui ne s'appliquent pas à la table AdventureWorks.Sales.SalesOrderDetail. 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 que DatabaseName='AW1' OR DatabaseName='AW2' est spécifiée, une tentative a lieu pour inscrire une seule notification d'événements dans 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. Notez que actuellement, les événements au niveau de l’objet sont pris en charge uniquement sur les files d’attente et uniquement pour les QUEUE_ACTIVATION event_type.

Notez que certains événements ne peuvent pas être interrogés dans quelque étendue que ce soit. 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 inscrite qu'au niveau serveur. De même, l'événement CREATE_ENDPOINT et le groupe d'événements DDL_ENDPOINT_EVENTS ne peuvent également être inscrits qu'au niveau 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, cependant, vous pouvez encore utiliser la clause WHERE comme filtre pour les événements de niveau serveur en fonction des propriétés qui correspondent à l'événement. Par exemple, de nombreux événements de trace ont une propriété DatabaseName qui peut être utilisée dans la clause WHERE comme filtre.

Les notifications d’événements au niveau du serveur sont créées dans la base de données master 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

R. Interrogation des événements dans 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. Interrogation 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 AdventureWorks et qui existe sous le groupe d'événements DDL_DATABASE_LEVEL_EVENTS.

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

C. Interrogation des événements dans l'étendue de la base de données, avec un filtre par schéma et par 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 AdventureWorks.Sales.SalesOrderDetail.

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

Voir aussi

Fournisseur WMI pour les concepts des événements de serveur
Notifications d’événements (Moteur de base de données)