Sql Server Profiler

Introduction

Sql Profiler est un outil bien utile pour faire du monitoring d'utilisation de Sql Server.
Tout récemment, nous l'avons utilisé pour tenir l'oeil des opérations que nous savions particulièrement gourmandes.

Exemple
Dans le cas qui nous concerne, nous avions de terribles problèmes de performances où l'écriture de nouveaux records dans la table d'AuditTrail échouaient (write time-out) de temps en temps. Avec pour conséquence (1) la perte du record d'audit et (2) l'apparente lenteur de l'application.
Malheureusement, nous avons des processus lisant occasionnelement cette table d'audit, assez énorme au demeurant (plusieurs millions de records et 6Go).
Sachant que la table d'audit ne dispose pas d'un design vraiment terrible (en passe d'être corrigé). Nous avions le sentiment que ces problèmes d'écritures étaient la conséquence même des différentes opérations de lectures exécutés sur AuditTrail.
Il fallait donc vérifier que les erreurs d'écriture reportées dans notre log applicatif étaient bien subséquentes (et donc probablement caussées par) aux requêtes Sql retournant des données extraitent de l'AuditTrail.

C'est là que SqlProfiler se révèle bien utile car c'est lui qui nous permettra de détecter et logger les requêtes de lecture de l'AuditTrail.
A nous, par la suite, de comparer le contenu des deux logs.


Mise en place
1) Démarrer SQL Profiler

2) Créer une nouvelle trace

3) Choisir le bon modèle et limiter la casse

Personnelement, je préfère partir d'un template/modèle vierge qu'il faut alors configuré.
Mes premiers essaient à partir des modèles prédéfinit ne se sont pas montrés des plus efficaces... Il faut avouer que le modèle par défaut ne capture pas les statement SQL envoyés par notre application.


Il est préférable de fixer une limite pour ne pas consommer toutes les ressources de la machine.
Dans le cadre de l'utilisation d'un tel outil sur un serveur de production (le genre de machine qui n'est  pas surveillées de façon intensive/manuelle), on peut facilement créer une situation engorgeant totalement l'espace disque. 
C'est qu'activer un trace est tellement plus facile que de ne pas oublier, après plusieurs jours, qu'elle fonctionne  :-)

4) Sélection des traces

La sélection des traces appropriés n'est pas forcement des plus évidents.
Par exemple, les traces de type TSql Batch sont sélectionnés par défaut dans le modèle par défaut.
Ce type de trace se révèle totalement intutile lorsque l'on cherche a monitorer une application de type Ado/OleDB. Dans ce cas, les traces a monitorer sont SQL:StmtCompleted et SQL:StmtStarting

Par contre, pour ne pas risquer de crouler sous les quantités d'information collectés, il faudra configurer le filtrage.

4.1) Filtrer sur la DB

A mon sens, ce point ne nécessite pas commentaire.

4.2) Filtrer les requêtes SQL


Point un peu plus délicat!
Il faut avant tout savoir que le statement SQL est stocker dans la colonne TextData.
Dans notre cas, nous voulions collecter les requêtes SELECT sur la table d'audit (sachant qu'il n'y a pas d'updates).

5) Démarrer la trace
Une fois la trace démarrée, il ne reste plus qu'a observer l'accumulation des résultats.