Surveiller Analysis Services avec des événements étendus SQL Server

S’applique à : SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Les événements étendus (xEvents) sont un système de suivi et de surveillance des performances léger qui utilise très peu de ressources système, ce qui en fait un outil idéal pour diagnostiquer les problèmes sur les serveurs de production et de test. Il est également hautement évolutif, configurable et, dans SQL Server 2016, plus facile à utiliser grâce à la nouvelle prise en charge des outils intégrés. Dans SQL Server Management Studio (SSMS), sur les connexions à des instances Analysis Services, vous pouvez configurer, exécuter et surveiller une trace dynamique, comme à l’aide de SQL Server Profiler. L’ajout d’outils optimisés doit faire des xEvents un remplacement plus raisonnable du SQL Server Profiler et crée une meilleure symétrie plus dans la façon dont vous diagnostiquez des problèmes dans votre moteur de base de données et les charges de travail Analysis Services.

Outre SQL Server Management Studio, vous pouvez également configurer SQL Server Analysis Services sessions d’événements étendus à l’ancienne, par le biais de scripts XMLA, comme pris en charge dans les versions précédentes.

Tous les événements Analysis Services peuvent être capturés et ciblés sur des consommateurs spécifiques, comme défini dans Événements étendus.

Utiliser SSMS pour configurer Analysis Services

Pour les instances tabulaires et multidimensionnelles, SSMS affiche un dossier de gestion qui contient des sessions xEvent initiées par l’utilisateur. Vous pouvez exécuter plusieurs sessions simultanément. Toutefois, dans l’implémentation actuelle, l’interface utilisateur des événements étendus SQL Server Analysis Services ne prend pas en charge la mise à jour ou la relecture d’une session existante.

Le dossier Gestion n’est pas pris en charge lors de l’utilisation de SSMS pour se connecter à un espace de travail Power BI Premium.

Choisir des événements

Si vous connaissez déjà les événements à capturer, le moyen le plus simple de les ajouter à la trace est de les rechercher. Sinon, les événements suivants sont fréquemment utilisés pour les opérations de surveillance :

• CommandBegin et CommandEnd.

• QueryBegin, QueryEndet QuerySubcubeVerbose (affiche entièrement la requête MDX ou DAX envoyée au serveur), plus ResourceUsage pour les statistiques sur les ressources utilisées par la requête et le nombre de lignes retournées.

• ProgressReportBegin et ProgressReportEnd (pour les opérations de traitement).

• AuditLogin et AuditLogout (capture l’identité de l’utilisateur sous lequel une application cliente se connecte à Analysis Services).

Choisir le stockage des données

Une session peut être transmise en continu en direct dans une fenêtre de Management Studio ou enregistrée dans un fichier pour une analyse ultérieure à l’aide de Power Query ou Excel.

• event_file stocke les données de session dans un fichier .xel.

• event_stream active l’option Surveiller les données actives dans Management Studio.

• ring_buffer stocke les données de session en mémoire pendant que le serveur est en cours d’exécution. Les données de session sont supprimées au redémarrage du serveur

Ajouter des champs d’événement

Veillez à configurer la session de manière à inclure des champs d’événement afin de pouvoir facilement voir les informations qui vous intéressent.

L’optionConfigurer se trouve à l’extrémité de la boîte de dialogue.

Dans la configuration, sous l’onglet Champs d’événement, sélectionnez TextData pour que ce champ s’affiche en regard de l’événement en indiquant les valeurs de retour, notamment les requêtes exécutées sur le serveur.

Après avoir configuré une session pour les événements et le stockage de données souhaités, vous pouvez cliquer sur le bouton script pour envoyer votre configuration à l’une des destinations prises en charge, y compris un fichier, une nouvelle requête dans SQL Server Management Studio et le Presse-papiers.

Actualisation de Sessions

Une fois la session créée, veillez à actualiser le dossier Sessions dans Management Studio pour voir la session que vous venez de créer. Si vous avez configuré un event_stream, vous pouvez cliquer sur le nom de la session et choisir Surveiller les données actives pour surveiller l’activité du serveur en temps réel.

Script XMLA pour démarrer

Le traçage d'événements étendus est activé à l'aide d'une commande de script de création d'objet XMLA semblable à celle ci-dessous :

<Execute ...>  
   <Command>  
      <Batch ...>  
         <Create ...>  
            <ObjectDefinition>  
               <Trace>  
                  <ID>trace_id</ID>  
                  <Name>trace_name</Name>  
                  <ddl300_300:XEvent>  
                     <event_session ...>  
                        <event package="AS" name="AS_event">  
                           <action package="PACKAGE0" .../>  
                        </event>  
                        <target package="PACKAGE0" name="asynchronous_file_target">  
                           <parameter name="filename" value="data_filename.xel"/>  
                           <parameter name="metadatafile" value="metadata_filename.xem"/>  
                        </target>  
                     </event_session>  
                  </ddl300_300:XEvent>  
               </Trace>  
            </ObjectDefinition>  
         </Create>  
      </Batch>  
   </Command>  
   <Properties></Properties>  
</Execute>  

Les éléments suivants seront définis par l'utilisateur, selon les besoins de suivi :

trace_id
Définit l'identificateur unique pour cette trace.

trace_name
Nom donné à cette trace ; habituellement une définition compréhensible de la trace. On utilise généralement la valeur trace_id comme nom.

AS_event
Événement Analysis Services à exposer. Consultez Événements de trace Analysis Services pour les noms des événements.

data_filename
Nom du fichier qui contient les données d'événement. Ce nom est suffixé avec un horodatage pour éviter que les données soient écrasées si la trace est envoyée plusieurs fois.

metadata_filename
Nom du fichier qui contient les métadonnées d'événement. Ce nom est suffixé avec un horodatage pour éviter que les données soient écrasées si la trace est envoyée plusieurs fois.

Script XMLA à arrêter

Pour arrêter les événements étendus qui tracent l'objet, vous devez supprimer cet objet à l'aide d'une commande de script de suppression d'objet XMLA semblable à celle ci-dessous :

<Execute xmlns="urn:schemas-microsoft-com:xml-analysis">  
   <Command>  
      <Batch ...>  
         <Delete ...>  
            <Object>  
               <TraceID>trace_id</TraceID>  
            </Object>  
         </Delete>  
      </Batch>  
   </Command>  
   <Properties></Properties>  
</Execute>  
  

Les éléments suivants seront définis par l'utilisateur, selon les besoins de suivi :

trace_id
Définit l'identificateur unique pour la trace à supprimer.

Voir aussi

événements SQL Server étendus