SQLDIAG (épisode 1)

Début d’une assez longue série de posts sur l’utilitaire SQLDIAG et ses petits camarades de jeu PSSDIAG, SQLNexus et autres RML Utilities…

SQLDIAG est un utilitaire en mode ligne de commandes qui est livré avec SQL Server depuis plus de 10 ans maintenant. Il est bien caché, peu dfhe gens l’utilisent mais il peut être d’une puissance redoutable. Il est capable de lancer en même temps:

• Une collecte perfmon.
• Une trace type SQL Trace.
• Une collecte des journaux d’évènements.
• Un inventaire complet  de la machine basé sur msinfo32.
• Un inventaire complet de l’instance.

Il permettra même de corréler des traces de compteurs perfmon et le traçage de sessions SQL dans Profiler. Il se base sur un fichier de configuration au format XML. Il en existe un par défaut (SQLDiag.xml) qui se trouve sous ~Tools\Binn, mais il est très exhaustif  et trace tous les compteurs et évènements disponibles. L’inconvénient de l’utiliser est qu’il créé des traces pénalisantes et très encombrantes, plusieurs dizaines de Gb de fichiers textes, blg, trc, etc… Donc on a intérêt à se créer son petit fichier XML pour ne capturer que ce dont on aura besoin.

SQLDiag.xml

Dans ce premier épisode, nous allons donc parler de la structure de ce fichier XML. Elle ressemble vu d’en haut à ceci:

<Collection>
<Machines>
        <Machine name=".">
                <MachineCollectors>
                        <EventlogCollector />
                        <PerfmonCollector />
                </MachineCollectors>
                <Instances>
                       <Instance>
                              <Collectors>
                                    <SqldiagCollector />
                                    <BlockingCollector />
                                    <ProfilerCollector />
                                    <CustomDiagnostics />
                             </Collectors>
                     </Instance>
              </Instances>
      </Machine>
</Machines>
</Collection>

Chaque balise %Collector délimite la zone de paramétrage de chaque collecteur de trace. Pour activer / désactiver un collecteur, passer son attribut enabled à true ou false:

• EventlogCollector pour collecter les journaux d’évènements.
  
• PerfmonCollector pour lancer la trace perfmon.
• SQLdiagCollector pour récupérer toute la configuration de l’instance: paramètres, contenu de tous les errorlogs, connexions, verrous, liste des bases et options, xp_msver, etc…
  
• BlockingCollector pour l’évènement BlockedProcessReport de SQL Trace, rapporte les processus bloqués si le paramètre ‘blocked process threshold (s)‘ est configuré.
• ProfilerCollector pour la trace SQL Trace complète avec les évènements que l’on aura indiqué.
  
• CustomDiagnostics pour lancer des exécutables supplémentaires, en l’occurence msinfo32 dans notre cas, et récupérer la configuration complète de la machine.
  

PerfmonCollector

C’est le collecteur de compteurs perfmon. Ses éléments fils sont <PerfmonObject /> qui désigne la famille de compteurs comme “PhysicalDisk(*)” par exemple, et <PerfmonCounter /> qui désigne le compteur associé comme “\Avg. Disk sec/Read“. On aura besoin d’activer chaque compteur en passant son attribut enabled à true. Une zone PerfmonCollector peut ressembler à ceci, avec le nom des compteurs en vert:

<PerfmonCollector enabled="true" pollinginterval="30" maxfilesize="256">
    <PerfmonCounters>
        <PerfmonObject name="\PhysicalDisk(*)" enabled="true">
             <PerfmonCounter name="\Avg. Disk sec/Read" enabled="true" />
             <PerfmonCounter name="\Avg. Disk sec/Write" enabled="true" />
             <PerfmonCounter name="\Disk Read Bytes/sec" enabled="true" />
             <PerfmonCounter name="\Disk Write Bytes/sec" enabled="true" />
             <PerfmonCounter name="\Avg. Disk Bytes/Transfer" enabled="true" />
        </PerfmonObject>
        <PerfmonObject name="\Processor(*)" enabled="true">
            <PerfmonCounter name="\% Processor Time" enabled="true" />
            <PerfmonCounter name="\% User Time" enabled="true" />
            <PerfmonCounter name="\% Privileged Time" enabled="true" />
        </PerfmonObject>
    </PerfmonCounters>
</PerfmonCollector>

L’attribut pollinginterval indique la fréquence d’échantillonnage des compteurs. Le fichier de sortie de ce collecteur sera un fichier BLG intitulé tout simplement SQLDIAG.blg. Il pourra être corrélé plus tard avec la trace qui sera générée par le collecteur ProfilerCollector.

SQLdiagCollector

C’est le collecteur de données de l’instance. Il n’est pas paramétrable est composé d’une seule ligne:

<SqldiagCollector enabled="true" startup="false" shutdown="true" /> 

On l’activera donc en passant son attribut enabled à true là encore. Les paramètres startup et shutdown permettent d’indiquer si la collecte se fait au démarrage ou à l’arrêt de la trace SQLDIAG.

BlockingCollector:

C’est le collecteur des processus bloqués en attente de libération de ressources (verrous). Lui aussi n’est constitué  que d’un seul élément:

<BlockingCollector enabled="true" pollinginterval="5" maxfilesize="350" /> 

L’attribut pollinginterval désigne la fréquence d’échantillonnage  de l’évènement, et maxfilesize la taille maximale du fichier en sortie. Ce collecteur se base sur le paramètre d’instance ‘blocked process threshold‘ qui définit la durée en secondes au delà de laquelle on considère que le blocage est anormalement long. Il faudra définir ce paramètre car sa valeur par défaut est à zéro, ce qui signifie qu’il n’est pas activé. Par exemple pour mettre le seuil à 20 secondes:

sp_configure 'blocked process threshold', 20
go
reconfigure
go

Ensuite, le collecteur va créer une trace SQL Trace avec le seul évènement ‘Blocked Process Report‘, et capturer les sessions qui auront été bloquées pendant plus de 20 secondes. Le fichier de sortie de ce collecteur est un fichier trc classique nommé <INSTANCE>_SQLDIAG_sp_trace_blk.

ProfilerCollector:

Ensuite, ProfilerCollector est le collecteur de trace SQL Trace classique. Comme pour PerfmonCollector, il va disposer d’éléments fils comme <EventType /> et <Event /> dans lesquels on va bien entendu retrouver nos classes d’évènements:

<ProfilerCollector enabled="true" template="_GeneralPerformance100.xml" pollinginterval="5" maxfilesize="350">
     <Events>
         <EventType name="Stored Procedures">
             <Event id="10" name="RPC:Completed" enabled="true"/>
             <Event id="11" name="RPC:Starting" enabled="true" />
             <Event id="43" name="SP:Completed" enabled="true" />
             <Event id="42" name="SP:Starting" enabled="true" />
             <Event id="45" name="SP:StmtCompleted" enabled="true" />
             <Event id="44" name="SP:StmtStarting" enabled="true" />
        </EventType>
       <EventType name="TSQL">
             <Event id="40" name="SQL:StmtStarting" enabled="true"/>
             <Event id="41" name="SQL:StmtCompleted" enabled="true" />
       </EventType>
     </Events>
 </ProfilerCollector>

Le fichier de sortie de ce collecteur sera aussi un fichier trace classique nommé <INSTANCE>_SQLDIAG_sp_trace.

CustomDiagnostics

Enfin, CustomDiagnostics permet de pousser encore plus loin la personnalisation du rapport, en nous permettant d’utiliser nos propres outils de collecte. L’outil qui est utilisé par défaut est msinfo32 qui est utilisé pour afficher de manière graphique (Démarrer -> Exécuter -> msinfo32) ou en ligne de commande toute la configuration de la machine hôte:

<CustomDiagnostics>
 <CustomGroup name="msinfo" enabled="true" />
 <CustomTask enabled="true" groupname="MsInfo" taskname="Get MSINFO32" type="Utility" point="Startup" wait="OnlyOnShutdown" cmd="start /B /WAIT MSInfo32.exe /computer %server% /report
         &quot;%output_path%%server%_MSINFO32.TXT&quot; /categories +SystemSummary+ResourcesConflicts+ResourcesIRQS+ComponentsNetwork+ComponentsStorage+ComponentsProblemDevices+SWEnvEnvVars+
         SWEnvNetConn+SWEnvServices+SWEnvProgramGroup+SWEnvStartupPrograms" />
 <CustomTask enabled="true" groupname="MsInfo" taskname="Get default traces" type="Copy_File" point="Startup" wait="OnlyOnShutdown" cmd="&quot;%sspath%log\log*.trc&quot; &quot;%output_path%&quot;" />
 <CustomTask enabled="true" groupname="MsInfo" taskname="Get SQLDumper log" type="Copy_File" point="Startup" wait="OnlyOnShutdown" cmd="&quot;%sspath%log\SQLDUMPER_ERRORLOG.log&quot;
          &quot;%output_path%%server%_%instance%_SQLDUMPER_ERRORLOG.log&quot;" />
 </CustomDiagnostics>

Mais en plus de récupérer le contenu d’une trace msinfo32, il peut également récupérer le contenu des traces SQL Server par défaut *, et les stacktraces générées par SQL Server lorsqu’il rencontre une erreur fatale sur un module. Il va copier le contenu de ces traces dans le répertoire passé à l’exécution de SQLDIAG.

Exécution d’une trace

Une fois le fichier XML défini, lancer une trace devient un jeu d’enfant:

$ sqldiag /I MyXMLfile.xml /O e:/SQLDIAG/TRACE1
2010/02/04 18:58:10.28 SQLDIAG Collector version
2010/02/04 18:58:10.29 SQLDIAG

IMPORTANT:  Please wait until you see "Collection started" before attempting to reproduce your issue

2010/02/04 18:58:10.29 SQLDIAG Output path: e:\SQLDIAG\TRACE1\
2010/02/04 18:58:10.33 SQLDIAG Collecting from 1 logical machine(s)
2010/02/04 18:58:10.34 SQLDIAG Invalid node fetched. (null)
2010/02/04 18:58:10.34 SQLDIAG Invalid node fetched. (null)
2010/02/04 18:58:10.34 MS2K8-WIN2008-1\* SQL Server version: 10
2010/02/04 18:58:10.35 MS2K8-WIN2008-1\* Machine name: MS2K8-WIN2008-1 (this machine)
2010/02/04 18:58:10.35 MS2K8-WIN2008-1\* Target machine is not a cluster
2010/02/04 18:58:10.35 MS2K8-WIN2008-1\* Instance: (Default) (32-bit)
2010/02/04 18:58:12.40 SQLDIAG Initialization starting...
2010/02/04 18:58:13.98 MS2K8-WIN2008-1\* Starting Profiler trace
2010/02/04 18:58:14.94 MS2K8-WIN2008-1\* Starting Blocking script
2010/02/04 18:58:16.88 MS2K8-WIN2008-1\* MsInfo: Get MSINFO32
2010/02/04 18:58:17.26 MS2K8-WIN2008-1\* MsInfo: Get default traces
2010/02/04 18:58:17.47 MS2K8-WIN2008-1\* MsInfo: Get SQLDumper log
2010/02/04 18:58:17.71 MS2K8-WIN2008-1\* Adding Perfmon counters...
2010/02/04 18:58:20.73 MS2K8-WIN2008-1\* Starting Perfmon
2010/02/04 18:58:20.73 SQLDIAG Initialization complete
2010/02/04 18:58:21.53 MS2K8-WIN2008-1\* Perfmon started
2010/02/04 18:58:21.58 MS2K8-WIN2008-1\* Collecting diagnostic data

2010/02/04 18:58:22.28 SQLDIAG Collection started.  Press Ctrl+C to stop.

La trace est lancée, un simple Ctrl-C suffira à la stopper. Les commutateurs /I et /O permettent d’indiquer le fichier de configuration XML choisi et le répertoire où va se loger le contenu de la trace complète.

Il existe aussi des commutateurs pour indiquer à SQLDIAG de programmer son exécution à des heures déterminées. Il est même possible de l’enregistrer en tant que service dans windows.

Dans le prochain post sur SQLDIAG, on verra comment dépouiller les fichiers de résultat.

A+ David B.

(avec la collaboration de Martial LUCAS. )

* Depuis la version SQL Server 2005, un paramètre instance ‘default trace enabled’ avec une valeur de 1 (valeur par défaut) génère une trace systématiquement au démarrage de l’instance. Cette trace contient les classes évènements Database, Errors and Warnings, Full text, Objects, Performance, Server et Security Audit. Chaque trace vient se loger dans le répertoire des ERRORLOG par défaut.

Continuez votre lecture sur le blog :

• SQLDIAG (épisode 2) (David Baffaleuf) [SQL Server]
• Scruter les journaux d’évènements Windows avec LogParser (David Baffaleuf) [SQL Server]
• Comparatif MySQL dans le PaaS, épisode 3 : Amazon RDS (2/2) (David Baffaleuf) [AWSMySQL]
• Oracle RDS : récupérer les tracefiles, comment faire ? (Emmanuel RAMI) [AWSOracle]
• Déterminer la fréquence horaire d’exécution d’une procédure stockée sous SQL Server (Vincent Delabre) [SQL Server]