• Article

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

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

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

SELECT * FROM DDL_DATABASE_LEVEL_EVENTS WHERE DatabaseName = 'AdventureWorks2008R2'

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

USE AdventureWorks2008R2 ;
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 propriétés d'événement valides, consultez Fournisseur WMI pour les classes et propriétés d'événements serveur.

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. Examinez chaque événement répertorié dans Fournisseur WMI pour les classes et propriétés d'événements serveur afin de déterminer quelles propriétés 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, SPIDet ComputerName de ses événements parents.

  • ,...n
    Indique que event_property peut être l'objet de plusieurs interrogations, séparées 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 Fournisseur WMI pour les classes et propriétés d'événements serveur. Notez que les noms event type correspondent aux mêmes noms event_type | event_group qui peuvent être spécifiés quand vous créez manuellement une notification d'événements en utilisant CREATE EVENT NOTIFICATION. CREATE_TABLE, LOCK_DEADLOCK, DDL_USER_EVENTS et TRC_DATABASE constituent des exemples de event type.

    Notes

    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 la procédure stockée sp_addtype déclencheront toutes les deux une notification d'événement qui est créée sur un événement CREATE_TYPE. Cependant, la procédure stockée sp_rename ne déclenche pas de notification d'événements. Pour plus d'informations, consultez Événements DDL.

  • where_condition
    Est un prédicat de la requête de la clause WHERE composé de noms event_property et des opérateurs logiques et de comparaison. where_condition détermine l'étendue dans laquelle la notification d'événements correspondante est enregistrée dans la base de données cible. Son comportement peut aussi être celui d'un filtre destiné à cibler un schéma ou un objet particulier depuis lequel interroger event_type. Pour plus d'informations, consultez plus bas la section Notes de 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

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

  • L'étendue dans laquelle le fournisseur essaie d'extraire le event_type spécifié : le niveau serveur, le niveau base de données ou le niveau objet (le seul objet pris en charge actuellement est la 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 essaie de réduire l'activité interne sur le serveur, ainsi que le trafic réseau entre l'instance de SQL Server et le processus hôte de WMI. Le fournisseur examine le event_type spécifié dans la clause FROM et les conditions de la clause WHERE, et essaie d'inscrire l'EVENT NOTIFICATION sous-jacent avec l'étendue 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='AdventureWorks2008R2' est spécifié dans la clause WHERE, le fournisseur essaie d'inscrire une notification d'événements dans la base de données AdventureWorks2008R2. Si la base de données AdventureWorks2008R2 existe et que le client appelant a les autorisations requises pour créer une notification d'événements dans AdventureWorks2008R2, 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 base de données AdventureWorks2008R2 n'a pas été créée.

Le where_condition peut également agir comme filtre pour limiter en outre 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 = 'AdventureWorks2008R2' 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 AdventureWorks2008R2.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' sont tous spécifiés dans la clause WHERE, une tentative a lieu pour inscrire directement la notification d'événements sur l'objet Z du schéma X. L'inscription réussit si le client a les autorisations requises. Notez qu'actuellement, les événements du niveau objet ne sont pris en charge que sur les files d'attente, et uniquement pour le event_type QUEUE_ACTIVATION.

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 des événements, consultez Conception de notifications d'événements. La tentative d'inscrire une requête WQL dont event_type peut uniquement être inscrit au niveau serveur a toujours lieu au niveau 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 dans l'étendue 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 dans l'étendue objet ou base de données sont créées dans la base de données spécifiées 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

A. Interrogation des événements dans l'étendue du serveur

La requête WQL suivante extrait toutes les propriétés d'événement pour tout événement de trace SERVER_MEMORY_CHANGE 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 AdventureWorks2008R2 et qui existe sous le groupe d'événements DDL_DATABASE_LEVEL_EVENTS.

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

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 AdventureWorks2008R2.Sales.SalesOrderDetail.

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