Discussion :

[Ikebukuro]

Bonjour,

Je voudrais savoir à quoi correspondent exactement les recursives calls quand on fait un Autotrace.
J'ai lu que ça correspondait au parsing de la requête mais je ne suis pas plus avancé : c'est N requêtes sur N tables différentes pour voir si la requête est OK (structure de la table, droits d'accès...), c'est N appels dans la Shared pool pour essayer de trouver un ordre SQL identique et récupérer un plan d'exécution déjà traité...?

J'aimerais bien avoir le détail de ce qui se passe lors de cette opération car cet indicateur est généralement très élevé.


Exemple où on a un seul recursive call; donc Oracle sait faire simple quand il veut

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
SQL> set autotrace on
SQL> select 1 from dual;
         1
----------
         1
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1388734953
 
-----------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------
|   0 | SELECT STATEMENT |      |     1 |     2   (0)| 00:00:01 |
|   1 |  FAST DUAL       |      |     1 |     2   (0)| 00:00:01 |
-----------------------------------------------------------------
 
 
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        519  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

Exemple où le nombre est très élevé par rapport à l'ordre SQL proprement dit : 73 recursives calls.

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
SQL> SELECT 1 FROM EMP;
1
-
1
...
107 rows selected.
 
 
Execution Plan
----------------------------------------------------------
Plan hash value: 2196514524
 
-------------------------------------------------------------------------
| Id  | Operation        | Name         | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT |              |   107 |     1   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | EMP_EMAIL_UK |   107 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------
 
 
Statistics
----------------------------------------------------------
         73  recursive calls
          0  db block gets
        127  consistent gets
          2  physical reads
          0  redo size
       2379  bytes sent via SQL*Net to client
        600  bytes received via SQL*Net from client
          9  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        107  rows processed

Un autre exemple encore plus frappant : le nombre de 1161 est faramineux en regard du SELECT!

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
SQL> select * from TEST where SUBSTR(LIB, 1, 1) = '2';
        ID LIB
---------- --------------------
     21093 2 LIB PART DEUX
     21100 2 LIB PART DEUX
     21107 2 LIB PART DEUX
11111 rows selected.
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1357081020
 
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1000 | 21000 |   137   (1)| 00:00:02 |
|*  1 |  TABLE ACCESS FULL| TEST |  1000 | 21000 |   137   (1)| 00:00:02 |
--------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter(SUBSTR("LIB",1,1)='2')
 
Statistics
----------------------------------------------------------
       1161  recursive calls
          0  db block gets
       1991  consistent gets
        530  physical reads
          0  redo size
     245951  bytes sent via SQL*Net to client
       8663  bytes received via SQL*Net from client
        742  SQL*Net roundtrips to/from client
         27  sorts (memory)
          0  sorts (disk)
      11111  rows processed

[dell68]

Il faut générer une trace de la requête éxécutée au niveau d'une session, voici les étapes :

sous le schema qu tu vas lancer ta requête :

Code :

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

1
2
3
4
 
alter session set tracefile_identifier='xxxxxx' ;
alter session set events '10046 trace name context forever, level 12';
alter session set sql_trace=TRUE ;

Dans la même session, tu lance ta requête à tracer

Code :

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

1
2
 
alter session set events '10046 trace name context off' ;

Tu regarde au nievau de l'OS, s'il ya un fichier de trace nommé 'xxxxxx'

et ensuite tu lance le programme TKPROF qui va te formater ce fichier lisiblement avec TOUTES les appels récursifs

sous OS :

Code :

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

1
2
 
tkprof  nom_fichier_xxxxx.trc  nom_du_fichier.prf   sys=YES

avec l'option sys=YES, tu auras beaucoups de BLABLABLABLA sur les requêtes recursifs, dans le rapport tkprof !

Bonne chances !

[Ikebukuro]

Merci pour la réponse, je regarde ça de suite.

OK, c'est super chaud à lire même formaté avec TKPROF :-)

J'ai fais un autre ordre SQL car le premier faisait juste un recursive call donc pas intéressant.
Merci beaucoup pour ton aide!