Événements étendus dans la base de données Azure SQL et Azure SQL Managed Instance

S’applique à : Azure SQL Database Azure SQL Managed Instance

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

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

L’ensemble de caractéristiques, fonctions et scénarios d'utilisation des événements étendus dans la base de données Azure SQL et Azure SQL Managed Instance sont similaires à ceux disponibles dans SQL Server. Les principales différences sont les suivantes :

• La cible event_file utilise toujours des objets blobs dans Stockage Azure, plutôt que des fichiers sur le disque.
• Dans la base de données Azure SQL, les sessions d'événements sont toujours 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.

Démarrage

Deux exemples vous aideront à bien démarrer avec les événements étendus dans la base de données Azure SQL et Azure SQL Managed Instance :

• Créez une session avec une cible event_file dans Stockage Azure. Cet exemple montre comment capturer des données d’événement dans un fichier (objet blob) dans Stockage Azure à l’aide de la cible event_file. 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 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.

Bonnes pratiques

Adoptez les meilleures pratiques suivantes pour utiliser les événements étendus dans la base de données Azure SQL et Azure SQL Managed Instance de manière fiable et sans affecter l’intégrité du moteur de base de données et les performances de la charge de travail.

• Si vous utilisez la cible event_file :
  • 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.
• 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 avoir un impact sur 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

La base de données Azure SQL et Azure SQL Managed Instance prennent en charge les cibles suivantes :

• Cible event_file Écrit les mémoires tampons complètes dans un conteneur Azure Storage.
• Cible ring_buffer Contient les données d’événement en mémoire jusqu’à ce qu’elles soient remplacées par de nouvelles données d’événement.
• Cible event_counter Compte tous les événements qui se sont produits au cours d’une session d’événements étendus.
• Cible d’histogramme Compte les occurrences de différentes valeurs de champs ou d’actions dans des compartiments distincts.
• event_stream. Diffuse les données d’événement vers une application .NET.

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.

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.

DMV communes

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

Tout comme dans SQL Server, vous pouvez obtenir les événements, les actions et les 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;

autorisations

Dans la base de données Azure SQL et Azure SQL Managed Instance, les événements étendus prennent en charge un modèle d’autorisation granulaire. Les autorisations suivantes peuvent être accordées :

CREATE ANY DATABASE EVENT SESSION
DROP ANY DATABASE EVENT SESSION
ALTER ANY DATABASE EVENT SESSION
ALTER ANY DATABASE EVENT SESSION ADD EVENT
ALTER ANY DATABASE EVENT SESSION DROP EVENT
ALTER ANY DATABASE EVENT SESSION ADD TARGET
ALTER ANY DATABASE EVENT SESSION DROP TARGET
ALTER ANY DATABASE EVENT SESSION ENABLE
ALTER ANY DATABASE EVENT SESSION DISABLE
ALTER ANY DATABASE EVENT SESSION OPTION

CREATE ANY EVENT SESSION
DROP ANY EVENT SESSION
ALTER ANY EVENT SESSION
ALTER ANY EVENT SESSION ADD EVENT
ALTER ANY EVENT SESSION DROP EVENT
ALTER ANY EVENT SESSION ADD TARGET
ALTER ANY EVENT SESSION DROP TARGET
ALTER ANY EVENT SESSION ENABLE
ALTER ANY EVENT SESSION DISABLE
ALTER ANY EVENT SESSION OPTION

Pour plus d’informations sur ce que contrôle chacune de ces autorisations, consultez CREATE EVENT SESSION, ALTER EVENT SESSION et DROP EVENT SESSION.

Toutes ces autorisations sont incluses dans l’autorisation CONTROL de base de données ou d’instance gérée. Dans la base de données Azure SQL, le propriétaire de base de données (dbo), les membres du rôle de base de données db_owner et l’administrateur du serveur logique contiennent l’autorisation CONTROL de base de données. Dans Azure SQL Managed Instance, les membres du rôle serveur sysadmin détiennent l’autorisation CONTROL sur l’instance.

Autorisation du conteneur de stockage et contrôle

Lorsque vous utilisez la cible event_file, les données d’événement sont stockées dans des objets blobs dans un conteneur Stockage Azure. La Moteur de base de données en cours d’exécution de la session d’événements doit avoir un accès spécifique à ce conteneur. Vous pouvez accorder cet accès de l’une des manières suivantes :

• Attribuez le rôle RBAC contributeur aux données blob de stockage à l’identité managée du serveur logique Azure SQL ou de l’instance managée Azure SQL sur le conteneur et créez des informations d’identification pour indiquer au Moteur de base de données d’utiliser l’identité managée pour l’authentification.

  En guise d’alternative à l’attribution du rôle RBAC contributeur aux données blob de stockage, vous pouvez affecter les actions RBAC suivantes :

  Espace de noms	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

  Remarque

  L’utilisation de l’identité managée avec des sessions d’événements étendues est en préversion.

• Créez un jeton SAP pour le conteneur et stockez le jeton 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, utiliser un identifiant au niveau du serveur.

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

  • Disposez des rwdl autorisations (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.

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