Discussion :

[mikedavem]

dbaffaleuf >> 01h44 ... insomnie passagère ou bien ?

En fait, je pense que l'explication vient surtout du fait que d'insérer des données directement dans une table pourrait être extrêmement coûteux.

Un thread de gestion de trace est exécuté toutes les 4 secondes lorsqu'une trace est active. Cette trace est responsable de l'écriture des données des buffers utilisés par les providers. Cela permet d'écrire de gros blocs de données sur disque d'un seul coup au lieu d'écrire sur disque à chaque fois qu'un événement est collecté. Cela réduit donc énormément l'impact d'une trace surtout sur un serveur extrêment chargé.

Si l'on permet d'écrire dans une table directement (un provider dédié donc), on aurait un souci majeur : pour une table l'écriture avec de gros blocs de données n'est pas supporté. Celle-ci s'effectue ligne à ligne. Imaginez donc si le nombre d'événements à écrire devient très important on aurait quelques problèmes majeurs :

Le buffer utilisé par le provider pourrait rapidement être saturé du fait de l'insertion ligne à ligne dans la table. Certaines événéments ne seraient donc plus tracés et même si l'on empêchait cette perte d'événements, cela pourrait engendrer un certain nombres de verrous sur la table.

Je pense que c'est la raison pour laquelle un tel provider n'existe pas pour une trace serveur.

++

[dbaffaleuf]

dbaffaleuf >> 01h44 ... insomnie passagère ou bien ? ++

Non pas d'insomnies. Juste du boulot.

[FMJ]

Si je comprends bien, cette limitation n'est pas levée avec SQL 2008 ?
Enfin, ce qui est tout de même bizarre pour un risque de perf ou que les logs ne suivant pas, c'est que la fonction est autorisée avec un paramétrage manuel mais pas via un script.


mikedavem
Par contre, j'ai effectivement pensé à appliquer ta méthode, mais le Profiler ne propose d'enregistrer dans un fichier qu'avec le format .trc. Qui n'est pas au format texte, donc inutilisable en dehors de l'application.
Tu l'utilisais comment ce fichier de trace ?

[FMJ]

Ce qui m'agace, c'est qu'il suffirait que le Profiler offre la clause OU dans son Filtre avant capture, et que dans les Logs, les erreurs entraînant une erreur soit identifiées (par exemple au niveau du champs "Success") pour éviter tout ce binz.

C'est pourtant pas la mer à boire !!!!!!!!

[kagemaru]

Merci pour vos explications. Un doc intéressant pour faire ce programme en .NET :

http://msdn.microsoft.com/en-us/library/ms345134.aspx


Pour FMJ,

Tu l'utilisais comment ce fichier de trace ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT *  INTO TABLE FROM :: fn_trace_gettable (N'z:\monfichiet.trc', 1)

[mikedavem]

Si je comprends bien, cette limitation n'est pas levée avec SQL 2008 ?

Avec le profiler non mais avec les événements étendues oui
Elsuket et moi même préparons un article à ce sujet.

Par contre, j'ai effectivement pensé à appliquer ta méthode, mais le Profiler ne propose d'enregistrer dans un fichier qu'avec le format .trc. Qui n'est pas au format texte, donc inutilisable en dehors de l'application.
Tu l'utilisais comment ce fichier de trace ?

kagemaru a répondu à ta question. En utilisant la fonction ::fn_trace_gettable tu peux effectivement importer ce que tu veux dans une table.

++