Quelques détails

définir une trace avec les événements pertinents de réalisation, selon si on
souhaite exécuter les requêtes dans les procédures cataloguées ou en batch. Il
faut généralement suivre les événements SQL:StmtCompleted et SP:StmtCompleted.
Classez les requêtes en fonction des colonnes durée ou CPU, selon si les requêtes
sont plus lentes qu’on ne le souhaite, ou si elles utilisent plus de ressources
CPU qu’elles ne le devraient. Pour s’assurer que l’on ne gaspille pas de ressources
de suivi avec des requêtes rapides, on peut filtrer la trace sur un nombre minimum
de millisecondes pour la durée ou un nombre minimum de millisecondes pour l’utilisation
de la CPU.
On peut également utiliser Profiler pour découvrir les dessous de SQL Server Enterprise
Manager. Supposons que l’on souhaite visualiser les actions d’Enterprise Manager
lorsque l’on ajoute le fichier ‘file5’ à  un groupe de fichiers appelé ‘fg5’ de
la base de données testdb. Ouvrons tout d’abord la boîte de dialogue Propriétés
de la base de données de testdb, et ajoutons le fichier. Avant de cliquer sur
OK, définissons une trace dans Profiler à  l’aide des événements et des colonnes
de données par défaut, et d’un filtre de valeur de 1 (maître) sur l’ID base de
données. Démarrons alors la trace, cliquons sur OK dans Enterprise Manager, puis
arrêtons la trace. Profiler capture les instructions du type :

use [master]

ALTER DATABASE [testdb] ADD FILEGROUP [fg5]

ALTER DATABASE [testdb] ADD FILE(NAME = N’file5′,
FILENAME = N’d:\MSSQL7\DATA\file5_Data.NDF’ , SIZE
= 1, FILEGROWTH = 10%) TO FILEGROUP [fg5]

En outre, Profiler peut aider à  résoudre des problèmes, notamment comment obtenir
une notification automatique lorsqu’un paramètre auto-grow. Ce problème peut s’avérer
délicat car on ne peut pas placer de déclencheur dans une table système. Une manière
d’obtenir ces informations consiste à  utiliser Profiler pour définir un suivi
avec les événements, colonnes de données et filtres suivants :

· Evénements : TSQL: SQL:StmtCompleted et SP:StmtCompleted
· Colonnes de données : EventClass, TextData, NTUserName, Appli-cationName,
SQLUserName et StartTime
· Filtres : Filtre de valeur sur l’ID base de données de la base
de données que l’on souhaite filtrer, et filtre d’inclusion sur le texte (%alter%database%modify%file%)

On peut ensuite créer une table en sortie structurée comme l’instruction du listing
4. Vous noterez que, dans ce cas, il faut concevoir une table et non laisser Profiler
la créer car il faut récupérer la colonne TextData dans un déclencheur. Le problème
est que, dans la table créée par Profiler, TextData représente des données de
type ntext, inaccessibles depuis un déclencheur. Pour accéder à  la colonne de
la table depuis un déclencheur, il suffit de définir le type de données en nvarchar.
Ensuite, on définit un déclencheur pour nous avertir lorsqu’un paramètre auto-grow
est modifié, comme cela est indiqué dans le listing 5. Pour tester l’appel du
déclencheur, modifiez les propriétés d’un fichier :

ALTER DATABASE testdb MODIFY FILE (NAME =
‘testdb_dat’, MAXSIZE = 30MB)

On recevra le message e-mail suivant :

File properties changed:
Statement: ALTER DATABASE testdb MODIFY FILE (NAME =
‘testdb_dat’, MAXSIZE = 30MB)
NT User Name: Gandalf
Application Name: MS SQL Query Analyzer
SQL User Name: NA
Time: 1999-12-22 14:15:28

Retrouver les événements ayant provoqué un blocage peut être difficile, mais Profiler
propose des événements spécifiques qui peuvent aider. On peut par exemple suivre
l’événement Lock:Deadlock indiquant l’occurrence d’un blocage et spécifiant le
SPID et l’ID de transaction bloqués, l’heure à  laquelle le blocage a eu lieu,
ainsi que les noms de l’application et de l’utilisateur. L’événement pratique
Lock: Deadlock Chain, généré par tout événement provoquant un blocage, fournit
les SPID et les ID de transaction impliqués.
On peut enregistrer les ID de transaction impliqués dans le blocage, puis trier
les résultats par ID de transaction et étendre uniquement les transactions impliquées.
On peut également envisager d’envoyer le résultat du suivi vers une table afin
d’exécuter les requêtes filtrant sur une liste de SPID et d’ID de transaction.
Pour générer une situation de blocage, créez deux tables (t1 et t2) disposant
chacune d’une colonne de type nombre entiers ; puis, dans chaque table, insérez
un enregistrement avec pour valeur 1. Définissez une trace avec les événements
suivants : Lock:Deadlock, Lock: Deadlock Chain, ainsi que les instructions des
événements correspondant de démarrage et de fin (RPC, SP, SQL), selon la source
soupçonnée. Dans le présent exemple, nous n’avons besoin que de SQL: StmtStarting
et SQL:StmtCompleted.
En plus des colonnes de données par défaut, ajoutez la colonne ID de transaction
et toute autre colonne souhaitée. Filtrez la trace sur l’ID base de données de
la base de données en cours d’utilisation, puis ouvrez deux connexions pour votre
serveur à  partir de l’Analyseur de requêtes. A partir de la connexion 1, exécutez
:

BEGIN TRANSACTION UPDATE t1 SET col1 = 1

A partir de la connexion 2, exécutez :

BEGIN TRANSACTION
UPDATE t2 SET col1 = 1
SELECT * FROM t1
COMMIT TRANSACTION

Et, de nouveau à  partir de la connexion 1, exécutez :

SELECT * FROM t2
COMMIT TRANSACTION

Arrêtez la trace et ouvrez le fichier de suivi. Recherchez les événements Lock:Deadlock
Chain et enregistrez les ID de transaction impliqués. Groupez les résultats par
ID de transaction et étendez les transactions appropriées. La sortie doit être
similaire à  celle présentée dans l’écran 1.
SQL Server Enterprise Manager fournit un assistant apportant une aide dans la
définition des suivis, notamment pour l’identification de la cause d’un blocage.
On peut utiliser l’Assistant de création de suivi (Create Trace) pour configurer
un suivi en choisissant Wizards dans le menu Tools d’Enterprise Manager. Ouvrez
la catégorie Management et sélectionnez Create Trace Wizard.