111
5.2 SQL Trace et le profiler
Deuxième point : comment automatiser les replay ? Le profiler (profiler90.exe
en SQL Server 2005) comporte quelques paramètres d’appel en ligne de commande
(faire profiler90.exe /? pour les voir), mais qui ne permettent pas de lancer une
trace directement en replay. Une solution peut être d’exporter le contenu des ordres
SQL, par la commande File / Export / Extract SQL Server Events, qui génère un
fichier de batches avec extension .sql. Vous pouvez ensuite exécuter l’outil en ligne
de commande sqlcmd.exe avec le paramètre -i :
sqlcmd.exe -E -S monserveur -i c:\temp\monbatch.sql
que vous pouvez lancer de multiples fois dans un script, dans une boucle par
exemple.
Une autre solution consiste à utiliser les outils que l’équipe de support utilisateur
de Microsoft a développés pour faciliter l’utilisation de traces pour les tests de
charge. Ils sont packagés sous le nom de RML Utilities for SQL Server, et peuvent
être téléchargés sur le site de Microsoft (cherchez avec le nom du package). Ils
nécessitent le Framework .NET 3.5, qu’ils installent automatiquement si nécessaire.
Ces outils ne sont pas compatibles SQL Server 2008, notamment à cause des nouveaux types de données. Au moment de la rédaction de ce livre, la version 2008 est
en développement, elle sera donc disponible tôt ou tard.
5.2.2 Diminution de l’impact de la trace
Comme nous l’avons dit, le profiler n’est qu’un client de la fonctionnalité serveur
nommée SQL Trace. Le profiler est très utile en tant qu’outil d’optimisation, de
débogage, et pour essayer, en temps réel, de découvrir la source d’un problème de
performances. Son défaut est qu’il utilise des ressources supplémentaires, soit du
temps processeurs lorsqu’il est lancé sur le serveur, soit de la bande passante réseau
s’il tourne sur un poste client (ce qui est meilleur). Lorsque vous souhaitez planifier
des traces, ou exécuter des traces de longue haleine, par exemple pour construire une
baseline, ou pour identifier à travers une période représentative les requêtes les plus
coûteuses, la solution la plus souple et la moins consommatrice de ressources, est de
maintenir la trace à même SQL Server. Pour cela, vous disposez de quelques procédures stockées système. Vous pouvez exporter la définition de la trace définie dans le
profiler en ordres SQL, ce qui rend très facile la création de scripts de trace. Dans le
profiler, choisissez dans le menu « File » la commande Export / Script Trace Definition, puis votre version de SQL Server. Voici un exemple simplifié de script généré :
declare @rc int
declare @TraceID int
declare @maxfilesize bigint
set @maxfilesize = 5
exec @rc = sp_trace_create @TraceID output, 0,
N'InsertFileNameHere', @maxfilesize, NULL
if (@rc != 0) goto error
declare @on bit
5.2 SQL Trace et le profiler
Deuxième point : comment automatiser les replay ? Le profiler (profiler90.exe
en SQL Server 2005) comporte quelques paramètres d’appel en ligne de commande
(faire profiler90.exe /? pour les voir), mais qui ne permettent pas de lancer une
trace directement en replay. Une solution peut être d’exporter le contenu des ordres
SQL, par la commande File / Export / Extract SQL Server Events, qui génère un
fichier de batches avec extension .sql. Vous pouvez ensuite exécuter l’outil en ligne
de commande sqlcmd.exe avec le paramètre -i :
sqlcmd.exe -E -S monserveur -i c:\temp\monbatch.sql
que vous pouvez lancer de multiples fois dans un script, dans une boucle par
exemple.
Une autre solution consiste à utiliser les outils que l’équipe de support utilisateur
de Microsoft a développés pour faciliter l’utilisation de traces pour les tests de
charge. Ils sont packagés sous le nom de RML Utilities for SQL Server, et peuvent
être téléchargés sur le site de Microsoft (cherchez avec le nom du package). Ils
nécessitent le Framework .NET 3.5, qu’ils installent automatiquement si nécessaire.
Ces outils ne sont pas compatibles SQL Server 2008, notamment à cause des nouveaux types de données. Au moment de la rédaction de ce livre, la version 2008 est
en développement, elle sera donc disponible tôt ou tard.
5.2.2 Diminution de l’impact de la trace
Comme nous l’avons dit, le profiler n’est qu’un client de la fonctionnalité serveur
nommée SQL Trace. Le profiler est très utile en tant qu’outil d’optimisation, de
débogage, et pour essayer, en temps réel, de découvrir la source d’un problème de
performances. Son défaut est qu’il utilise des ressources supplémentaires, soit du
temps processeurs lorsqu’il est lancé sur le serveur, soit de la bande passante réseau
s’il tourne sur un poste client (ce qui est meilleur). Lorsque vous souhaitez planifier
des traces, ou exécuter des traces de longue haleine, par exemple pour construire une
baseline, ou pour identifier à travers une période représentative les requêtes les plus
coûteuses, la solution la plus souple et la moins consommatrice de ressources, est de
maintenir la trace à même SQL Server. Pour cela, vous disposez de quelques procédures stockées système. Vous pouvez exporter la définition de la trace définie dans le
profiler en ordres SQL, ce qui rend très facile la création de scripts de trace. Dans le
profiler, choisissez dans le menu « File » la commande Export / Script Trace Definition, puis votre version de SQL Server. Voici un exemple simplifié de script généré :
declare @rc int
declare @TraceID int
declare @maxfilesize bigint
set @maxfilesize = 5
exec @rc = sp_trace_create @TraceID output, 0,
N'InsertFileNameHere', @maxfilesize, NULL
if (@rc != 0) goto error
declare @on bit