Événements étendus dans Azure SQL

S’applique à :Base de données SQLAzure SQL Managed InstanceBase de données Azure SQL dans Fabric

• Overview
• Mémoire tampon en anneau
• Fichier d’événements

Pour une présentation des événements étendus, consultez :

• Événements étendus
• Démarrage rapide : Événements étendus

L’ensemble de fonctionnalités, les fonctionnalités et les scénarios d’utilisation pour les événements étendus dans Azure SQL Database, SQL Database dans Fabric et Azure SQL Managed Instance sont similaires à ce qui est disponible dans SQL Server. Les principales différences sont les suivantes :

• Dans Azure SQL Database, SQL Database dans Fabric et Azure SQL Managed Instance, la event_file cible utilise toujours des blobs dans Azure Storage, plutôt que des fichiers sur le disque.
  • Dans SQL Server, la event_file cible peut utiliser des fichiers sur disque ou des blocs dans le stockage Azure.
• Dans Azure SQL Database et sql Database dans Fabric, les sessions d’événements sont toujours délimitées à la base de données. Cela signifie que :
  • Une session d’événements d’une base de données ne peut pas accéder aux données ou événements d’une autre base de données.
  • Un événement doit se produire dans le contexte d’une base de données utilisateur à inclure dans une session.
• Dans Azure SQL Managed Instance, vous pouvez créer des sessions d’événements à l'échelle du serveur et à l'échelle de la base de données. Nous vous recommandons d’utiliser des sessions d’événements au niveau du serveur pour la plupart des scénarios.

Get started

Il existe deux exemples de procédure pas à pas pour vous aider à démarrer rapidement avec les événements étendus :

• Créez une session d’événements avec une cible event_file dans Stockage Azure. Cet exemple montre comment capturer des données d’événement dans un fichier (blob) dans stockage Azure à l’aide de la event_file cible, et inclut des conseils de résolution des problèmes pour les erreurs courantes. Utilisez cette option si vous devez conserver de manière permanente les données d’événement capturées ou si vous souhaitez utiliser l’observateur d’événements dans SQL Server Management Studio (SSMS) pour analyser les données capturées.
• Créez une session d’événements avec une cible ring_buffer en mémoire. Cet exemple montre comment capturer les derniers événements d’une session d’événements en mémoire à l’aide de la cible ring_buffer. Utilisez-le comme moyen rapide d’examiner les événements récents pendant les enquêtes ad hoc ou le dépannage, sans avoir à stocker les données d’événement capturées.

Les événements étendus peuvent être utilisés pour la surveillance des réplicas en lecture seule. Pour plus d'informations, consultez Requêtes en lecture sur les réplicas.

Meilleures pratiques

Adoptez les meilleures pratiques suivantes pour utiliser des événements étendus de manière sécurisée, fiable et sans affecter les performances de charge de travail et d’intégrité du moteur de base de données.

• Si vous utilisez la cible event_file :
  • Selon les événements ajoutés à une session, les fichiers produits par la event_file cible peuvent contenir des données sensibles. Examinez attentivement les attributions de rôles RBAC et les listes de contrôle d’accès (ACL) sur le compte de stockage et le conteneur, y compris l’accès hérité, pour éviter d’accorder un accès en lecture inutile. Suivez le principe du privilège minimum.
  • Utiliser un compte de stockage dans la même région Azure que la base de données ou l’instance gérée où vous créez des sessions d’événements.
  • Aligner la redondance du compte de stockage avec la redondance de la base de données, du pool élastique, ou de l’instance gérée. Pour les ressources localement redondantes, utiliser LRS, GRS ou RA-GRS. Pour les ressources redondantes interzones, utiliser ZRS, GZRS ou RA-GZRS. Pour plus d’informations, consultez Redondance de Stockage Azure.
  • N’utilisez pas de niveau d’accès d’objets blobs autre que Hot.
  • N’activez pas l’espace de noms hiérarchique pour le compte de stockage.
• Si vous souhaitez créer une session d’événements en cours d’exécution continue qui démarre automatiquement après chaque redémarrage de moteur de base de données (par exemple, après un basculement ou un événement de maintenance), incluez l’option de session d’événements de STARTUP_STATE = ON dans vos CREATE EVENT SESSION ou instructions ALTER EVENT SESSION.
• À l’inverse, utilisez STARTUP_STATE = OFF pour les sessions d’événements à court terme, telles que celles utilisées dans le cadre d’un dépannage ad hoc.
• Dans la base de données Azure SQL, ne lisez pas les événements de blocage de la session d’événements intégrée dl. S’il existe un grand nombre d’événements de blocage collectés, leur lecture avec la fonction sys.fn_xe_file_target_read_file() peut entraîner une erreur de mémoire insuffisante dans la base de données master. Cela peut affecter le traitement de la connexion et entraîner une panne d’application. Pour connaître les méthodes recommandées pour surveiller les blocages, consultez Collecter des graphiques de blocage dans la base de données Azure SQL avec des événements étendus.

Cibles de session d’événements

Pour plus d’informations sur les cibles d’événements étendus prises en charge dans Azure SQL Database, SQL Database dans Fabric, Azure SQL Managed Instance et SQL Server, consultez Cibles pour les événements étendus.

différences Transact-SQL

Lorsque vous exécutez les instructions CREATE EVENT SESSION, ALTER EVENT SESSION et DROP EVENT SESSION dans SQL Server et dans Azure SQL Managed Instance, vous utilisez la clause ON SERVER. Dans Azure SQL Database, vous utilisez la clause ON DATABASE à la place, car dans Azure SQL Database, les sessions d’événements sont étendues à la base de données.

Affichages catalogue des événements étendus

Les événements étendus fournissent plusieurs affichages catalogue. Les affichages catalogue vous indiquent les métadonnées ou la définition de session d’événements. Les affichages ne renvoient pas d’informations sur les instances des sessions d’événements actives.

Pour obtenir la liste des vues de catalogue pour chaque plateforme, consultez Extended Events Catalog Views.

Vues de gestion dynamique des événements étendus

Les événements étendus fournissent plusieurs vues de gestion dynamique (DMV). Les DMV renvoient des informations sur les sessions d’événements démarrées.

Pour obtenir la liste des vues de gestion dynamique des événements étendus pour chaque plateforme, consultez les vues de gestion dynamique des événements étendus.

Vues de gestion dynamique courantes

Il existe d’autres DMV d’événements étendus communes à Azure SQL Database, Azure SQL Managed Instance et SQL Server :

• sys.dm_xe_map_values
• sys.dm_xe_object_columns
• sys.dm_xe_objects
• sys.dm_xe_packages

Événements, actions et cibles disponibles

Vous pouvez obtenir des événements, des actions et des cibles disponibles à l’aide de cette requête :

SELECT o.object_type,
       p.name AS package_name,
       o.name AS db_object_name,
       o.description AS db_obj_description
FROM sys.dm_xe_objects AS o
INNER JOIN sys.dm_xe_packages AS p
ON p.guid = o.package_guid
WHERE o.object_type IN ('action','event','target')
ORDER BY o.object_type,
         p.name,
         o.name;

Permissions

Consultez les autorisations pour obtenir des autorisations détaillées par plateforme.

Autorisation du conteneur de stockage et contrôle

Lorsque vous utilisez la event_file cible avec des objets blob de stockage Azure, le moteur de base de données qui exécute la session d’événements doit avoir un accès spécifique au conteneur d’objets blob. Vous pouvez accorder cet accès de l’une des manière suivantes :

• Attribuez le rôle RBAC Contributeur aux données Blob du stockage à l’identité managée du serveur logique Azure SQL ou de l’instance Azure SQL Managed Instance sur le conteneur, puis créez des informations d’identification afin d’indiquer au moteur de base de données d’utiliser une identité managée pour l’authentification.

  En guise d’alternative à l’attribution du rôle RBAC Contributeur aux données Blob du stockage, vous pouvez attribuer les actions RBAC suivantes :

  Namespace	Action
  Microsoft.Storage/storageAccounts/blobServices/containers/	read
  Microsoft.Storage/storageAccounts/blobServices/containers/blobs/	delete
  Microsoft.Storage/storageAccounts/blobServices/containers/blobs/	read
  Microsoft.Storage/storageAccounts/blobServices/containers/blobs/	write

• Créez un jeton SAS pour le conteneur, puis stockez-le dans des informations d’identification.

  Dans la base de données Azure SQL, vous devez utiliser l’identifiant délimité à la base de données. Dans Azure SQL Managed Instance et SQL Server, utilisez des informations d’identification au niveau du serveur.

  Le jeton SAS que vous créez pour votre conteneur Stockage Azure doit répondre aux exigences suivantes :

  • Disposez des autorisations rwdl (Read, Write, Delete, List).
  • Disposer de l’heure de début et de l’heure d’expiration qui englobent la durée de vie de la session d’événements.
  • Il ne doit avoir aucune restriction des adresses IP.

Gouvernance des ressources

Dans Azure SQL Database, la consommation de mémoire par les sessions d’événements étendues est contrôlée dynamiquement par les Moteur de base de données pour réduire la contention des ressources.

Il existe une limite de mémoire disponible pour les sessions d’événements :

• Dans une base de données unique, la mémoire de session totale est limitée à 128 Mo.
• Dans un pool élastique, les bases de données individuelles sont soumises aux limites des bases de données uniques et au total, elles ne peuvent pas dépasser 512 Mo.

Si vous recevez un message d’erreur référençant une limite de mémoire, les actions correctives que vous pouvez effectuer sont les suivantes :

• Exécuter moins de sessions d’événement simultanées.
• Utilisation CREATE et ALTER instructions pour les sessions d’événements, réduisez la quantité de mémoire que vous spécifiez dans la MAX_MEMORY clause de la session.

Note

Dans les événements étendus, la clause MAX_MEMORY apparaît dans deux contextes : lors de la création ou de la modification d’une session (au niveau de la session) et lors de l’utilisation de la cible ring_buffer (au niveau cible). Les limites ci-dessus s’appliquent à la mémoire au niveau de la session.

Le nombre de sessions d’événements démarrées dans Azure SQL Database est limité :

• Dans une base de données unique, la limite est de 100.
• Dans un pool élastique, la limite est de 100 sessions étendues à la base de données par pool.

Dans les pools élastiques denses, le démarrage d’une nouvelle session d’événements étendue peut échouer en raison de contraintes de mémoire, même lorsque le nombre total de sessions démarrées est inférieur à 100.

Pour rechercher la mémoire totale consommée par une session d’événements, exécutez la requête suivante lors de la connexion à la base de données où la session d’événements est démarrée :

SELECT name AS session_name,
       total_buffer_size + total_target_memory AS total_session_memory
FROM sys.dm_xe_database_sessions;

Pour trouver la mémoire totale de session d’événements pour un pool élastique, cette requête doit être exécutée dans chaque base de données du pool.

Contenu connexe

• Événements étendus
• Démarrage rapide : Événements étendus