SQL Profiler est un outil de grande qualité permettant de comprendre différents problèmes de base de données, tels que «les requêtes les plus coûteuses sont en cours d’exécution», «Qui nécessite des verrous exclusifs acquis», «Quels index sont manquants», etc.

Mais dans les environnements de développement et de production lors de la résolution d’un problème, les développeurs préfèrent utiliser SQL Profiler pour obtenir l’appel de procédure exact généré par l’application front-end.

La pire pratique est que les développeurs aiment utiliser les modèles prédéfinis existants à cette fin et utilisent normalement un modèle par défaut, c’est-à-dire STANDARD. Si vous utilisez également SQL Profiler pour cet appel de procédure, la sélection du modèle de trace STANDARD n’est pas un bon choix. En effet, sur un serveur de production, ses performances sont affectées et même sur le serveur de développement, elle renvoie des informations supplémentaires.

La bonne pratique est que, si vous n’avez pas créé votre propre modèle, sélectionnez toujours TUNING.

Il contient également des informations supplémentaires. Ainsi, lorsque vous ne devez intercepter que les appels de procédure générés à partir de votre application, cliquez sur l’onglet « Sélection d’événement » et ne conservez que l’événement « RPC: terminé ».

Vous n’avez pas besoin de sélectionner «Sp: stmt Completed», il vous suffit de capturer les «appels de procédure d’exécution» et non l’ensemble de l’instruction contenue dans cette procédure.

Vous pouvez également omettre «SP: Batch Completed» car nous avons besoin d’appels générés uniquement à partir d’une application. Si vous devez également capturer des appels à partir de SSMS, vous pouvez le conserver.

Pour éviter toute pression de travail supplémentaire sur le serveur et obtenir uniquement les résultats requis, vous devez également appliquer des filtres sur «Nom de la base de données» et «Texte», vous pouvez ajouter % comme vous l’utilisez avec l’opérateur LIKE