Datafly.pro

Lors des journées SQL Server de début décembre, j'ai discuté avec notre ami Frédéric Pichaut du support Microsoft sur la disponibilité d'une future version. Il semblerait bien qu'elle existe déjà à usage interne, mais pas encore diffusée au public (on peut se demander pourquoi c'est si long !)

En attendant, je voulais tout de même faire une démonstration de readtrace lors de ma session "Optimisation pour les nuls" et j'ai donc cherché comment résoudre ce problème en attendant la future version compatible.

En fait, c'est juste un tout petit octet qui différencie une trace SQL 2008 de SQL 2012. Et si on modifie cet octet dans le fichier trc, readtrace n'y voit que du feu et traite très bien une trace SQL 2012 en la prenant pour du SQL 2008 !

Plutôt que de refaire ce qui existe déjà, je vous propose le script powershell tout simple que j'ai utilisé lors de ma démonstration. Il est proposé par Gianluca Sartori sur le site spagettidba.com : http://spaghettidba.com/2012/11/08/more-on-converting-trace-files/

## =============================================
## Author:      Gianluca Sartori - @spaghettidba
## Create date: 2012-11-07
## Description: Changes the version information
##              in the header of a SQL Server trace
## =============================================
cls
# Enter your filename here
$fileName = "somefile.trc"
# The version information we want to write: 0x0A = 10 = SQLServer 2008
[Byte[]] $versionData = 0x0A
# The offset of the version information in the file
$offset = 390
[System.IO.FileMode] $open = [System.IO.FileMode]::OpenOrCreate
$stream = New-Object System.IO.FileStream -ArgumentList $fileName, $open
$stream.Seek($offset, [System.IO.SeekOrigin]::Begin);
$stream.Write($versionData, 0, $versionData.Length);
$stream.Close()

Pour rappel de ce que sait faire readtrace :

Readtrace permet de traiter les fichiers de charge de travail (.trc) générés par SQL Profiler en les chargeant dans une base de données et de répondre à des questions du type :

- Quels sont les utilisateurs, les applications, les bases de données qui consomment le plus de ressources et quelles sont les requêtes qui en sont responsables ?

Readtrace normalise les requêtes en remplaçant les paramètres par des chaînes génériques.
Par exemple, les requêtes :

    SELECT * FROM table1 WHERE name='Tom' 
    SELECT * FROM table1 WHERE name='Mary' 

sont bien traitées comme une seule et même requête et leur charge de travail est additionnée.
On sait donc ainsi identifier facilement quelles sont les requêtes qui sont coûteuses en charge de travail parce qu'effectuées de nombreuses fois (alors qu'elles sont peu significatives individuellement).

L'intérêt de readtrace est en plus de nous fournir de jolis rapports (merci SSRS viewer) :

Bonne analyse de traces...!