103
5.2 SQL Trace et le profiler
Figure 5.5 — Les filtres de colonnes
Vous pouvez accumuler les filtres sur une même colonne, avec différents opérateurs. Les colonnes filtrées montrent une icône d’entonnoir. Avant SQL Server
2005, les événements qui ne retournaient rien dans la colonne filtrée étaient affichés
quand même, ce qui était assez peu pratique. Depuis SQL Server 2005, l’option
« Exclude rows that do no contain values » permet de filtrer ces événements. Pensez-y, elle n’est pas sélectionnée par défaut.
Quelques idées de filtre : filtre sur un SPID particulier pour tracer une seule session, filtre sur une ApplicationName pour analyser ce que fait une application cliente,
filtre sur TextData pour trouver les instructions SQL qui s’appliquent à un objet.
Dans ce cas, la syntaxe du LIKE est la même qu’en SQL : le caractère % (pourcent)
remplace une chaîne de caractères. Pour une trace destinée à détecter les requêtes les
plus coûteuses, un filtre sur le nombre de reads (opérateur égal ou plus grand que) est
la meilleure méthode : les reads ne varient pas d’un appel à un autre à données égales, et plus le nombre de reads est important, plus l’instruction est lourde, non seulement pour sa propre exécution, mais aussi, à travers les ressources qu’elle consomme
et les verrous qu’elle pose peut-être, pour toutes les autres s’exécutant simultanément.
Vous pouvez aussi grouper à l’affichage, par colonne(s). Cela vous permet d’obtenir une vue non plus chronologique, mais dans un ordre qui vous siet mieux. Dans ce
cas, la lecture peut être moins intuitive. Cliquez sur le bouton « Organize
columns… » (ou clic droit sur les en-têtes de colonne, et commande « organize
columns… »). Dans la fenêtre qui s’ouvre, les boutons Up et Down permettre
d’organiser l’ordre des colonnes. Un Up jusqu’au nœud « Groups » crée un regroupement. Sur la figure 5.6, vous voyez un regroupement par ApplicationName, puis SPID.
5.2 SQL Trace et le profiler
Figure 5.5 — Les filtres de colonnes
Vous pouvez accumuler les filtres sur une même colonne, avec différents opérateurs. Les colonnes filtrées montrent une icône d’entonnoir. Avant SQL Server
2005, les événements qui ne retournaient rien dans la colonne filtrée étaient affichés
quand même, ce qui était assez peu pratique. Depuis SQL Server 2005, l’option
« Exclude rows that do no contain values » permet de filtrer ces événements. Pensez-y, elle n’est pas sélectionnée par défaut.
Quelques idées de filtre : filtre sur un SPID particulier pour tracer une seule session, filtre sur une ApplicationName pour analyser ce que fait une application cliente,
filtre sur TextData pour trouver les instructions SQL qui s’appliquent à un objet.
Dans ce cas, la syntaxe du LIKE est la même qu’en SQL : le caractère % (pourcent)
remplace une chaîne de caractères. Pour une trace destinée à détecter les requêtes les
plus coûteuses, un filtre sur le nombre de reads (opérateur égal ou plus grand que) est
la meilleure méthode : les reads ne varient pas d’un appel à un autre à données égales, et plus le nombre de reads est important, plus l’instruction est lourde, non seulement pour sa propre exécution, mais aussi, à travers les ressources qu’elle consomme
et les verrous qu’elle pose peut-être, pour toutes les autres s’exécutant simultanément.
Vous pouvez aussi grouper à l’affichage, par colonne(s). Cela vous permet d’obtenir une vue non plus chronologique, mais dans un ordre qui vous siet mieux. Dans ce
cas, la lecture peut être moins intuitive. Cliquez sur le bouton « Organize
columns… » (ou clic droit sur les en-têtes de colonne, et commande « organize
columns… »). Dans la fenêtre qui s’ouvre, les boutons Up et Down permettre
d’organiser l’ordre des colonnes. Un Up jusqu’au nœud « Groups » crée un regroupement. Sur la figure 5.6, vous voyez un regroupement par ApplicationName, puis SPID.