Les cubes nécessitent une surveillance fréquente car leur productivité diminue assez souvent (ralentissements lors de la construction des requêtes, incrément du temps de traitement). Pour découvrir la raison de la diminution, nous devons surveiller notre système. Pour cela, nous utilisons SQL Server Profiler. Cependant, Microsoft prévoit d'exclure cet outil de traçage SQL dans les versions ultérieures. Le principal inconvénient de l'outil est l'intensité des ressources, et il doit être exécuté avec précaution sur un serveur de production, car il peut entraîner une perte de productivité critique du système.
Ainsi, les événements étendus sont un système général de gestion des événements pour les systèmes serveurs. Ce système prend en charge la corrélation des données de SQL Server, ce qui permet d'obtenir des événements d'état SQL Server.
L'architecture du système est illustrée ci-dessous :
En fait, nous avons un package qui contient des événements, des cibles, des actions, des types, des prédicats et des cartes. Les sessions contenant des événements, des cibles et des actions sont exécutées sur le serveur. Je ne décrirai pas l'architecture en détail puisque l'aide contient une description explicite.
Revenons maintenant à notre SSAS. Pour rendre tout plus vivant, considérons plusieurs scénarios que nous utilisons pour l'analyse des problèmes.
Premier scénario :analyse de traitement de cube (cube multidimensionnel)
C'est souvent le cas lorsqu'un cube est mis à jour très longtemps pendant le traitement, bien que le volume de données soit assez faible. Pour en connaître la raison, nous devons comprendre quelle requête ou quel lieu de traitement provoque le ralentissement. Bien sûr, nous pouvons exécuter le traitement sur Production et voir ce qui se passe, mais je ne suis pas sûr que vos utilisateurs l'apprécieront. Ici, les événements étendus viennent à l'aide. Lançons notre session et configurons son enregistrement dans un fichier.
Ouvrons SSMS et connectons-nous à SSAS, puis passons à Gestion.
Maintenant, créons une nouvelle session :
- Sur l'onglet Général, spécifiez un nom pour notre session et chargez un modèle.
- Les événements onglet montre les événements qui nous aideront à analyser les problèmes. L'onglet présente tous nos anciens amis de Profiler. Sélectionnons les événements suivants pour l'analyse du traitement :CommandBegin , FinCommande, Programme essReportBegin et ProgressReportEnd, ResourseUsage.
CommandBegin , FinCommande affichera le début et la fin de l'exécution de la commande pendant le traitement.
Programme essReportBegin et ProgressReportEn fournir des informations étendues sur la longueur de chaque événement et afficher les données lues, l'exécution de requêtes SQL, la longueur, etc.
Utilisation des ressources affiche le nombre de ressources dépensées pour l'exécution d'une requête, d'une action.
Lorsque nous avons sélectionné les événements, nous pouvons passer à la configuration de chaque événement et spécifier quels événements doivent être affichés et quels événements doivent être masqués (par exemple, nous pouvons masquer l'ID de processus).
- Stockage des données languette. Ici, nous pouvons spécifier soit d'afficher les événements en mode temps réel, soit de les écrire dans un fichier :
- event_file – enregistrer l'événement dans un fichier pour une analyse plus approfondie. Spécifiez la taille de fichier maximale et le chemin de destination. Si la taille du fichier dépasse la taille spécifiée, un nouveau fichier sera créé. Aussi, nous pouvons spécifier le nombre de fichiers qui doivent être créés (nombre maximum de fichiers).
- event_stream – permet de visualiser les événements en mode temps réel.
- ring_buffer – spécifie que les données de session doivent être stockées en mémoire tant que le serveur est exécuté. En cas de rechargement, les données seront supprimées.
- Le Avancé permet de configurer les ressources (mémoire, processeur) pour une session donnée.
Enfin, cliquez sur OK et obtenez la séance. Exécutons le traitement du cube et voyons le traitement par événements. Passez en mode de données en direct.
En haut de la capture d'écran suivante, nous pouvons voir les événements qui se déroulent en ce moment avec notre instance. Les détails des événements sont affichés en bas. Toute valeur des détails de l'événement peut être ajoutée dans une colonne distincte en haut. Cliquez avec le bouton droit sur une valeur sélectionnée des détails de l'événement et affichez-les dans un tableau.
Dans le résultat, nous obtenons la vue suivante :
Par conséquent, les événements étendus permettent d'analyser notre traitement en mode temps réel. Nous pouvons comprendre combien de temps est consacré au traitement de chaque objet, combien de ressources sont utilisées pour quoi. Cela aide à tirer des conclusions et à trouver les points faibles. De plus, nous ne surchargeons pas le système et n'obtenons pas de perte de productivité.
Vous pouvez également créer une session via XMLA. Vous pouvez récupérer le script sur GitHub.
L'arrêt et la suppression d'une session sont possibles via SSMS et XMLA.
- Via SSMS (cependant, en 2016, l'erreur s'est produite et je n'ai pas réussi à supprimer la session via l'interface).
- Script XMLA – peut être téléchargé ici.
Ceci est la première partie de l'article sur les événements étendus pour SSAS. Dans la deuxième partie, nous considérerons un scénario d'analyse de la productivité des requêtes dans le cube, en travaillant avec un fichier de trace et en analysant le fichier via Power BI.
Je vous recommande également de consulter les articles de blog suivants :
- Pinal Dave — SQL SERVER – Générateur de profils SQL vs événements étendus
- Chris Web :profileur, services d'analyse et d'événements étendus. Bien que l'auteur de l'article déclare que Profiler n'est presque pas utilisé sur les serveurs de production, mais confirme ses problèmes de charge du serveur.
- Brent Ozar – Événements étendus SQL Server
