137
5.8 Événements étendus (SQL Server 2008)
• predicates : des clauses de filtre. Le filtrage se fait au plus près de l’événement,
ce qui évite de déclencher l’événement s’il ne correspond pas au filtre. Les
prédicats peuvent conserver leur état, on peut donc par exemple compter les
déclenchements d’un événement dans un prédicat, et utiliser ce compteur
comme filtre.
• maps : des tableaux de référence qui permettent de lier des identifiants courts
dans l’événement, à des correspondances claires dans la map. Cela permet,
comme dans un modèle relationnel, de diminuer la taille des données
d’événement.
Les événements sont classés en « channels » (sur le modèle de ETW). Les événements faisant partie du channel « Analytic » sont ceux qui seront principalement
intéressants pour l’analyse de performances. Ils contiennent des événements correspondant aux traces SQL et aux compteurs de performances fournis par SQL Server
(avec beaucoup plus d’informations qu’une simple valeur de compteur). Les colonnes keyword et channel de chaque événement permettent d’en retrouver le package et
le channel, et de les classer. La colonne keyword correspond à une information claire
tirée d’un lien sur une map.
SELECT map_value as Keyword
FROM sys.dm_xe_map_values
WHERE name = 'keyword_map';
Vous trouvez une requête permettant de lister les événements disponibles dans
l’entrée des BOL SQL Server 2008 nommée « How to: View the Events for Registered
Packages ».
Le coût de déclenchement des événements étendus a été optimisé autant que
possible, et est léger (Microsoft déclare 2 microsecondes de processeur cadencé à
2 GHz). Les événements asynchrones sont à préférer, car ils ont un impact plus faible sur les performances du serveur. Les événements asynchrones sont gérés par des
buffers, des parties de mémoire qui stockent les événements avant de les envoyer aux
clients qui en font la demande ou de les écrire sur le disque. Cette deuxième partie
sera effectuée par un thread en background, ce qui est moins coûteux.
5.8.2 Création d’une session
Pour récupérer des événements étendus, vous devez d’abord créer une session, qui est
la déclaration nommée d’un groupe d’événements tracés. Ces sessions étant enregistrées dans des tables systèmes, elles existent donc encore après un redémarrage de
l’instance, et elles peuvent être configurées pour redémarrer automatiquement avec
elle.
Une session se crée avec la commande CREATE EVENT SESSION, dans laquelle nous
indiquons les événements à récupérer (ADD EVENT nom_du_package.evenement), les
destinataires (ADD TARGET), etc. :
CREATE EVENT SESSION masession
5.8 Événements étendus (SQL Server 2008)
• predicates : des clauses de filtre. Le filtrage se fait au plus près de l’événement,
ce qui évite de déclencher l’événement s’il ne correspond pas au filtre. Les
prédicats peuvent conserver leur état, on peut donc par exemple compter les
déclenchements d’un événement dans un prédicat, et utiliser ce compteur
comme filtre.
• maps : des tableaux de référence qui permettent de lier des identifiants courts
dans l’événement, à des correspondances claires dans la map. Cela permet,
comme dans un modèle relationnel, de diminuer la taille des données
d’événement.
Les événements sont classés en « channels » (sur le modèle de ETW). Les événements faisant partie du channel « Analytic » sont ceux qui seront principalement
intéressants pour l’analyse de performances. Ils contiennent des événements correspondant aux traces SQL et aux compteurs de performances fournis par SQL Server
(avec beaucoup plus d’informations qu’une simple valeur de compteur). Les colonnes keyword et channel de chaque événement permettent d’en retrouver le package et
le channel, et de les classer. La colonne keyword correspond à une information claire
tirée d’un lien sur une map.
SELECT map_value as Keyword
FROM sys.dm_xe_map_values
WHERE name = 'keyword_map';
Vous trouvez une requête permettant de lister les événements disponibles dans
l’entrée des BOL SQL Server 2008 nommée « How to: View the Events for Registered
Packages ».
Le coût de déclenchement des événements étendus a été optimisé autant que
possible, et est léger (Microsoft déclare 2 microsecondes de processeur cadencé à
2 GHz). Les événements asynchrones sont à préférer, car ils ont un impact plus faible sur les performances du serveur. Les événements asynchrones sont gérés par des
buffers, des parties de mémoire qui stockent les événements avant de les envoyer aux
clients qui en font la demande ou de les écrire sur le disque. Cette deuxième partie
sera effectuée par un thread en background, ce qui est moins coûteux.
5.8.2 Création d’une session
Pour récupérer des événements étendus, vous devez d’abord créer une session, qui est
la déclaration nommée d’un groupe d’événements tracés. Ces sessions étant enregistrées dans des tables systèmes, elles existent donc encore après un redémarrage de
l’instance, et elles peuvent être configurées pour redémarrer automatiquement avec
elle.
Une session se crée avec la commande CREATE EVENT SESSION, dans laquelle nous
indiquons les événements à récupérer (ADD EVENT nom_du_package.evenement), les
destinataires (ADD TARGET), etc. :
CREATE EVENT SESSION masession