96
Chapitre 5. Analyse des performances
Figure 5.3 — Options de la session SSMS
5.2 SQL TRACE ET LE PROFILER
SQL Trace est une technologie intégrée au moteur SQL Server, qui permet de
fournir à un client le détail de quantité d’événements se produisant dans les différentes parties de SQL Server.
SQL Trace peut être comparé à un débogueur. Devant un programme complexe,
organisé en multiples classes et modules, un développeur qui doit identifier la cause
d’un problème à partir d’un rapport de bug n’a qu’une méthode efficace à
disposition : reproduire le problème en suivant pas à pas le comportement du code à
l’aide de son outil de débogage, observant les valeurs attribuées aux variables, les
changements d’état des classes, l’itération des boucles. Sans cette capacité à entrer
dans les opérations du code, à observer finement ce qui se passe, le travail de débogage serait réduit à une recherche fastidieuse faite d’essais, d’instructions PRINT, de
lecture attentive de code. Un serveur SQL ajoute des niveaux de complexité supplémentaires, qui rendent la méthode expérimentale cauchemardesque : on peut rarement deviner à la simple lecture d’une requête quel en est le plan d’exécution, c’està-dire la stratégie que va appliquer SQL Server pour en assurer l’exécution optimale.
Pour le savoir, il faudrait faire soi-même tout le travail de l’optimiseur : inspecter les
tables, lister les index et leurs statistiques, estimer le nombre de lignes impactées,
essayer plusieurs stratégies, estimer leur coût… Il est donc pratiquement impossible
de deviner ce qui va précisément se passer. De plus, l’exécution concurrentielle des
requêtes rend les performances dépendantes du contexte : charge de travail des processeurs, attente sur des verrous, performance des tables temporaires…
Chapitre 5. Analyse des performances
Figure 5.3 — Options de la session SSMS
5.2 SQL TRACE ET LE PROFILER
SQL Trace est une technologie intégrée au moteur SQL Server, qui permet de
fournir à un client le détail de quantité d’événements se produisant dans les différentes parties de SQL Server.
SQL Trace peut être comparé à un débogueur. Devant un programme complexe,
organisé en multiples classes et modules, un développeur qui doit identifier la cause
d’un problème à partir d’un rapport de bug n’a qu’une méthode efficace à
disposition : reproduire le problème en suivant pas à pas le comportement du code à
l’aide de son outil de débogage, observant les valeurs attribuées aux variables, les
changements d’état des classes, l’itération des boucles. Sans cette capacité à entrer
dans les opérations du code, à observer finement ce qui se passe, le travail de débogage serait réduit à une recherche fastidieuse faite d’essais, d’instructions PRINT, de
lecture attentive de code. Un serveur SQL ajoute des niveaux de complexité supplémentaires, qui rendent la méthode expérimentale cauchemardesque : on peut rarement deviner à la simple lecture d’une requête quel en est le plan d’exécution, c’està-dire la stratégie que va appliquer SQL Server pour en assurer l’exécution optimale.
Pour le savoir, il faudrait faire soi-même tout le travail de l’optimiseur : inspecter les
tables, lister les index et leurs statistiques, estimer le nombre de lignes impactées,
essayer plusieurs stratégies, estimer leur coût… Il est donc pratiquement impossible
de deviner ce qui va précisément se passer. De plus, l’exécution concurrentielle des
requêtes rend les performances dépendantes du contexte : charge de travail des processeurs, attente sur des verrous, performance des tables temporaires…