> Data > Résolution de problèmes avec SQL Profiler

Résolution de problèmes avec SQL Profiler

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Itzik Ben-Gan
Retrouvez le coupable en reconstituant le crime… L'utilisation de l'outil de traçage SQL Profiler de SQL Server 7.0 est comparable à  l'aide qu'apporterait un enquêteur privé, permettant d'optimiser, de dépanner et de gérer un environnement SQL Server. L'article "Comment suivre un événement à  la trace avec SQL Server Profiler" présente l'architecture de suivi de SQL Server 7.0, et indique comment définir au moyen d'une interface graphique une fonction de suivi avec Profiler. Désormais, vous êtes prêt à  plonger dans des eaux plus profondes, et à  réexécuter les actions enregistrées par Profiler, et définir des actions de suivi automatique avec les procédures cataloguées étendues de suivi de SQL Server 7.0. Avec ces bases solides, on peut mettre à  profit Profiler et les procédures cataloguées étendues pour examiner différents cas de figure, allant des requêtes dont l'exécution est anormalement longue aux situations de blocage.

Si on souhaite réexécuter des traces, il faut d'abord mener quelques tâches préliminaires à  bien

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.

Téléchargez cette ressource

Microsoft 365 : HP Subscription Management Services en détail

Microsoft 365 : HP Subscription Management Services en détail

Collaboration à distance, environnements de travail et productivité optimisés, gestion évolutive des licences, accélérez la transformation de votre business pour le faire entrer dans l’ère de la collaboration hybride. Découvrez comment le service de gestion des abonnements HP peut vous aider à optimiser vos investissements et votre stratégie de gestion de vos abonnements Microsoft 365.

Data - Par iTPro.fr - Publié le 24 juin 2010