Discussion :

[dens19]

Bonjour,

Existe-t-il un moyen de réaliser un "OU" logique entre les critères d'un filtre d'une trace prise avec SQL SERVER Profiler ?

Je m'explique je cherche à filtrer des requêtes exécutées sur un serveur pour lesquelles la durée d'exécution est supérieure à 200ms ou le nombre de READ est supérieur à 10000. Pour l'instant la seule solution que j'ai trouvé est de créer 2 traces distincts chacune avec un de ces 2 critères. Si je les associe dans la même trace, un "ET" logique est réalisé entre ces 2 critères pour le filtre du coup les requêtes ne satisfaisant qu'un des 2 critères n'apparaissent pas dans le profiler.

D'avance merci pour votre aide.

[SQLpro]

Non, cela n'est pas possible et couterait trop cher. Imaginez que l'auditeur pénalise la production, ce serait une catastrophe. C'est à vous de faire ce tri dans les données résultant.

A +

[hmira]

Oui, je confirme, ce n’est pas possible directement.
Cependant, ci-dessous 3 solutions dans un ordre décroissant de "mes" préférences :

1 – Pour moi la meilleure solution c’est d’enregistrer la trace dans une table (exemple T_TraceProfiler), puis appliquer des requêtes T-SQL sur cette table de trace pour filtrer les enregistrements. Exemple :

Code :

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

1
2
SELECT * FROM T_TraceProfiler 
WHERE((Reads > 10000) OR (Duration > 200))

2 – Enregister la trace dans fichier (exemple 'C:\Temp\MaTrace.trc’) puis utiliser la fonction fn_trace_gettable pour pouvoir requêter sur le fichier. Exemple :

Code :

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

1
2
3
SELECT * 
FROM ::fn_trace_gettable('C:\Temp\MaTrace.trc’, 0) 
WHERE ((Reads > 10000) OR (Duration > 200))

3 – Lancer 2 instances de SQL profiler chacune avec un filtre différents. La première avec le filtre reads > 10000 et la deuxième avec le filtre duration > 200, puis on consultant les 2 fenêtres vous aurez, en quelque sorte, le résultat des requêtes vérifiant l’un OU l’autre des 2 critères.

A+,

[SQLpro]

Évitez de stocker les données du profiler dans une table.. Cela ne fait que rajouter des dégradation du service SQL et peut conduire à un audit "anormal" du simple fait du profiler.

Placez toujours vos données auditées du profiler dans des fichiers. Vous pourrez effectivement toujours les remettre ultérieurement dans une table en évitant de le faire sur un serveur en production !

A +

[kagemaru]

Par expérience, je préfère stocker dans une/des table(s) d'une instance de test ou carrément une dédiée à la réception des données de profiler, localisée sur un autre serveur. Même la génération de trace-fichier sur le serveur de prod peut potentiellement avoir un impact négatif.

[dens19]

Merci beaucoup pour vos réponses.

Je place ce poste en résolu vu qu'on ne peut pas le faire directement par l'IHM de SQL SERVER Profiler mais que c'est possible via d'autres méthodes que je vais étudier.

Cdlt

[mikedavem]

Bonjour,

Si vous travaillez avec la version SQL Server 2008, vous pouvez éventuellement utiliser les événéments étendues qui permettent de réaliser un "OU" logique dans les critères de filtres (ou prédicats avec les événements étendues).

++

[dens19]

Je travaille malheureusement avec SQL SERVER 2000 mais je vais regarder de plus prés ces événements étendus.

Merci pour votre réponse.
Cdlt.