Etape 9 : Examinez les données et procédez aux déductions

table myTrace, je
peux rapidement identifier les bases de données concernées
par les processus à  longue durée d’exécution. Mais plus intéressant
encore, je peux identifier des tendances dans le
temps et voir quelles bases de données affichent une dégradation
des performances et méritent mon attention.
Comme je capture l’heure de début de chaque processus,
je peux voir à  quels moments les processus les plus lents
s’exécutent. Il est possible de détecter les requêtes qui effectuent
le plus d’opérations de lecture et d’écriture et quelles
applications sont le plus occupées et à  quel
moment. A partir de ces informations, je
peux optimiser les requêtes, ajouter un index,
ou réécrire une procédure stockée afin
d’essayer de faire en sorte qu’elle s’exécute
en moins d’une seconde.

Les aspects à  prendre en
compte


Quelques aspects doivent être pris en compte
à  propos des traces planifiées. Comme
elles s’exécutent à  des intervalles réguliers, elles peuvent
passer à  côté d’un processus long s’exécutant en dehors de
la planification. Une méthode pour gérer cette limitation
consiste à  modifier la planification d’un jour sur l’autre. Si
vous prévoyez d’exécuter la trace pendant 5 minutes à  15
minutes d’intervalle en commençant à  6:00 AM les lundis et
mercredis, vous pouvez la lancer à  6:07 AM les mardis et jeudis.
Le processus ne devient pas aléatoire, mais vous pouvez
au moins apporter une once de diversité.

Dans un monde parfait, vous pourriez configurer ces
traces de telle sorte qu’elles s’exécutent sur votre base de
données de développement au cours de la phase de test, afin
de localiser les problèmes avant de basculer votre base de
données en production. Mais, d’un point de vue réaliste, il
peut s’avérer nécessaire d’exécuter ces traces sur votre
serveur de production car un serveur de test ne supportera
pratiquement jamais la même charge que votre environnement
de production. Le fait d’utiliser le minimum d’événements
et de colonnes de données dans votre trace contribuera
à  réduire la sollicitation d’un serveur de production.
Une autre méthode destinée à  réduire cette sollicitation
consiste à  configurer un serveur lié et à  écrire la table de résultats
de trace SQL Server sur celui-ci. Par ailleurs, le fait
d’écrire le fichier de sortie de la trace sur un lecteur réseau
est utile car cela évite de solliciter le sous-système de disque
du serveur SQL Server.

Les traces automatisées procurent des avantages largement
supérieurs aux efforts requis pour leur mise en oeuvre.
Lorsque les données de performances sont regroupées dans
une table, vous pouvez obtenir rapidement des informations
sur les applications qui accèdent à  votre serveur. Le fait
d’exécuter une requête simple qui compte le nombre de
processus dont la durée est supérieure à  1 seconde et les regroupe
par ID de base de données permet de savoir quelles
bases de données ont le plus de processus à  longue durée
d’exécution. Le code du listing Web 2 crée une table d’analyse,
fournie gracieusement par Kalen Delaney, qui vous permet
de convertir ces numéros EventClass énigmatiques affichés
lors de l’exécution de traces du Générateur de profils
en descriptions. Elle a également inclus un exemple d’instruction
SQL destinée à  récupérer rapidement des moyennes
par EventClass.
L’application de ces 9 étapes crée un cadre pour l’exécution
de toutes les traces imaginables. En créant la trace avec
le Générateur de profils, en enregistrant le script SQL en tant
que procédure stockée et en l’intégrant dans la tâche que
vous avez déjà  créée, le Générateur de profils peut capturer
une multitude d’informations sur SQL Server, allant des recompilations
de procédures stockées aux acquisitions de
verrous et à  la croissance du fichier de base de données.
Quel que soit l’aspect que vous cherchez à  améliorer, la
configuration des traces planifiées vous permet d’acquérir
une vision cohérente de vos bases de données et vous aide à 
en savoir plus sur SQL Server.