Options générales

serveur différent, simplement en utilisant un ensemble
de procédures cataloguées étendues de SQL Server 7.0 dévolues aux traces. Je détaille
cette question dans l’article « Résolution de problème avec SQL Server ». Les destinations
suivantes sont néanmoins disponibles dans Profiler :
Ecran. Si on utilise Profiler pour tracer les événements (et non pour utiliser
des procédures cataloguées étendues de SQL Server 7.0), le résultat du suivi sera
toujours dirigé vers l’écran, que l’on sélectionne une autre destination ou non.
On peut néanmoins enregistrer la sortie plus tard dans un fichier script SQL,
un fichier de suivi ou une table en choisissant l’option Save As du menu File.
Notez que l’arrêt et le redémarrage de la trace efface la sortie précédente. Aussi,
il faut enregistrer ses résultats avant de redémarrer le suivi. En outre, si on
modifie les propriétés de la trace sans rouvrir une trace sauvegardée, les nouvelles
propriétés ne prendront pas effet tant que la trace n’a pas été arrêtée et redémarré.
(Pour en savoir plus, sur l’arrêt et le redémarrage des suivis, veuillez consulter
l’article « Résolution de problème avec SQL Profiler ».)

Fichier. Si on envoie la sortie vers un fichier de suivi, on peut l’analyser ultérieurement.
En outre, les fichiers permettent de consulter la trace sous différentes vues.
On peut par exemple souhaiter organiser la sortie en différents groupes ou colonnes
de données, ou encore, supprimer certains événements et colonnes de données de
la trace. L’envoi de la sortie vers un fichier de trace présente deux avantages
par rapport à  une sortie dans une table : consommation mémoire plus faible et
temps d’exécution plus rapide. En effet, les I/O effectuées directement sur le
système de fichiers ne génèrent pas de surcharge mémoire et CPU, ce qui est le
cas des insertions dans les tables. Par exemple, avec un fichier, il n’est pas
nécessaire d’utiliser des ressources pour traiter les problèmes de concurrence
ou de cohérence.
Table. L’utilisation d’une table pour analyser la sortie du suivi peut nécessiter
beaucoup de mémoire et de temps CPU. Toutefois, cela apporte plus de souplesse
qu’un fichier. Par exemple, on peut utiliser la fonction PivotTable de Microsoft
Excel qui, utilisant la table de suivi comme source de données, permet de faire
glisser, dynamiquement, les informations vers les différentes zones PivotTable
(page, enregistrements, colonnes, données) afin de former la vue souhaitée du
suivi. Les tables offrent également des critères de filtrage plus souples que
Profiler. Par exemple, avec Profiler, on ne peut pas analyser tous les événements
dont le SPID est de, disons, 8 ou 9. Mais On peut créer ce filtre en exécutant
la requête simple suivante :

SELECT * FROM mytracetable WHERE SPID in (8, 9)

On peut également créer des déclencheurs sur une table afin d’exécuter certaines
actions suite à  l’avènement de certains événements système, une fonction qu’on
ne peut pas exécuter autrement parce qu’on ne peut pas créer de déclencheurs sur
des tables système.
On peut laisser Profiler créer la table de sortie selon les colonnes de données
sélectionnées ou on peut créer une table répondant à  des objectifs propres. J’ai
par exemple créé une table activant les déclencheurs pour la vérification de la
colonne TextData. Dans les tables générées par Profiler, cette colonne est le
type de données ntext, inaccessible pour les déclencheurs. Pour ma table, j’ai
simplement modifié la structure de la table pour utiliser le type de données nvarchar
(au lieu de ntext) dans la colonne TextData. Même si on décide de créer une table,
on peut laisser Profiler la créer d’abord, puis générer un script pour sa création
dans Enterprise Manager (cliquer avec le bouton droit de la souris sur le nom
de la table, choisir All Tasks, puis Generate SQL Script) et modifier légèrement
l’instruction CREATE TABLE pour répondre à  ses besoins. Un moyen plus facile pour
générer l’instruction CREATE TABLE est de cliquer avec le bouton droit sur le
nom de la table dans Enterprise Manager, de choisir Copy, basculer sur Query Analyzer
et de sélectionner Paste dans le menu Edit (ou le faire simplement glisser d’Enterprise
Manager vers l’analyseur de requête).

Vous découvrirez que les tables générées par Profiler répertorient un événement
en tant que code décimal représentatif et sous le nom de l’événement. On peut
cependant exécuter la procédure cataloguée étendue de SQL Server 7.0, xp_trace_geteventnames,
sans les paramètres afin de répertorier toutes les classes d’événements et leurs
noms. Premièrement, créez une table simple et envoyez la sortie de xp_trace_geteventnames
vers cette table, comme le montre le listing 1. Ensuite, effectuez une jointure
sur votre table de sortie de suivi pour obtenir les noms des événements, comme
le montre le listing 2.
De plus, dans l’onglet General, on peut également déterminer si la définition
de suivi est privée ou partagée entre les utilisateurs se connectant à  l’ordinateur
(on peut également définir une valeur par défaut égale à  privé ou partagé dans
la boîte de dialogue Trace Options de Profiler avant de définir le suivi). De
cette façon, vous n’avez pas à  modifier cette option dans l’onglet General, à 
moins que vous ne souhaitiez modifier l’option par défaut).