Statspack, plan d'exécution bizarre avec Scan Index APRES accès table

Version imprimable

14/12/2021, 10h51
Ikebukuro

1 pièce(s) jointe(s)

Statspack, plan d'exécution bizarre avec Scan Index APRES accès table

Rebonjour les experts Oracle :D
Dans le plan d'exécution ci-dessous, j'ai la désagréable impression que les étapes 14 et 15 sont inversées ou mal affichées.
J'ai effacé les noms des objets pour des raisons de confidentialités (absence de l'INSERT aussi) mais l'index en ligne 14 est l'index associé à la PK de la table de la ligne 15.
Quand on regarde leur indentation, la ligne 14 doit être exécutée avant la 15, l'opération 14 étant la fille de l'opération 15.
Le pb c'est que l'affichage ne suit pas ce qui est fait pour les opérations 8 et 9, 10 et 11, 12 et 13 :aie::aie:

A noter que ce plan d'exécution lit 1Go sur le disque dur et 1To en mémoire, soit un rapport de 1 000... est-ce que les deux sont liés?

Dernière question : la ligne 7 fait un sort et n'a besoin que de 10Mo et pas 10Go pour s'exécuter en mémoire?
Pièce jointe 610186

Un GROS GROS merci pour votre aide.

Hello

C'est l'effet de la transformation appelée NLJ_BATCHING (Nested Loop Join Batching)

https://docs.oracle.com/cd/B28359_01...s.htm#BABFCIAI

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SQL> select * from t1 where id in (select id from t2 where x1 = 17335) order by id  ;
 
Plan hash value: 250297636
----------------------------------------------------------------------------------------
| Id  | Operation                      | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |       |       |       |   255 (100)|          |
|   1 |  NESTED LOOPS                  |       |   100 | 13100 |   254   (1)| 00:00:01 |
|   2 |   NESTED LOOPS                 |       |   100 | 13100 |   254   (1)| 00:00:01 |
|   3 |    SORT UNIQUE                 |       |   100 |  1000 |   103   (0)| 00:00:01 |
|   4 |     TABLE ACCESS BY INDEX ROWID| T2    |   100 |  1000 |   103   (0)| 00:00:01 |
|*  5 |      INDEX RANGE SCAN          | T2_I1 |   100 |       |     3   (0)| 00:00:01 |
|*  6 |    INDEX RANGE SCAN            | T1_N1 |     1 |       |     2   (0)| 00:00:01 |
|   7 |   TABLE ACCESS BY INDEX ROWID  | T1    |     1 |   121 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   5 - access("X1"=17335)
   6 - access("ID"="ID")

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SQL> select /*+ no_nlj_batching(t1) */ * from t1 where id in (select id from t2 where x1 = 17335) order by id  ;  
 
Plan hash value: 1500308460
----------------------------------------------------------------------------------------
| Id  | Operation                      | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |       |       |       |   255 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID   | T1    |     1 |   121 |     3   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                 |       |   100 | 13100 |   254   (1)| 00:00:01 |
|   3 |    SORT UNIQUE                 |       |   100 |  1000 |   103   (0)| 00:00:01 |
|   4 |     TABLE ACCESS BY INDEX ROWID| T2    |   100 |  1000 |   103   (0)| 00:00:01 |
|*  5 |      INDEX RANGE SCAN          | T2_I1 |   100 |       |     3   (0)| 00:00:01 |
|*  6 |    INDEX RANGE SCAN            | T1_N1 |     1 |       |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   5 - access("X1"=17335)
   6 - access("ID"="ID")

Bien à vous
Mohamed

14/12/2021, 15h53
Ikebukuro

Je n'en avais jamais entendu parler... un gros merci à toi Mohamed car cela m'intriguait fortement :D

Il reste deux questions à résoudre; allez messieurs-dames, à vot'bon coeur :lol::lol:
- ce plan d'exécution lit 1Go sur le disque dur et 1To en mémoire, soit un rapport de 1 000... je pensais à un pb de Nested Loop Joins mais chaque jointure utilise un index, et hyper sélectif car sur PK...
- la ligne 7 indique un sort : la taille affichée est bien de 10Mo et non pas de 10Go pour s'exécuter en mémoire?