Résolution de problèmes avec SQL Profiler

On peut réexécuter les traces enregistrées par Profiler pour déboguer des applications
présentant des problèmes, fournir des scripts simulant un environnement de production
pour des tests, optimiser les bases de données, et bien plus. Toutefois, si on
souhaite réexécuter des traces, il faut d’abord mener quelques tâches préliminaires
à  bien. Premièrement, il faut configurer un suivi de manière à  capturer certains
événements et colonnes de données en plus de ceux qui nous intéressent. Ces événements
et colonnes de données supplémentaires garantissent une réexécution fidèle des
scénarii. Ensuite, il faut enregistrer la sortie de la trace dans un fichier,
une table ou un script SQL.

Toutes les réexécutions nécessitent de capturer les événements Connect, Disconnect,
ExistingConnection, RPC:Starting et SQL:BatchStarting. En outre, pour les réexécutions
de curseurs API côté serveur (curseurs côté serveur gérés par les fonctions de
curseur API), il faut capturer les événements CursorExecute, CursorOpen et CursorPrepare.
Pour réexécuter les instructions SQL préparées côté serveur, ajoutez les événements
Exec Prepared SQL et Prepare SQL. Les colonnes de données requises pour la réexécution
sont : nom de l’application, données binaires, ID connexion ou ID de process serveur
(SPID), ID base de données, classe d’événement, sous-classe d’événement, nom de
l’hôte, données entières, nom du serveur, nom d’utilisateur SQL, heure de début
et texte.
Notez qu’une réexécution ne simule pas des événements capturés : elle les réexécute.
Aussi, lorsqu’on réexécutera une trace, on modifiera probablement la base de données.
Par exemple, si on réexécute une trace intégrant une instruction INSERT, on risque
de se retrouver avec une table contenant une clé en double. Pour éviter ce problème,
remettez votre base de données à  l’état initial si vous réexécutez la trace par
rapport au serveur source (le serveur sur lequel vous avez effectué le suivi original
des événements).

Si on souhaite réexécuter la trace sur un serveur différent, il faut s’assurer
que la base de données du serveur cible présente le même état que la base de données
du serveur source. Il faut également utiliser les mêmes connexions, utilisateurs,
permissions et ID base de données que ceux utilisés sur le serveur source.
L’utilisation de la même ID base de données s’avère délicate, en particulier parce
que Microsoft déconseille de modifier l’ID base de données en accédant directement
la table système sysdatabases. Pour retrouver des ID base de données identiques,
on peut copier les fichiers base de données utilisateur du serveur source vers
un chemin similaire du serveur cible, puis restaurer une copie de la base de données
d’origine du serveur source sur le serveur cible. De la même façon, on peut restaurer
une sauvegarde de la base de données utilisateur du serveur source sur le serveur
cible, puis restaurer la sauvegarde de la base de données d’origine. Chacune de
ces méthodes garantit que les fichiers base de données du serveur cible existent
à  leurs emplacements d’origine et que les tables systèmes de la base de données
maîtresse contiennent l’ID base de données d’origine. Pour éviter complètement
le problème, il suffit de supprimer la colonne de données ID base de données dans
la trace, et de définir la base de données cible comme base de données par défaut
de chaque utilisateur détecté par la trace.

On peut également contrôler le niveau de synchronisation et la vitesse de réexécution
d’un script.
Pour cela, il suffit de choisir Settings dans le menu Replay : la boîte de dialogue
Replay SQL Server s’affiche.
Le niveau de synchronisation, qui gère la synchronisation entre les différentes
connexions, accepte les valeurs suivantes :
· Full synchronization (par défaut) : permet de réexécuter les événements dans
leur ordre d’origine à  travers toutes les connexions.
· Partial synchronization: permet aux événements d’une connexion de démarrer avant
d’autres événements ayant une heure de début antérieure dans d’autres connexions,
mais qui ont été retardés.
· No synchronization : permet à  un événement de démarrer dès la fin de l’événement
précédent, dans la même connexion, sans tenir compte de la synchronisation des
connexions.

La vitesse de réexécution admet les valeurs suivantes :

· As fast as possible (par défaut) : démarre l’événement suivant dès la fin de
l’événement précédent.
· Maintain interval between events : maintient l’intervalle de temps d’origine
entre les événements.
· Maintain relationships to start time : démarre les événements à  la même heure
(par rapport à  l’heure de début de la trace) que dans la trace d’origine.