Slidedeck de ma session aux JSS 2011 sur Xevents

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