Au cours de la surveillance des performances ou du dépannage d'un problème tel que la lenteur du système, il peut être nécessaire de rechercher ou de capturer des requêtes qui ont une durée élevée, un processeur élevé ou qui génèrent des E/S importantes pendant l'exécution. Vous pouvez utiliser les DMV ou le magasin de requêtes pour obtenir des informations sur les performances des requêtes, mais les informations des deux sources sont un agrégat. Les DMV représentent le CPU moyen, les E/S, la durée, etc. pour une requête uniquement tant qu'elle est en cache. Query Store fournit également des métriques moyennes pour de nombreuses ressources, mais elles sont agrégées sur une fenêtre de temps définie (par exemple, 30 minutes ou une heure). Il existe bien sûr des solutions de surveillance tierces qui sont plus que capables de vous offrir tout cela et plus encore (comme SentryOne), mais pour cet article, je voulais me concentrer sur les outils natifs.
Si vous souhaitez comprendre les performances des requêtes pour des exécutions individuelles afin d'identifier la requête exacte ou l'ensemble de requêtes qui pourrait poser problème, l'option la plus simple consiste à utiliser les événements étendus. Et l'un des moyens les plus rapides pour démarrer est d'utiliser XEvent Profiler, qui est disponible via SQL Server Management Studio (à partir de la version 17.3) :
Profileur XEvent dans SSMS
Utilisation de base
Il existe deux options pour XEvent Profiler :Standard et TSQL. Pour utiliser l'un ou l'autre, double-cliquez simplement sur le nom. Dans les coulisses, une session d'événements définie en interne est créée (si elle n'existe pas déjà) et démarrée, et la visionneuse de données en direct s'ouvre immédiatement avec le focus. Notez qu'après avoir démarré la session, elle apparaîtra également sous Gestion | Événements étendus | Séances. En supposant que vous ayez une activité contre le serveur, vous devriez commencer à voir les entrées apparaître dans la visionneuse en cinq secondes ou moins.
Live Data Viewer (après avoir double-cliqué pour démarrer la session standard)
Les sessions Standard et TSQL partagent certains événements, le Standard en ayant plus au total. Voici une liste des événements pour chacun :
Standard TSQL
sql_batch_starting sql_batch_starting
sql_batch_completed
rpc_starting
rpc_completed
logout logout
login login
existing_connection existing_connection
attention Si vous cherchez à comprendre les informations sur l'exécution de la requête, telles que la durée d'exécution de la requête ou la quantité d'E/S qu'elle a consommées, alors Standard est une meilleure option en raison des deux événements terminés. Pour les deux sessions, le seul filtre consiste à exclure les requêtes système pour les événements batch, rpc et attention.
Affichage et enregistrement des données
Si nous démarrons la session standard et exécutons certaines requêtes, dans la visionneuse, nous voyons l'événement, le texte de la requête et d'autres informations utiles telles que cpu_time, logical_reads et la durée. L'un des avantages de l'utilisation de rpc_completed et sql_batch_completed est que le paramètre d'entrée s'affiche. Dans le cas où une procédure stockée présente de grandes variations de performances, la capture du paramètre d'entrée peut être extrêmement utile car nous pouvons faire correspondre une exécution qui prend plus de temps avec une valeur spécifique transmise à la procédure stockée. Afin de trouver un tel paramètre, nous devons trier les données en fonction de la durée, ce que nous ne pouvons pas faire lorsque le flux de données est actif. Pour effectuer tout type d'analyse, le flux de données doit être arrêté.
Arrêter le flux de données dans la visionneuse en direct
Maintenant que mes requêtes ne défilent plus dans le flou, je peux cliquer sur la colonne de durée pour trier mes événements. La première fois que je clique dessus, je trie par ordre croissant, et parce que je suis paresseux et que je ne veux pas faire défiler le bas, je clique à nouveau pour trier par ordre décroissant.
Événements triés par durée décroissante
Maintenant, je peux voir tous les événements que j'ai capturés dans l'ordre de la durée la plus élevée à la plus faible. Si je cherchais une procédure stockée spécifique qui était lente, je pouvais soit faire défiler jusqu'à ce que je la trouve (ce qui pourrait être pénible), soit regrouper ou filtrer les données. Le regroupement est plus facile ici, car je connais le nom de la procédure stockée.
L'object_name est affiché dans la partie supérieure de la visionneuse, mais cliquer sur n'importe quel événement rpc_completed affiche tous les éléments capturés dans le volet Détails. Cliquez avec le bouton droit sur object_name, ce qui le mettra en surbrillance, puis sélectionnez Afficher la colonne dans le tableau.
Ajouter object_name au visualiseur de données
Dans le volet supérieur, je peux maintenant cliquer avec le bouton droit sur object_name et sélectionner Grouper par cette colonne. Si je développe les événements sous usp_GetPersonInfo, puis que je les trie à nouveau par durée, je vois maintenant que l'exécution avec PersonID=3133 avait la durée la plus élevée.
Événements regroupés par object_name, usp_GetPersonInfo triés par durée décroissante
Pour filtrer les données :utilisez soit le bouton Filtres…, l'option de menu (Événements étendus | Filtres…), soit CTRL + R pour faire apparaître une fenêtre afin de réduire le jeu de résultats en fonction des différents champs affichés. Dans ce cas, nous avons filtré sur object_name =usp_GetPersonInfo, mais vous pouvez également filtrer sur des champs tels que server_principal_name ou client_app_name, car ceux-ci ont été collectés.
Il convient de souligner que ni la session Standard ni la session TSQL n'écrivent dans un fichier. En fait, il n'y a pas de cible pour l'une ou l'autre des sessions d'événements (si vous ne saviez pas que vous pouvez créer une session d'événements sans cible, vous le savez maintenant). Si vous souhaitez enregistrer ces données pour une analyse plus approfondie, vous devez effectuer l'une des actions suivantes :
- Arrêtez le flux de données et enregistrez la sortie dans un fichier via le menu Événements étendus (Exporter vers | Fichier XEL…)
- Arrêtez le flux de données et enregistrez la sortie dans une table d'une base de données via le menu Événements étendus (Exporter vers | Table…)
- Modifiez la session d'événement et ajoutez le event_file en tant que cible.
L'option 1 est ma recommandation, car elle crée un fichier sur disque que vous pouvez partager avec d'autres et revoir plus tard dans Management Studio pour une analyse plus approfondie. Dans Management Studio, vous avez la possibilité de filtrer les données non pertinentes, de les trier sur une ou plusieurs colonnes, de regrouper les données et d'effectuer des calculs (par exemple, des moyennes). Vous pouvez le faire si les données sont une table, mais vous devez écrire le TSQL; l'analyse des données dans l'interface utilisateur est plus facile et plus rapide.
Modification des sessions XEvent Profiler
Vous pouvez modifier les sessions d'événements Standard et TSQL et les modifications que vous apportez seront conservées lors des redémarrages de l'instance. Cependant, si les sessions d'événements sont abandonnées (après que vous ayez apporté des modifications), elles seront réinitialisées aux valeurs par défaut. Si vous vous retrouvez à faire continuellement les mêmes modifications, je vous suggère de scripter les modifications et de créer une nouvelle session d'événement qui persistera également lors des redémarrages. Par exemple, si nous examinons la sortie capturée jusqu'à présent, nous pouvons voir que les requêtes ad hoc et les procédures stockées ont été exécutées. Et même si c'est formidable que je puisse voir les différents paramètres d'entrée pour les procédures stockées, je ne vois pas les instructions individuelles qui s'exécutent avec cet ensemble d'événements. Pour obtenir cette information, je devrais ajouter l'événement sp_statement_completed.
Comprenez que les sessions d'événements Standard et TSQL sont conçues pour être légères. Les événements statement_completed se déclenchent plus fréquemment que les événements batch et rpc, il peut donc y avoir plus de surcharge lorsque ces événements font partie d'une session d'événements. Lorsque j'utilise des événements d'instruction, je fortement recommandent d'inclure des prédicats supplémentaires. Pour rappel, les événements rpc et batch filtrent uniquement les requêtes système - il n'y a pas d'autre prédicat. En général, je recommande également des prédicats supplémentaires pour ces événements, en particulier pour une charge de travail à volume élevé.
Si vous vous demandez si l'exécution des sessions Standard ou TSQL entraînera une baisse des performances de votre système, sachez que la visionneuse de données en direct se déconnectera si elle crée trop de surcharge sur le système. C'est une grande sécurité, mais je serais toujours prudent lors de l'utilisation de ces sessions d'événement. Je pense qu'ils constituent une première étape fantastique pour le dépannage, en particulier pour ceux qui découvrent SQL Server ou les événements étendus. Cependant, si la visionneuse de données en direct est ouverte et que vous vous éloignez de votre ordinateur, la session d'événement continue de s'exécuter . L'arrêt ou la fermeture de la visionneuse de données en direct arrêtera la session d'événement, ce que je recommande lorsque vous avez terminé votre collecte de données ou votre dépannage.
Pour les sessions d'événements que vous souhaitez exécuter pendant une période plus longue, créez des sessions d'événements distinctes qui écrivent dans la cible event_file et disposent des prédicats appropriés. Si vous avez besoin de plus d'informations sur la mise en route des événements étendus, consultez la session que j'ai donnée à SQLBits l'année dernière sur la migration de Profiler vers les événements étendus.
