Le document présente une introduction au moteur d'événements étendus (XE) de SQL Server, abordant sa définition, son organisation et les nouveautés apportées par Denali. Il met en avant les différences avec SQL Trace, les types d'événements et de cibles, ainsi que l'architecture flexible et très configurable du moteur XE. Plusieurs exemples d'utilisation et des détails techniques sont fournis pour illustrer les capacités de capture et d'analyse des événements dans SQL Server.

1. Rejoignez la Communauté

2. ÉVÈNEMENTS ÉTENDUS (XE)
& nouveautés Denali

3. SPEAKER
David BAFFALEUF - dbaffaleuf@capdata.fr
DBA de production depuis 1999.
Consultant et formateur SQL Server.
Responsable technique du service DBA à distance @ CapData
Consulting.
SQL Server MVP.
 http://www.capdata.fr
 http://blog.capdata.fr

4. AGENDA
• Définition, organisation du moteur XE: packages, events,
targets, etc…
• Gestion et exploitation des traces.
• Comparatif XE vs SQL Trace.
• Bilan nouveautés Denali.
• Démo / Q & A.

5. QU’EST-CE QUE LE MOTEUR XE?
• Vers une évolution logique: SQL Trace/sysperfinfo/dbcc
sqlperf(), puis DMV/DMF, ring buffers…
• Architecture de gestion évènementielle imbriquée au
coeur des moteurs relationnel et de stockage.
• Hautement configurable, faible impact.
• Très grande richesse en nombre d’évènements
capturables. (591 contre 180 dans SQL Trace)
• Intégration possible avec traces système (ETW).
• SQL Trace en voie d’obsolescence.

6. ORGANISATION DU MOTEUR XE
targets
maps
types
actions
events
PACKAGE
PACKAGE
(.dll)
(.dll)
XE ENGINE
PACKAGE
(.dll)
WORKER
DISPATCHER
(+pool)
predicates
XE
SESSXIOEN
SESSXIOEN
SESSION
Events
Targets
Buffers
METADATA EXECUTION
W
W W
W
W W
W
sqllang.dll
sqldk.dll
sqlmin.dll
SQL SERVER CORE ENGINE
messages

7. ORGANISATION DU MOTEUR XE
• Cloisonnement entre moteur d’exécution et
métadonnées: permet d’ajouter aisément de nouveaux
packages et groupes d’évènements dans une release, ou
one-off au besoin pour debug (4 packages en 2008 RTM,
8 en Denali CTP3)
• Les métadonnées sont encapsulées dans des packages
(dll externes) et exposent des catégories d’objets
manipulables dans une session: events, targets, actions,
etc…
• Le moteur fournit un pool de workers autonome pour
réagir de manière asynchrone (consommer un évènement,
écrire dans un target, etc…)

8. PACKAGES & EVENTS
• Les packages contiennent les métadonnées définissant
un ensemble commun d’évènements, de données
associées, d’opérateurs et de destinations de trace.
• Ils sont définis dans une dll externe.
• 8 packages disponibles en CTP3: package0, sqlserver, sqlos,
SecAudit, ucs, sqlclr, filestream, sqlserver*.
• Exposés par sys.dm_xe_packages.
• Certains packages sont privés et non utilisables
directement (SecAudit):
SELECT p.* FROM sys.dm_xe_packages p
WHERE (p.capabilities IS NULL
OR p.capabilities <> 1);

9. PACKAGES & EVENTS
• Les events définissent des points d’intérêt dans le flot
d’exécution du code. Un test booléen détermine à chaque
passage si un évènement est déclaré dans une trace active
et s’il valide le prédicat ou non.
• Les events sont classés selon la norme utilisée pour ETW:
Admin, Analytic, Debug, Operationnal.
• En tout 591 events publics répartis dans 7 packages.
• Exposés par sys.dm_xe_objects avec object_type =
‘event’:
SELECT p.name AS package_name, o.name AS event_name, FROM
sys.dm_xe_packages AS p
JOIN sys.dm_xe_objects AS o ON p.guid = o.package_guid
WHERE (p.capabilities IS NULL OR p.capabilities & 1 = 0)
AND (o.capabilities IS NULL OR o.capabilities & 1 = 0)
AND o.object_type = 'event'

10. PACKAGES & EVENTS
Events par package
(SQL Server Denali CTP3)
sqlserver* = sqlmin.dll

11. PACKAGES & EVENTS
• Package0 (sqldk.dll): package racine, ne contient pas
d’évènements, mais définit les objets de plus haut niveau:
tous les targets, tous les types et messages, plus quelques
prédicats, actions système, et les maps ETW.
• sqlserver (sqllang.dll): définit les principaux évènements
associés aux moteurs relationnel / stockage
(sql_statement_completed, sp_statement_completed, login,
logout, auto_stats, etc…) => 176 events.
• sqlos (sqldk.dll): trace les évènements relatifs à chaque
noeud SQLOS (workers, tasks, async IO, appels systèmes,
scheduling, synchronisation, etc…). Debug avancé => 61
events.

12. PACKAGES & EVENTS
• SecAudit (sqllang.dll) : utilisé en interne pour les Audit
Specifications. Non utilisable dans une session manuelle
(capabilities = 1). *
• ucs (sqllang.dll): Unified Communication Stack. TCP Endpoints,
Service Broker => 21 events.
• sqlclr (sqllang.dll): pour déboguer des problèmes dans un
appdomain SQLCLR (échec allocation de mémoire). => 4
events.
• filestream (sqllang.dll): étend les évènements capturables
depuis sqlserver/sqllang.dll pour filestream, notamment les
interactions avec RsFx. => 13 events.
• sqlserver (sqlmin.dll): grosse extension du package sqlserver
initial (+316 events)
* Pour plus de détails, cf session ‘Sécurité dans SQL Server – D. Barbarin’.

13. TARGETS
• Le target est la destination dans laquelle les informations
capturées sur l’évènement seront stockées pour interrogation.
Souvent les données sont stockées de manière brute pour
gagner de la place.
• Les 6 targets disponibles sont tous définis dans package0:
etw_classic_sync_target, histogram, event_file, event_counter,
pair_matching, ring_buffer.
• Chaque target a ses applications, ses avantages et ses
inconvénients. On peut en déclarer plusieurs par session.
• Synchrone / asynchrone: consommé immédiatement par le SOS
worker, ou consommé plus tard par un des workers dispatché
par le moteur XE.
• Exposés dans sys.dm_xe_objects (object_type=‘target’).

14. RING_BUFFER
• En mémoire seulement, taille par défaut illimitée
(max_memory=+oo, max_events_limit=1000).
• Recyclage soit lorsque le ring buffer est plein ou que le
nombre max d’events à retenir est atteint
(occurrence_number ). Sinon vidé lors d’un restart ou d’un
arrêt de la session XE.
• Exécution asynchrone.
• Les données sont matérialisées en XML à l’interrogation
via sys.dm_xe_session_targets.
• Pas recommandé pour les sessions générant une grande
quantité d’events par seconde, mais pratique si prédicat
très filtrant.

15. EVENT_FILE
• Anciennement asynchronous_file_target.
• Permet de conserver un historique de trace persistant.
• Les données sont matérialisées en XML lors de l’appel à
sys.fn_xe_file_target_read_file().
• Entièrement configurable: nom, chemin, taille max,
rollover, taille d’incrément...
• Exécution asynchrone.
• Plus de fichier XEM en CTP3+.
• Eviter d’agréger directement via la TVF (lent).

16. EVENT_COUNTER
• Anciennement synchronous_event_counter.
• Compte le nombre d’events déclenchés par une session.
• Permet de tester les prédicats et évaluer si le target choisi
est adapté (ring_buffer, event_file).
• Exécution synchrone, mais impact minimum.
• Informations matérialisées en XML lors de l’interrogation
de sys.dm_xe_session_targets (idem ring buffers).

17. HISTOGRAM
• Anciennement bucketizers.
• Permet de regrouper des évènements autour d’un critère
(source). Par exemple compter les recompilations par
database_id.
• Permet ainsi de cibler ses efforts en fonction des résultats.
• Exécution asynchrone (plus de bucketizer synchrone)
• Informations matérialisées en XML lors de l’interrogation
de sys.dm_xe_session_targets (idem ring buffers)

18. PAIR_MATCHING
• Permet de détecter les events qui habituellement vont par
paire et qui sont orphelins: transaction ouverte, connexion
active, verrou ou latch non libéré, requête en cours
d’exécution, etc…
• Nécessite d’établir quels sont les events pairs: BEGIN/END,
ou STARTING/COMPLETED.
• Difficulté de trouver des évènements parfaitement pair-à-pair
(ex: transaction, verrous)
• Limité à 10000 events orphelins en CTP3+ pour éviter les
saturations (max_orphans).

19. ETW_CLASSIC_SYNC_TARGET
• Passerelle vers un consommateur ETW type.
• Permet de mettre en corrélation des traces SQL Server et
système via tracerpt et Windows Performance Analyzer.
• Le format de stockage est varié: texte, csv, XML, etc...
• Une seule session ETW active par instance.
• Les events SQL sont affichés mais pas décryptés par
Performance Analyzer Vista/2008 (provider classic vs
manifest).
• Pas très pratique: nécessite de nombreuses actions
manuelles avec logman pour forcer le target à flusher ses
buffers, et pour réellement couper la trace.

20. AUTRES OBJETS
• Actions: associées à un event. Soit collecte de données
relatives à l’event (44) soit exécution d’une tâche
particulière (3, orientées debug).
• Maps: table de correspondance clés / valeurs (genre
d’EventSubClass plus poussé). Par exemple les différentes
causes de recompilation, les différents waits.
• Types: Définit les types de données utilisés (uint32,
uint64, guid, xml…). Proviennent tous du package0.
• Prédicates: mécanisme de filtrage, permet de diminuer
davantage l’empreinte de XE sur les performances.
• Messages: messages renvoyés par le moteur XE.
• Exposés dans sys.dm_xe_objects (object_type=‘…’).

21. EXPOSITION DES METADATA
sys.dm_xe_packages
package0, sqlserver,
sqlos, SecAudit, ucs,
filestream, sqlclr,
sqlserver (sqlmin)
sys.dm_xe_objects
events, targets,
predicates, actions,
maps, types
sys.dm_xe_object_columns
-Données associées aux events
- Options associées aux targets
sys.dm_xe_map_values
Correspondance clé /
valeur
object name +
package guid
package guid
package guid map name

22. DEMO 1
Metadata

23. SESSION XE
• Une session XE définit une trace composée d’un
ensemble d’évènements, actions prédicats et targets
destinés à être capturés pour analyse.
• Tous les éléments constitutifs sont définis à travers la
commande DML CREATE EVENT SESSION (ou via le
GUI à partir de Denali CTP3+).
• Les sessions peuvent être démarrées, modifiées ou
arrêtées sans avoir à être recréées.
• Options de session XE: mémoire, max_dispatch_latency,
startup_date, etc… dynamiques.

24. GESTION D’UNE SESSION XE
CREATE EVENT SESSION XE_RequetesLentes ON SERVER
ADD EVENT sqlserver.sql_statement_completed
(ACTION (sqlserver.sql_text, sqlserver.plan_handle)
WHERE sqlserver.database_id = 5 AND cpu_time > 10)
ADD TARGET package0.ring_buffer
WITH (max_dispatch_latency = 1 seconds);
ALTER EVENT SESSION XE_RequetesLentes ON SERVER
STATE = START;
…
ALTER EVENT SESSION XE_RequetesLentes ON SERVER
STATE = STOP;
DROP EVENT SESSION XE_RequetesLentes ON SERVER;

25. EXPOSITION DES SESSIONS XE
sys.dm_xe_sessions
Liste des sessions
cataloguées et options
de session
sys.dm_xe_session_targets
Liste et contenu (XML) des
targets par session
sys.dm_xe_session_object_columns
sys.dm_xe_session_event_actions
Liste les actions par event
sys.dm_xe_session_events
Liste les events définis par
session
Session
address
Session
address
Session
address
Liste les options des targets et des
events par session
Session
address

26. EXPLOITER LES RESULTATS
• Les targets couramment utilisés (ring buffer, event file)
stockent des données brutes et compactes.
• Ces données sont exposées en XML via:
sys.dm_xe_session_targets : colonne target_data.
sys.dm_xe_file_target_read_file(): colonne
event_data.
• Pour accéder aux données, il faut pouvoir les parser en
XQuery.
• Des outils existent pour lire le contenu sans passer par du
XQuery (XE code generator - A. Machanic / XE SSMS addin
- J. Kehayias, et le GUI – XE Profiler).

27. EXPLOITER LES RESULTATS: XQUERY
Event=sql_statement_completed
data = ‘cpu_time’
Value = 156000
action = ‘plan_handle’
Value = 0x06000500…

28. EXPLOITER LES RESULTATS: XQUERY
DECLARE @target_data XML
SELECT @target_data = CAST (target_data AS XML)
FROM sys.dm_xe_sessions AS s JOIN sys.dm_xe_session_targets AS t
ON t.event_session_address = s.address
WHERE s.name = 'XE_RequetesLentes'
SELECT
DATEADD (hh, DATEDIFF (hh, GETUTCDATE(), CURRENT_TIMESTAMP),
n.value('(@timestamp)[1]', 'datetime2')) as[timestamp],
n.value('(data[@name="duration"]/value)[1]','bigint') as duration,
n.value('(data[@name="cpu_time"]/value)[1]','bigint') as cpu_time,
n.value('(data[@name="physical_reads"]/value)[1]','bigint') as physical_reads,
n.value('(data[@name="logical_reads"]/value)[1]',’bigint') as logical_reads,
n.value('(action[@name="sql_text"]/value)[1]','nvarchar(max)') as sql_text
FROM @target_data.nodes ('RingBufferTarget/event[@name =
''sql_statement_completed'']') AS q(n)

29. EXPLOITER LES RESULTATS: GUI
* Pour plus de détails, cf session ‘Optimisation &
Troubleshooting – F. Pichaut’.

30. SYSTEM_HEALTH
• Depuis SQL Server 2008 RC0
• Initiative du support PSS
• Démarrée automatiquement lors du startup.
• Ring buffer + event file pour persistance en CTP3+
• Peut être customisée contrairement à la trace par défaut.
• Trace au minimum:
Sessions en erreur avec severity > 20 ou échec mémoire.
Non-yielding schedulers (17883).
Deadlocks.
Certains waits...

31. XE VS SQL TRACE
• Nb d’events (591 contre 180 events en SQL Trace).
• Empreinte réduite côté serveur.
• Choix des targets.
• Capacités de filtrage avancées (idem SARG).
• Correspondance entre events avec sys.trace_events <->
sys.trace_xe_event_map depuis CTP1.
• Evaluer rapidement l’impact de la trace avec un simple
comptage (event_counter).
• system_health + trace par défaut complémentaires.
• SQL Trace obsolète en Denali.

32. BILAN NOUVEAUTES DENALI (XE)
• Interface graphique de gestion intégrée dans SSMS.
• XE Object Model (management & reader APIs)
• Equité parfaite avec les évènements SQL Trace.
• Simplification des targets (plus de fichier xem, plus de
bucketizers sync/async…)
• Gros ajout d’events (+354 events avec les 4 nouveaux
packages sqlserver, filestream, ucs et sqlclr).
• 1 session supplémentaire pour les Availability Groups
(AlwaysOn_health).
• system_health persistant avec event_file.

33. QUELQUES CAS D’UTILISATION
• Détecter quelle est la requête qui a provoqué un page
split (page_split + action sql_text).
• Détecter une erreur 824 (constant_page_corruption
_detected) avant que l’utilisateur qui a reçu le message
n’appelle pour se plaindre.
• Détecter outstanding IO > 15 secondes (long_io_detected)
• Tracer les waits par session.
• Détecter une rupture de connexion (timeout => pas de
statement_completed)
• ...

34. DEMO 2
Sessions XE

35. Merci à nos Sponsors
Rencontrez les dans l’espace partenaires