Profondeur récursive d'un curseur

Version imprimable

18/10/2005, 11h00
Veve44

Profondeur récursive d'un curseur

Bonjour,

Quelqu'un saurait-il me dire ce que signifie la profondeur récursive d'un curseur donné par l'utilitaire TKPROF :?:

Merci par avance !
18/10/2005, 13h19
Jaouad

Bonjour ,
Peux t'on avoir un extrait du rapport

Jaouad
18/10/2005, 15h03
McM

Voic ce que j'ai trouvé sur http://www.dbspecialists.com/present...e_explain.html

Citation:

SELECT table_name
FROM user_tables
ORDER BY table_name

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.01 0.02 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 14 0.59 0.99 0 33633 0 194
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 16 0.60 1.01 0 33633 0 194

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: RSCHRAG [recursive depth: 0]

Notice the text in square brackets concerning recursive depth.
This did not actually appear on the report : I added it for effect.
The fact that the report did not mention recursive depth for this statement indicates that it was executed at the top level.
In other words, the application issued this statement directly to the database server.
When recursion is involved, the TKPROF report will indicate the depth of the recursion next to the parsing user.

Au fait, j'avais oublié de préciser la version d'Oracle : Oracle 8.1.5, au cas où...

Voici un extrait du rapport :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SELECT VALUE   
FROM
 NLS_INSTANCE_PARAMETERS  WHERE PARAMETER = :b1
 
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute  13652      0.24       0.34          0          0          0           0
Fetch    13652      8.04       8.39          0          0          0       13652
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total    27304      8.28       8.73          0          0          0       13652
 
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 37     (recursive depth: 1)

En fait, ma question concernait l'information recursive depth...
Quezako ???

Autre question subsidiaire : on voit 13652 pour le nombre de fetch pour cette requête. Ca veut dire qu'elle a été exécuté 13652 fois ???

Merci

18/10/2005, 16h47
orafrance

oui, 1 fetch/ligne ;)
18/10/2005, 16h47
plaineR

Je ne vais répondre qu'à la question subsidiaire :
oui elle a été exécutée 13652 mais c'est la ligne execute qui t'indique cela

Le fetch t'indique le nombre de lignes extraites.

Pour plus d'informations sur le tkprof :
http://oracle.developpez.com/guide/tuning/tkprof/

D'après mes traces de TKPROF, je dirais que le recursive depth est le niveau à partir duquel le SELECT est exécuté.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
CURSOR c1 IS ...; 
CURSOR c2 IS ...;
BEGIN 
    FOR r1 IN C1 
    LOOP
         SELECT 2 FROM DUAL; -- Recursive Depth = 1
         FOR r2 IN C2
         LOOP
             SELECT 1 FROM DUAL; -- Recursive Depth = 2
         END LOOP;
    END LOOP;
END;

19/10/2005, 10h34
Veve44

Effectivement, ça a l'air d'être ça.

Merci beaucoup !

Concernant la requête qui est exécutée 13652 fois (!!!), quelqu'un saurait-il pourquoi ??
Elle n'apparaît absolument pas dans le code, donc, j'en conclu que c'est Oracle lui-même qui l'exécute pour rechercher le format de date par exemple, ou autre chose...
Mais n'y a-t-il pas moyen qu'il garde en mémoire le résultat une bonne fois pour toute au lieu de l'exécuter autant de fois ??
Ca nous ferait gagner 8 secondes sur le traitement...
19/10/2005, 10h36
Jaouad

Si tu as lu la documentation
est ce que tu as vu si ce n'était pas un ordre récursif ?
19/10/2005, 10h46
orafrance

un TO_DATE par exemple pourrait en effet exécuter cette requête à chaque ligne pour récupérer le format... du moins j'imagine que c'est pas délirant ;)