105
5.2 SQL Trace et le profiler
Ces colonnes indiquant des mesures chiffrées de l’exécution d’ordres SQL, elles
ne sont bien entendu retournées que par les événements déclenchés à la fin d’un
ordre. Dans les couples d’événements tels que SQL:BatchStarting et SQL:BatchCompleted ou SP:Starting et SP:Completed, c’est l’événement Completed qui vous intéressera. L’événement Starting ne sera utile que si vous désirez observer ce qui se passe
entre le début et la fin de l’ordre (par exemple à l’aide de l’événement SP:StmtCompleted qui détaille l’exécution des parties d’une procédure stockée), ou si, à cause
d’une exception, votre ordre ne se termine pas correctement.
Attention – Les colonnes CPU et Duration enregistrent en interne des durées en
microsecondes (un millionième de seconde, 10 puissance -6). Elles sont affichées
dans le profiler en millisecondes, comme pour les versions précédentes de SQL
Server, mais lorsque vous travaillez hors du profiler, par exemple dans une trace
sauvegardée dans une table, ces valeurs seront en microsecondes. Vous devez
donc diviser par 1000 pour obtenir des millisecondes.
D’autres colonnes sont indicatives, et utiles également pour filtrer vos
événements :
• ApplicationName : nom de l’application cliente, passée dans la chaîne de
connexion. Par exemple SSMS se fait connaître sous le nom Microsoft SQL
Server Management Studio. Si vous développez des applications clients
« maison », il est utile de le spécifier, soit dans la chaîne de connexion (en y
ajoutant « Application Name= »), soit à l’aide de la propriété idoine de votre
bibliothèque client (par exemple la propriété ApplicationName de l’objet
SqlConnectionStringBuilder en ADO.NET), cela vous permettra de savoir
d’où viennent vos requêtes, et d’afficher les événements provenant d’une
application seulement. Les développeurs peuvent aussi générer cet ApplicationName en y incluant le numéro de version de leur produit. Cela rend aisé la
vérification des mises à jour sur tous les clients, et cela permet, par exemple,
de créer un déclencheur DDL qui vérifie cette valeur à l’aide de la fonction
système APP_NAME() et interdit l’ouverture de session si la version du client
n’est pas suffisante.
• DatabaseID : l’identifiant de base de données courante, utile pour n’afficher
que les requêtes effectuées dans une base de données. Vous pouvez trouver cet
ID dans la colonne database_id de la vue système sys.databases, ou à l’aide
de la fonction DB_ID(). Notez qu’il s’agit du contexte de base dans lequel
l’ordre est exécuté, et non la localisation des objets touchés. Si vous requêtez
la table AdventureWorks.Person.Contact depuis la base master, en utilisant
comme ici le nom complet base.schéma.objet, votre DatabaseID sera 1 (valeur
toujours attribuée à la base master).
• DatabaseName : nom de la base de données en toutes lettres. Plus intuitif que
DatabaseID.
5.2 SQL Trace et le profiler
Ces colonnes indiquant des mesures chiffrées de l’exécution d’ordres SQL, elles
ne sont bien entendu retournées que par les événements déclenchés à la fin d’un
ordre. Dans les couples d’événements tels que SQL:BatchStarting et SQL:BatchCompleted ou SP:Starting et SP:Completed, c’est l’événement Completed qui vous intéressera. L’événement Starting ne sera utile que si vous désirez observer ce qui se passe
entre le début et la fin de l’ordre (par exemple à l’aide de l’événement SP:StmtCompleted qui détaille l’exécution des parties d’une procédure stockée), ou si, à cause
d’une exception, votre ordre ne se termine pas correctement.
Attention – Les colonnes CPU et Duration enregistrent en interne des durées en
microsecondes (un millionième de seconde, 10 puissance -6). Elles sont affichées
dans le profiler en millisecondes, comme pour les versions précédentes de SQL
Server, mais lorsque vous travaillez hors du profiler, par exemple dans une trace
sauvegardée dans une table, ces valeurs seront en microsecondes. Vous devez
donc diviser par 1000 pour obtenir des millisecondes.
D’autres colonnes sont indicatives, et utiles également pour filtrer vos
événements :
• ApplicationName : nom de l’application cliente, passée dans la chaîne de
connexion. Par exemple SSMS se fait connaître sous le nom Microsoft SQL
Server Management Studio. Si vous développez des applications clients
« maison », il est utile de le spécifier, soit dans la chaîne de connexion (en y
ajoutant « Application Name= »), soit à l’aide de la propriété idoine de votre
bibliothèque client (par exemple la propriété ApplicationName de l’objet
SqlConnectionStringBuilder en ADO.NET), cela vous permettra de savoir
d’où viennent vos requêtes, et d’afficher les événements provenant d’une
application seulement. Les développeurs peuvent aussi générer cet ApplicationName en y incluant le numéro de version de leur produit. Cela rend aisé la
vérification des mises à jour sur tous les clients, et cela permet, par exemple,
de créer un déclencheur DDL qui vérifie cette valeur à l’aide de la fonction
système APP_NAME() et interdit l’ouverture de session si la version du client
n’est pas suffisante.
• DatabaseID : l’identifiant de base de données courante, utile pour n’afficher
que les requêtes effectuées dans une base de données. Vous pouvez trouver cet
ID dans la colonne database_id de la vue système sys.databases, ou à l’aide
de la fonction DB_ID(). Notez qu’il s’agit du contexte de base dans lequel
l’ordre est exécuté, et non la localisation des objets touchés. Si vous requêtez
la table AdventureWorks.Person.Contact depuis la base master, en utilisant
comme ici le nom complet base.schéma.objet, votre DatabaseID sera 1 (valeur
toujours attribuée à la base master).
• DatabaseName : nom de la base de données en toutes lettres. Plus intuitif que
DatabaseID.