Packages d’événements étendus

S’applique à :SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Un package est un conteneur pour les objets Événements étendus dans le Moteur de base de données SQL Server. Par exemple, les packages suivants existent dans n’importe quelle Moteur de base de données qui prend en charge les événements étendus :

  • package0 - Objets système d’événements étendus. Il s'agit du package par défaut.
  • sqlserver- Objets liés au Moteur de base de données
  • sqlos - Objets associés au système d’exploitation SQL (SQLOS).

Remarque

Le SecAudit package est utilisé en interne par la fonctionnalité Audit. Aucun des objets de ce package n’est disponible via le langage de définition de données d’événements étendus (DDL).

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 tous les objets suivants, qui sont abordés plus en détail plus loin 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 les sessions d’événements étendus.

Contenu d'un package

L’illustration suivante montre les objets qui peuvent exister dans un package.

Diagram that shows the relationship of a module, packages, and objects.

Événements

Les événements surveillent les points d’intérêt dans le chemin d’exécution d’un programme, comme SQL Server. Lorsqu’un événement se déclenche, il contient le fait que le point d’intérêt a été atteint et les informations d’état à partir du moment où l’événement a été déclenché.

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 au déclenchement de l’événement.

Un ensemble d’événements dans un package ne peut pas changer une fois que le package est inscrit auprès d’événements étendus.

Tous les événements ont un schéma avec version qui définit leur contenu. Ce schéma est composé de colonnes d’événements avec des types définis. 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 besoin d’utiliser 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 l’audience d’un événement. Les canaux sont décrits dans le tableau suivant.

Terme Définition
Administrateur Administration événements sont principalement destinés aux utilisateurs finaux, aux administrateurs et au support. Les événements trouvés dans le canal Administration peuvent indiquer un problème avec une solution bien définie sur laquelle un administrateur peut agir. Un exemple d’événement d’administrateur est lorsqu’une application ne parvient pas à se connecter. Ces événements sont documentés ou sont associés à un message qui indique au lecteur ce qu’il faut 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 principalement utilisés par les développeurs pour diagnostiquer un problème de débogage.

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 retournés par les événements peuvent changer, devenir non valides ou être supprimés dans les versions ultérieures de l’Moteur de base de données sans préavis.

Un mot clé est spécifique à l’application et permet un regroupement plus précis d’événements connexes, ce qui facilite la spécification et la récupération d’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. Les événements étendus fournissent plusieurs types cibles que vous pouvez utiliser selon les besoins pour diriger la sortie d’événement. Pour plus d’informations, consultez Cibles pour les événements étendus.

Vous utilisez la ADD TARGET clause 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

Les actions destinées à 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 un vidage de processus
  • Stocker les informations d’état dans un contexte local à l’aide du stockage variable
  • Données d’événement d’agrégation
  • Ajouter des données aux données d’événement

Voici quelques exemples courants d’utilisation d’actions :

  • Collecter le texte SQL d’une requête exécutée par le thread qui déclenche l’événement
  • Collecter le handle du 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, notamment le nom d’hôte du client, le nom du 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 ACTION clause 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 peuvent être utilisés pour créer des prédicats qui retournent true une fois toutes les n minutes ou chaque fois qu’un événement se déclenche. 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 un prédicat antérieur case activée échoue.

Vous utilisez la WHERE clause pour ajouter des prédicats à une session d’événements.

Types

Dans un package, chaque objet Événements étendus a un type. Les types suivants sont utilisés :

  • 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';

La requête précédente génère la sortie suivante :

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

À l’aide de cette table comme exemple, supposons que vous disposez d’une colonne nommée lock_modeet que sa valeur est 5. Le tableau indique que le 5 mappage correspond Xà , ce qui signifie que le type de verrou est Exclusif.