138
Chapitre 5. Analyse des performances
ON SERVER
ADD EVENT sqlos.async_io_requested
ADD EVENT sqlos.async_io_completed
ADD EVENT sqlserver.database_transaction_begin
ADD EVENT sqlserver.database_transaction_end
ADD TARGET package0.etw_classic_sync_target
(SET default_etw_session_logfile_path = N'C:\temp\sqletw.etl');
Pour démarrer la session :
CREATE EVENT SESSION masession
ON SERVER
STATE = start;
Vous ne pouvez créer la session et la démarrer en même temps, un peu comme
avec les procédures stockées de définition de SQL Trace. Les deux opérations ne
peuvent en effet être simultanément transactionnelles : on ne peut pas annuler la
création des métadonnées et l’envoi des événements en même temps, puisqu’il est
impossible de « désenvoyer » les événements.
Les sessions peuvent être requêtées dans les vues systèmes suivantes :
• sys.server_event_sessions
• sys.server_event_session_actions
• sys.server_event_session_events
• sys.server_event_session_fields
• sys.server_event_session_targets
Pour améliorer les performances de la session, permettez le vidage de buffers en
cas de manque, ceci en activant l’option ALLOW SINGLE EVENT LOSS, ou ALLOW MULTIPLE EVENT LOSS. Le nombre d’événements perdus est indiqué avec l’option ALLOW
SINGLE EVENT LOSS. L’option ALLOW MULTIPLE EVENT LOSS libère en revanche la totalité d’un buffer, qui peut contenir un grand nombre d’événements, et rend impossible
le retour du nombre d’événements perdus. Dans la plupart des cas, l’option ALLOW
SINGLE EVENT LOSS est recommandée, car elle offre de bonnes conditions de performances.
NO_EVENT_LOSS
Certains événements bas niveau ne peuvent être paramétrés avec NO_EVENT_LOSS, car l’attente
sur la libération de buffer serait trop handicapante pour le système. C’est le cas d’événements
comme FILE_IO ou CONTEXT_SWITCH. Dans la grande majorité des cas,
ALLOW_SINGLE_EVENT_LOSS est parfait pour récupérer des informations utiles.
Toute l’architecture des événements étendus est visible à travers des vues de gestion dynamique préfixées par sys.dm_xe_.
La vraie question, au moment où nous écrivons ce livre, est : que faire des événements déclenchés ? Deux solutions :
Chapitre 5. Analyse des performances
ON SERVER
ADD EVENT sqlos.async_io_requested
ADD EVENT sqlos.async_io_completed
ADD EVENT sqlserver.database_transaction_begin
ADD EVENT sqlserver.database_transaction_end
ADD TARGET package0.etw_classic_sync_target
(SET default_etw_session_logfile_path = N'C:\temp\sqletw.etl');
Pour démarrer la session :
CREATE EVENT SESSION masession
ON SERVER
STATE = start;
Vous ne pouvez créer la session et la démarrer en même temps, un peu comme
avec les procédures stockées de définition de SQL Trace. Les deux opérations ne
peuvent en effet être simultanément transactionnelles : on ne peut pas annuler la
création des métadonnées et l’envoi des événements en même temps, puisqu’il est
impossible de « désenvoyer » les événements.
Les sessions peuvent être requêtées dans les vues systèmes suivantes :
• sys.server_event_sessions
• sys.server_event_session_actions
• sys.server_event_session_events
• sys.server_event_session_fields
• sys.server_event_session_targets
Pour améliorer les performances de la session, permettez le vidage de buffers en
cas de manque, ceci en activant l’option ALLOW SINGLE EVENT LOSS, ou ALLOW MULTIPLE EVENT LOSS. Le nombre d’événements perdus est indiqué avec l’option ALLOW
SINGLE EVENT LOSS. L’option ALLOW MULTIPLE EVENT LOSS libère en revanche la totalité d’un buffer, qui peut contenir un grand nombre d’événements, et rend impossible
le retour du nombre d’événements perdus. Dans la plupart des cas, l’option ALLOW
SINGLE EVENT LOSS est recommandée, car elle offre de bonnes conditions de performances.
NO_EVENT_LOSS
Certains événements bas niveau ne peuvent être paramétrés avec NO_EVENT_LOSS, car l’attente
sur la libération de buffer serait trop handicapante pour le système. C’est le cas d’événements
comme FILE_IO ou CONTEXT_SWITCH. Dans la grande majorité des cas,
ALLOW_SINGLE_EVENT_LOSS est parfait pour récupérer des informations utiles.
Toute l’architecture des événements étendus est visible à travers des vues de gestion dynamique préfixées par sys.dm_xe_.
La vraie question, au moment où nous écrivons ce livre, est : que faire des événements déclenchés ? Deux solutions :