Packages Extended Events
S’applique à : SQL Server base de données Azure SQL Azure SQL Managed Instance
Un package est un conteneur d’objets Extended Events dans le moteur de base de données de SQL Server. Par exemple, les packages suivants existent dans n’importe quel moteur de base de données qui prend en charge les Extended Events :
Package | Description |
---|---|
package0 (valeur par défaut) |
Objets système Extended Events. |
sqlserver |
Objets liés au moteur de base de données. |
sqlos |
Objets liés au système d’exploitation SQL (SQLOS). |
Remarque
Le package SecAudit
est utilisé en interne par la fonctionnalité Audit. Aucun des objets dans ce package n'est disponible via le langage de définition de données (DDL) Extended Events.
Les packages sont identifiés par un nom, un GUID et le module binaire qui contient le package. Un module peut être un exécutable ou une bibliothèque de liens dynamiques. Pour plus d’informations, consultez sys.dm_xe_packages.
Un package peut contenir l'ensemble ou une partie des objets suivants, présentés plus en détails ultérieurement dans cet article :
- Événements
- Targets
- Actions
- Types
- Prédicats
- Maps
Des objets de packages différents peuvent être mélangés dans une session d'événements. Pour plus d’informations, consultez Sessions Extended Events.
Contenu d'un package
L’illustration suivante montre les objets qui peuvent exister dans un package.
Événements
Les événements surveillent les détails intéressants dans le chemin d'exécution d'un programme, tel que SQL Server. Lorsqu’un événement se déclenche, il contient le fait que le détail intéressant s'est manifesté et fournit les informations d'état correspondant au moment du déclenchement de l'événement.
Les événements peuvent être utilisés uniquement à des fins de suivi ou pour déclencher des actions. Ces actions peuvent être synchrones ou asynchrones.
Remarque
Un événement n'a aucune connaissance des actions qui peuvent être déclenchées en réponse à son déclenchement.
Un jeu d'événements dans un package ne peut pas changer une fois que le package a été enregistré avec les événements étendus.
Tous les événements ont un schéma avec contrôle de version qui définit leur contenu. Ce schéma est composé de colonnes d'événements de types déterminés. Un événement d'un type spécifique doit toujours fournir ses données exactement dans le même ordre que celui spécifié dans le schéma. Toutefois, une cible d'événement n'a pas à consommer toutes les données fournies.
Catégorisation des événements
Les événements étendus utilisent un modèle de catégorisation d'événements semblable au suivi d'événements pour Windows. Deux propriétés d'événement sont utilisées pour la catégorisation, canal et mot clé. L'utilisation de ces propriétés prend en charge l'intégration des événements étendus avec le suivi ETW et ses outils.
Un canal identifie le public concerné par un événement. Les canaux sont décrits dans le tableau ci-dessous.
Terme | Définition |
---|---|
Administrateur | Les événements administratifs sont principalement destinés à utilisateurs finaux, administrateurs et support technique. Les événements qui se trouvent dans le canal Admin peuvent indiquer un problème avec une solution bien définie sur laquelle un administrateur peut agir. Un exemple d’événement admin est lorsqu’une application ne parvient pas à se connecter. Ces événements sont soit documentés, soit associés à un message qui indique au lecteur quoi faire pour corriger le problème. |
Opérationnel | Les événements opérationnels permettent d'analyser et de diagnostiquer un problème ou une occurrence. Ils permettent de déclencher des outils ou des tâches en fonction du problème ou de l'occurrence. |
Analytiques | Les événements analytiques sont publiés selon un volume élevé. Ils décrivent le fonctionnement des programmes et sont généralement utilisés dans les enquêtes sur les performances. |
Déboguer | Les événements de débogage sont utilisés principalement par les développeurs pour diagnostiquer un problème afin de le résoudre. Les événements du canal de débogage renvoient des données d'état internes propres à l'implémentation. Les schémas et les données renvoyés par les événements peuvent changer, devenir invalides ou être supprimés dans les futures versions du moteur de base de données sans préavis. |
Un mot-clé est spécifique à l’application et permet un regroupement plus fin d'événements associés, ce qui vous permet de spécifier et de récupérer plus aisément un événement que vous souhaitez utiliser dans une session. Vous pouvez utiliser la requête suivante pour obtenir des informations sur un mot clé.
SELECT map_value AS Keyword
FROM sys.dm_xe_map_values
WHERE name = 'keyword_map';
Targets
Les cibles sont des consommateurs d'événements. Les cibles traitent des événements, de façon synchrone sur le thread qui déclenche l'événement ou de façon asynchrone sur un thread fourni par le système. Extended Events fournit plusieurs types de cibles que vous pouvez utiliser d'une manière appropriée pour diriger les données de sortie des événements. Pour plus d'informations, consultez Cibles des Événements étendus.
Vous utilisez la clause ADD TARGET
pour ajouter des cibles à une session d’événements.
Actions
Une action est une réponse de programmation ou une série de réponses à un événement. Les actions sont liées à un événement, et chaque événement peut avoir son propre ensemble d’actions.
Remarque
Des actions prévues pour des événements spécifiques ne peuvent pas être liées à d’autres événements.
Une action liée à un événement est appelée de façon synchrone sur le thread qui a déclenché l'événement. Il existe de nombreux types d'actions et elles présentent une gamme étendue de capacités. Les actions peuvent correspondre aux opérations suivantes :
- Capturer une image mémoire d’un processus
- Stocker des informations d'état dans un contexte local par le biais du stockage de variables
- Agréger des données d'événement
- Ajouter des données à des données d'événement
Voici des exemples courants d’utilisation des mesures :
- Collecter le texte SQL d’une requête exécutée par le thread exécutant l’événement
- Collecter le gestionnaire de plan de requête, le hachage de requête et le hachage de plan de requête
- Collectez les attributs d’une session qui provoque le déclenchement de l’événement, y compris le nom d’hôte client, le nom principal, l’ID de connexion, etc.
- Collecter la pile des appels
- Capturer un vidage de processus lorsqu’une erreur spécifique se produit
Vous utilisez la clause ACTION
pour ajouter des actions à une session d’événements.
Prédicats
Les prédicats sont un ensemble de règles logiques qui permettent d’évaluer des événements lorsqu’ils sont traités. Les prédicats permettent à l’utilisateur d’Extended Events de capturer de manière sélective des données d’événement en fonction de critères spécifiques.
Les prédicats peuvent stocker des données dans un contexte local, qui peut être utilisé pour créer des prédicats qui retournent la valeur true une fois toutes les n minutes ou toutes les n fois qu’un événement est déclenché. Vous pouvez également utiliser ce stockage de contexte local pour mettre à jour dynamiquement le prédicat, ce qui supprime le déclenchement futur des événements si les événements contiennent des données semblables.
Les prédicats ont la capacité de récupérer les informations de contexte, telles que l’ID de thread et les données spécifiques à l’événement. Les prédicats sont évalués en tant qu'expressions booléennes complètes et prennent en charge le court-circuit au premier point où il apparaît que l'expression entière est fausse.
Remarque
Les prédicats avec effets secondaires peuvent ne pas être évalués si une vérification de prédicat antérieure échoue.
Vous utilisez la clause WHERE
pour ajouter des prédicats à une session d’événement.
Types
Dans un package, chaque objet Extended Events a un type. Les types suivants sont connus :
action
event
message
pred_compare
pred_source
target
type
Pour plus d’informations, consultez sys.dm_xe_objects.
Maps
Une table de mappage mappe une valeur interne à une chaîne, ce qui permet à un utilisateur de savoir ce que la valeur représente. Au lieu d'obtenir simplement une valeur numérique, un utilisateur peut obtenir une description explicite de la valeur interne. La requête ci-dessous indique comment obtenir les valeurs de mappage.
SELECT map_key,
map_value
FROM sys.dm_xe_map_values
WHERE name = 'lock_mode';
L’exemple précédent produit la sortie ci-dessous :
map_key | map_value |
---|---|
0 | NL |
1 | SCH_S |
2 | SCH_M |
3 | S |
4 | U |
5 | X |
6 | IS |
7 | IU |
8 | IX |
9 | SIU |
10 | SIX |
11 | UIX |
12 | BU |
13 | RS_S |
14 | RS_U |
15 | RI_NL |
16 | RI_S |
17 | RI_U |
18 | RI_X |
19 | RX_S |
20 | RX_U |
21 | LAST_MODE |
En utilisant cette table comme exemple, supposez que vous possédez une colonne nommée lock_mode
et que sa valeur est 5
. Le tableau indique que 5
correspond à X
, ce qui signifie que le type de verrou est Exclusif.