Discussion :

[tux2005]

Bonjour,

Je suis sous Oracle 9i. Je n'arrive pas à comprendre les résultats suivants obtenus suite à un Tkprof sur une trace d'un traitement batch :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SELECT code
    FROM dossier
    WHERE dosid = :b1
 
call       count       cpu     elapsed       disk      query    current   rows
------  -------- ---------- ---------- ---------- ----------  ----------
Parse     1            0.00       0.00        0           0            0           0
Execute  516265    7.73      7.72        0            0            0           0
Fetch     516265    4.97      4.89        1123    1548795     0       516265
------- ------  -------- ---------- ---------- ---------- ----------  
total   1032531     12.70      12.61       1123    1548795          0      516265
 
Rows     Row Source Operation
-------  ---------------------------------------------------
 516265  TABLE ACCESS BY INDEX ROWID DOSSIER 
 516265   INDEX UNIQUE SCAN PK_DOSSIER

On voit que le fecth est répété 516265 fois (Count) et que le nombre de ligne retourné est 516265 (Rows) ma question est la suivante pour l'interprétation :

1. est ce que je dois comprendre qu'1 fetch me ramène 1 ligne ?
2. ou bien chaque fecth me ramène 516265 lignes ?

Mon doute provient de l'explain qui indique également 516265 lignes de retournées... donc je pencherais plus pour la réponse 2...

Si je suis dans le cas 1, mon traitement est très lourd car il parcourt 1548795 query pour récupérer 1 ligne et je dois donc essayer d'améliorer ce traitement.
Si je suis dans le cas 2, mon traitement est pas trop mal puisqu'il parcourt 1548795 query pour ramener 516265 lignes et on voit sur l'explain plan qu'il utilise bien un index...


je vous remercie par avance pour votre aide

Bonne journée
Tux

[rouardg]

Bonjour,

Tu es dans le cas 1.
Ta requête est exécutée 516256 fois. A chaque exécution, il y a un fetch qui te ramène une ligne. Ceci est normal puisque tu vas chercher le dossier suivant son id qui est unique (INDEX UNIQUE SCAN PK_DOSSIER).

Au niveau du plan d'exécution, il faut en fait penser que l'utilitaire Tkprof aggrège les résultats.

En effet, lorsque tu mets ta session en mode trace, chaque requête qui est exécutée figure dans le fichier de trace. Ce fichier doit donc contenir 516256 fois cette requête.

Ensuite, ce fichier est passé par la moulinette de TKPROF, qui par défaut aggrège les résultats. C'est pour cela que tu ne vois plus qu'une fois ta requête. Au niveau du plan, les résultats sont aggrégés.

[tux2005]

Merci pour ta réponse !

En lisant ton message et donc que je suis dans le cas 1, je me souviens maintenant qu'effectivement il faut faire attention et diviser toutes les valeurs (cpu elapsed disk query current rows) par le nombre d'executions (count)... sauf erreur de ma part.

Dans le cas ci-dessous, on a donc 1 fetch = 1 ligne retournée = 3 blocks lus
(3 => 1548795/516265).
La requête est donc pas si mal que ça.

Je m'apercois que de faire mon tkprof avec les options suivantes :

Code :

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

(prsela, exeela, fchela)

n'est pas forcément une bonne solution pour réperer les requêtes qui coutent le plus cher...
Il faut que je rajoute l'option fchcnt (nbre d'appels de fetch) pour que je récupère les requetes qui sont coûteuse mais pas parceque je les exécute un grand nombre de fois... car ça je ne pourrais rien y faire.

As-tu un conseil pour repérer rapidement les requêtres 'réellement' coûteuses dans une trace?

Merci pour tes éclaircissements rouardg.

Tux

[tux2005]

en fait dans mon cas, il y a t-il un moyen pour que le tkprof me ramène un tri par ordre croissant de nombre d'exécutions ?

car pour l'instant toutes les options me présentes les résultats par ordre décroissant...

or je voudrait pour un nombre réduit d'éxécution la requete la plus couteuse...


je vous remercie pour votre aide.