Cap Data Team SGBD Blog : Oracle, SQL Server, MySQL, Sybase... » sqldiag http://blog.capdata.fr Le blog technique sur les bases de données de CAP DATA Consulting Wed, 01 Feb 2012 17:21:53 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 SQLDIAG (épisode 2) http://blog.capdata.fr/index.php/sqldiag-episode-2/ http://blog.capdata.fr/index.php/sqldiag-episode-2/#comments Mon, 10 May 2010 16:28:36 +0000 David BAFFALEUF http://blog.capdata.fr/?p=985 Deuxième épisode de la trilogie sur SQLDIAG et les outils avancés de diagnostic autour de SQL Server. Nous parlerons aujourd’hui du résultat de la trace lancée lors du rapport précédent et de son contenu. Nous verrons comment charger le contenu de la trace SQL et du fichier BLG dans SQL Profiler pour interprétation. Puis nous verrons comment mettre en place RML Utilities pour agréger et afficher le résultat d’une trace SQLDIAG.

Contenu d’une trace SQLDIAG:

Une fois la trace terminée, Ctrl-C stoppe le collecteur et commence à écrire les fichiers résultats sous l’arborescence. On retrouve une arborescence telle que:

<NOM TRACE>
|___ log_*.trc
|___ MS2K8-WIN2008-1__sp_sqldiag_Shutdown.OUT
|___ MS2K8-WIN2008-1_MSINFO32.txt
|___ MS2K8-WIN2008-1_SQLDIAG__sp_trace_*.trc
|___ SQLDIAG.lbg
|___ internal
     |___ *.txt
     |___ *.OUT
  • log*.trc: ces fichiers contiennent la trace par défaut de l’instance. Ils ont été copiés de leur répertoire origine (le plus souvent ~MSSQL\LOG). Cf note bas de page dans le premier article.
  • MS2K8-WIN29008-1__sp_sqldiag_Shutdown.OUT: ce fichier est divisé en plusieurs parties. Il n’est généré qu’au moment du Crtrl-C pour ne pas rater d’évènements survenus pendant la trace. Il commence par contenir le contenu de chaque fichier ERRORLOG*, puis la configuration de l’instance, la liste des processus (sp_who), la liste des verrous (sp_lock), la liste des bases (sp_helpdb), des informations sur le binaire (xp_msver), donne la liste de toutes les procédures stockées étendues déclarées (sp_helpextendedproc) , et le contenu de sysprocesses, sys.dm_exec_sessions, ::fn_virtualservernodes() si sur cluster, sysdevices, sysdatabases, sys.master_files. Enfin, la liste des requêtes en cours d’exécution. Le reste , où chaque vue sys.dm_os* est récupérée, est plus à destination du support pour diagnostic. Celà leur donne une image précise de l’activité au niveau des schedulers (SQLOS), de la mémoire, des latches, des modules chargés dans l’espace d’adressage de sqlservr.exe, etc… C’est beaucoup plus pratique que de faire générer un dump ou un mini-dump au client qui rencontre un problème. D’ailleurs, il y aura certainement un article prochainement sur les vues sys.dm_os* principales, je ne m’étends donc pas dessus, car pour l’instant ce n’est pas ce qui nous intéresse.
  • MS2K8-WIN29008-1_MSINFO32.txt: Contient le contenu au format texte de msinfo32. Toutes les informations systèmes sont contenues dans ce fichier, classées par section entre crochets ([]). Nombre d’entre elles sont sans intérêt (IRQ/DMA, périphériques, clavier, pilotes, etc…), il y cependant certaines sections qui valent le coup d’oeil: [System Summary] pour les informations systèmes courantes (OS, CPU, mémoire, etc…), [Drives] et [Disks] pour les disques, [Running Tasks] pour les processus en cours d’exécution, [Windows Error Reporting] pour les messages d’erreurs de l’eventvwr.
  • MS2K8-WIN29008-1_SQLDIAG__sp_trace_*.trc: ces fichiers contiennent la trace SQL Trace que l’on a paramétrée dans le fichier XML.
  • SQLDIAG.blg: ce fichier contient la trace système paramétrée dans le fichier XML.
  • ~internal\: ce sous répertoire contient les logs de l’exécution de SQLDIAG. En fonction de la version utilisée, les fichiers OUT et txt peuvent se trouver au même niveau que les fichiers résultats.

Les deux axes qui vont nous intéresser sont principalement les fichiers de trace SQL et le fichier BLG. Les autres fichiers seront plus à utiliser à des fins de diagnostic.

Charger une trace SQL et un fichier BLG dans SQL Profiler:

Il est possible de charger un fichier de compteurs perfmon et une trace SQL dans SQL Profiler pour corrélation. Ce n’est possible toutefois que si les deux traces ont été générées ensembles, le plus souvent à l’aide d’un outil comme SQLDIAG ou PSSDIAG. Tout d’abord, ouvrir la trace SQL dans Profiler, puis File->Import Performance Data… Sélectionner le fichier BLG généré dans la même trace, puis les compteurs à charger (pour plus de lisibilité, on ne prendra que les compteurs disque dans notre cas), et importer la trace:

L’écran se divise en quatre parties. Les zones extrêmes représentent l’affichage classique de SQL Profiler: texte et statistiques des requêtes. La partie centrale présente les graphes associés aux compteurs du fichier BLG, et la partie inférieure la liste des compteurs avec les valeurs Min, Max, Average:

Il est possible de zoomer et de déplacer le curseur temporel dans la partie centrale, et Profiler va pointer sur les requêtes exécutées à l’instant sélectionné, et la valeur de ‘Selected‘ dans la partie inférieure est également mise à jour pour chaque compteur.

Maintenant il faut bien faire attention à ce que l’on lit ou ce que l’on interprète. Il faut bien se rendre compte que SQL Trace collecte les statistiques pour un évènement une fois qu’il s’est terminé, donc ce n’est pas parce qu’on va pointer sur un pic CPU ou un de temps de service disque  qu’on va tomber pile sur le problème. On va dire que ça facilite la tâche, ça permet de corréler des informations, mais ça ne fait pas le travail à votre place. Une requête peut commencer à faire des lectures physiques depuis le disque pendant une minute, puis faire d’autres opérations en mémoire (des tris, des agrégations) et se terminer un certain temps  après le pic. Un petit exemple d’une requête qui fait des accès physiques pendant 1 minute et qui se termine à la fin du pic. Si on ne regarde pas bien, on rate l’information:

RML Utilities:

RML Utilities est une petite application due, comme pas mal d’outils et d’avancées sur le moteur, à l’initiative de l’équipe Customer Support Services. La première version de RML s’appuyait sur deux binaires Ostress et ReadTrace principalement, elle a été refondue en 2007 pour incorporer une petite application d’affichage des traces, basée sur des reports RDL. Les versions x86 et x64 sont téléchargeables depuis la page d’accueil de RML. L’installation n’a rien de compliqué, donc on va passer directement à la phase d’intégration des traces.

Cette intégration se fait avec ReadTrace. Tout d’abord, on va créer une base pour stocker les données des traces:

create database RMLDB

Puis ReadTrace avec les options -I<chemin vers fichier trc initial> -S<instance> -d<Baserepository> (important de ne pas laisser d’espace entre le commutateur et le paramètre)

$ ./ReadTrace -IE:/SQLDIAG/TRACE3/SQL2008__sp_trace.trc -SMS2K8-Win2008-1 -E -dRMLDB

05/10/10 17:13:20.920 [0X000013B4] Output path was not specified; defaulting to C:\Users\capdata\AppData\Local\Temp\2\\output
05/10/10 17:13:21.000 [0X000013B4] Readtrace a SQL Server trace processing utility.
Version 9.01.0109 built for x86.
Copyright (c) Microsoft Corporation 1997-2008. All rights reserved.
05/10/10 17:13:21.002 [0X000013B4] Number of processors: 1
05/10/10 17:13:21.002 [0X000013B4]     Active proc mask: 0x00000001
05/10/10 17:13:21.008 [0X000013B4]         Architecture: 0
05/10/10 17:13:21.009 [0X000013B4]            Page size: 4096
05/10/10 17:13:21.009 [0X000013B4]         Highest node: 0
05/10/10 17:13:21.010 [0X000013B4]         Package mask: 0x00000001
05/10/10 17:13:21.011 [0X000013B4]         Processor(s): 0x00000001 Function units: Separated
05/10/10 17:13:21.011 [0X000013B4]           Processors: 0x00000001 assigned to Numa node: 0
05/10/10 17:13:21.012 [0X000013B4] -IE:/SQLDIAG/TRACE3/SQL2008__sp_trace.trc
05/10/10 17:13:21.012 [0X000013B4] -SMS2K8-Win2008-1
05/10/10 17:13:21.013 [0X000013B4] -E
05/10/10 17:13:21.013 [0X000013B4] -dRMLDB
05/10/10 17:13:21.014 [0X000013B4] Using language id (LCID): 1024 [French_France.1252] for character formatting with NLS: 0x00500100 and Defined: 0x00050100
05/10/10 17:13:21.015 [0X000013B4] Attempting to cleanup existing RML files from previous execution
05/10/10 17:13:21.016 [0X000013B4] Using extended RowsetFastload synchronization
05/10/10 17:13:21.017 [0X000013B4] Establishing initial database connection:
05/10/10 17:13:21.017 [0X000013B4] Server: MS2K8-Win2008-1
05/10/10 17:13:21.018 [0X000013B4] Database: RMLDB
05/10/10 17:13:21.018 [0X000013B4] Authentication: Windows
05/10/10 17:13:21.470 [0X000013B4] Using SQL Client version 10
05/10/10 17:13:21.471 [0X000013B4] Creating or clearing the performance database
05/10/10 17:13:22.916 [0X000013B4] Processing file: E:\SQLDIAG\TRACE3\SQL2008__sp_trace.trc (SQL 2005)
05/10/10 17:13:22.918 [0X000013B4] Validating core events exist
05/10/10 17:13:22.919 [0X000013B4] Validating necessary events exist for analysis
05/10/10 17:13:22.921 [0X000013B4] Validating necessary events exist for RML breakout
05/10/10 17:13:22.922 [0X000013B4] WARNING: Event [Server: Server Memory Change] missing from trace
05/10/10 17:13:22.923 [0X000013B4] WARNING REPLAY: The following trace events were not captured: [Sessions:ExistingConnection, Security Audit: Audit Login, Se
rity Audit: Audit Logout, Stored Procedures: RPC Output Parameter, Cursors:Unprepare, Cursors:CursorClose, Cursors:CursorPrepare, Cursors:CursorCreated, Curso
:CursorExecute, TSQL: Prepare SQL, TSQL: Unprepare SQL, Errors and Warnings:Attention, Transactions:SQLTransaction, Transactions:DTCTransaction, Transactions:
:Begin Tran starting and completed, Transactions:TM:Commit Tran starting and completed, Transactions:TM:Rollback Tran starting and completed, Transactions:TM:
ve Tran starting and completed, Transactions:TM:Promote Tran starting and completed, SQL:BatchStarting and SQL:BatchCompleted, RPC:Starting and RPC:Completed]
Review the help file to ensure that you have collected the appropriate set of events and columns for RML replay needs.  Lack of these events can lead to sever
replay problems.

Trace flag -T28 disables the check allowing RML output processing. *** Use with caution as the output and behavior could be unpredictable.
05/10/10 17:13:22.993 [0X000013B4] Events Read: 1000 Queued: 1000 Processed/sec: 0
05/10/10 17:13:23.026 [0X000013B4] Processing file: E:\SQLDIAG\TRACE3\SQL2008__sp_trace_1.trc (SQL 2005)
05/10/10 17:13:23.038 [0X000013B4] Events Read: 2000 Queued: 2000 Processed/sec: 0
05/10/10 17:13:23.070 [0X000013B4] Processing file: E:\SQLDIAG\TRACE3\SQL2008__sp_trace_2.trc (SQL 2005)
05/10/10 17:13:23.082 [0X000013B4] Events Read: 3000 Queued: 3000 Processed/sec: 0
05/10/10 17:13:23.261 [0X000013B4] Events Read: 4000 Queued: 4000 Processed/sec: 0
05/10/10 17:13:23.271 [0X000013B4] Processing file: E:\SQLDIAG\TRACE3\SQL2008__sp_trace_3.trc (SQL 2005)
05/10/10 17:13:23.284 [0X000013B4] Events Read: 5000 Queued: 5000 Processed/sec: 0
05/10/10 17:13:23.328 [0X000013B4] Processing file: E:\SQLDIAG\TRACE3\SQL2008__sp_trace_4.trc (SQL 2005)
05/10/10 17:13:23.342 [0X000013B4] Events Read: 6000 Queued: 6000 Processed/sec: 0
05/10/10 17:13:23.361 [0X000013B4] Processing file: E:\SQLDIAG\TRACE3\SQL2008__sp_trace_5.trc (SQL 2005)
05/10/10 17:13:23.366 [0X000013B4] Events Read: 7000 Queued: 7000 Processed/sec: 0
05/10/10 17:13:23.396 [0X000013B4] Processing file: E:\SQLDIAG\TRACE3\SQL2008__sp_trace_6.trc (SQL 2005)
05/10/10 17:13:23.406 [0X000013B4] Processing file: E:\SQLDIAG\TRACE3\SQL2008__sp_trace_7.trc (SQL 2005)
05/10/10 17:13:23.475 [0X000013B4] Events Read: 8000 Queued: 8000 Processed/sec: 0
05/10/10 17:13:23.574 [0X000013B4] Processing file: E:\SQLDIAG\TRACE3\SQL2008__sp_trace_8.trc (SQL 2005)
05/10/10 17:13:24.175 [0X000013B4] Processing file: E:\SQLDIAG\TRACE3\SQL2008__sp_trace_9.trc (SQL 2005)
05/10/10 17:13:24.313 [0X000013B4] Events Read: 9000 Queued: 8998 Processed/sec: 2
05/10/10 17:13:24.854 [0X000013B4] Processing file: E:\SQLDIAG\TRACE3\SQL2008__sp_trace_10.trc (SQL 2005)
05/10/10 17:13:24.905 [0X000013B4] Processing file: E:\SQLDIAG\TRACE3\SQL2008__sp_trace_11.trc (SQL 2005)
05/10/10 17:13:24.939 [0X000013B4] Processing file: E:\SQLDIAG\TRACE3\SQL2008__sp_trace_12.trc (SQL 2005)
05/10/10 17:13:24.959 [0X000013B4] Found TRACE_STOP with 0 bytes of data
05/10/10 17:13:24.961 [0X000013B4] Found [TRACE_STOP] event indicating the end of the trace files.
05/10/10 17:13:24.962 [0X000013B4] Reads completed
05/10/10 17:13:24.965 [0X000013B4] Shutting down the worker thread message queues.
05/10/10 17:13:24.996 [0X000013B4] Waiting for the worker threads to complete final actions.
05/10/10 17:13:26.074 [0X000013B4] Performing general cleanup actions.
05/10/10 17:13:26.076 [0X000013B4] Reducing cached memory.
05/10/10 17:13:26.096 [0X000013B4] Total Events Processed: 11117
05/10/10 17:13:26.101 [0X000013B4]  Total Events Filtered: 0
05/10/10 17:13:26.102 [0X000013B4] Parse errors: 0
05/10/10 17:13:26.224 [0X000013B4] Table ReadTrace.tblUniqueBatches: loaded ~445 rows
05/10/10 17:13:26.225 [0X000013B4] Table ReadTrace.tblUniqueStatements: loaded ~0 rows
05/10/10 17:13:26.225 [0X000013B4] Table ReadTrace.tblUniquePlans: loaded ~0 rows
05/10/10 17:13:26.226 [0X000013B4] Table ReadTrace.tblUniquePlanRows: loaded ~0 rows
05/10/10 17:13:26.241 [0X000013B4] Table ReadTrace.tblBatches: loaded ~4355 rows
05/10/10 17:13:26.242 [0X000013B4] Table ReadTrace.tblStatements: loaded ~0 rows
05/10/10 17:13:26.243 [0X000013B4] Table ReadTrace.tblPlans: loaded ~0 rows
05/10/10 17:13:26.244 [0X000013B4] Table ReadTrace.tblPlanRows: loaded ~0 rows
05/10/10 17:13:26.257 [0X000013B4] Table ReadTrace.tblInterestingEvents: loaded ~3 rows
05/10/10 17:13:26.258 [0X000013B4] Table ReadTrace.tblConnections: loaded ~0 rows
05/10/10 17:13:26.262 [0X000013B4] WARNING: One or more warning conditions exist that may affect the quality of the analysis data.  See RMLDB.ReadTrace.tblWar
ngs table and the ReadTrace log for complete details.
05/10/10 17:13:26.269 [0X000013B4] Indexing tables...
05/10/10 17:13:27.413 [0X000013B4] Doing post-load data cleanup...
05/10/10 17:13:27.863 [0X000013B4] Computing partial aggregates...
05/10/10 17:13:28.977 [0X000013B4] Data load completed.
05/10/10 17:13:28.979 [0X000013B4] Using execution path: c:\Program Files\Microsoft Corporation\RMLUtils
05/10/10 17:13:28.980 [0X000013B4] Launching [c:\Program Files\Microsoft Corporation\RMLUtils\Reporter.exe]
05/10/10 17:13:29.253 [0X000013B4] *******************************************************************************
* ReadTrace encountered one or more WARNINGS. A warning condition typically   *
* continues processing with reduced functionality, but the ReadTrace output   *
* may be adversely affected. Review the log file for details.                 *
*******************************************************************************
05/10/10 17:13:29.324 [0X000013B4]
 

Les deux warnings indiquent juste qu’il va manquer certains évènements, notamment les évènements pour pouvoir faire un replay dans Profiler.  A la fin du chargement, l’application ‘Reporter‘ est lancée et permet de visualiser les informations de la trace:

Ensuite, il est assez simple de naviguer dans l’interface et de visualiser l’information agrégée, par exemple en cliquant sur ‘Unique Batches’:

… et de repérer les requêtes consommatrices par critère (coût CPU, I/Os, durée), et visualiser le plan (si pris dans la trace):

Dernier épisode, on verra OSTRESS et ORCA, et les alternatives à SQLDIAG+RML Utilites: PSSDIAG, SQL Nexus, SQLH2, Data Collector, les reports SSMS.

A+ David B. (avec la collaboration de Martial LUCAS. )

lrwxrwxrwx 1 root root 4 2008-07-09 12:41 /bin/sh -> bash

Continuez votre lecture sur le blog :



]]> http://blog.capdata.fr/index.php/sqldiag-episode-2/feed/ 0 SQLDIAG (épisode 1) http://blog.capdata.fr/index.php/sqldiag-episode-1/ http://blog.capdata.fr/index.php/sqldiag-episode-1/#comments Fri, 05 Feb 2010 12:10:31 +0000 David BAFFALEUF http://blog.capdata.fr/?p=490 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 de 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 :



]]> http://blog.capdata.fr/index.php/sqldiag-episode-1/feed/ 11