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éessqlos
- 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.
É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_mode
et que sa valeur est 5
. Le tableau indique que le 5
mappage correspond X
à , ce qui signifie que le type de verrou est Exclusif.
Contenu associé
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour