Discussion :

[kamalito]

effectivement v$session_wait c 'est bien mais ca demande d'être présent , un peu moins pour session_event

Dans le TKprof on voit déjà les requêtes qui mettent du temps, simlement elles sont bien crites et leur plan d'exécution est très bien. Que pourrions nous voir dans les StatPack (les fameuses Wait event) et quelles seraient les actions ?
Merci

[Jaouad]

Dans le statspack , il y a les waits events mais également toutes les requêtes les plus gourmandes notamment lecture de block , I/O

que tu peux retrouver grace à leur hash value

Statspack et Tkprof n'ont effectivement pas le même finalité mais si ils ont des informations qu'y se recoupe

Jaouad

[kamalito]

Dans le statspack , il y a les waits events mais également toutes les requêtes les plus gourmandes notamment lecture de block , I/O

que tu peux retrouver grace à leur hash value

Statspack et Tkprof n'ont effectivement pas le même finalité mais si ils ont des informations qu'y se recoupe

Jaouad

Je saisis ben tous ce que tu m'écris, simplement je voudrais qu'on puisse me dire exactement ce qu'il faut faire quand on trouve une requête dite gourmande mais qui nous semble très bien écrite ! ?

merci

[bouyao]

en premier il faut voir :

Top 5 Timed Events puis ce qui suit dant event

[Jaouad]

lorsque tu constate qu'une requête consomme enormément de bloc il faut se poser quelques quesyions pour déterminer si une requête et bien optimisé ou pas :

- Combien raméne t'elle de lignes ?
- Quelles est l'explain plan ?
- Voir en fonction de l'explan plan si une étape du plan ne donne pas trop de lignes à l'étape supéririeur ( index ou jointure foireuses ) : En effet ce n'est pas parce que une requête passe par un index que celui est optimisé peut être qu'il n'est pas assez selectif ou restrictif


jaouad