Partager via


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 :

  • package0 - Objets système Extended Events. Il s'agit du package par défaut.
  • 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.

Diagramme qui montre la relation d’un module, des paquets et des objets.

É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.
En fonctionnement 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. Cela permet à l'utilisateur d'événements étendus 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é. Ce stockage de contexte local permet également de mettre à jour dynamiquement le prédicat, en supprimant 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, ainsi que des 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.