Discussion :

[Ikebukuro]

Amis DBA bonjour,

Je sèche depuis ce matin sur la signification des colonnes BUFFERS et READS dans un plan d'exécution.
La doc Oracle ne mentionne rien, pouvez-vous me dire à quoi cela correspond précisément? Je précise "précisément" car la colonne BUFFERS augmente parfois de façon bizarre, surtout si je lis des données via un ou plusieurs "user rowid".

Test 1 : un rowid

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
SQL> select /*+ gather_plan_statistics */ * from zztest where rowid = 'AAAUKFAAMAAACRDAAA';
...
 
SQL> select * from table(dbms_xplan.display_cursor(null,null,'iostats last'));
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------
SQL_ID	1kwbmj9ubvzma, child number 0
-------------------------------------
select /*+ gather_plan_statistics */ * from zztest where rowid =
'AAAUKFAAMAAACRDAAA'
 
Plan hash value: 833697196
 
-----------------------------------------------------------------------------------------------
| Id  | Operation		   | Name   | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	   |	    |	   1 |	      |      1 |00:00:00.01 |	    1 |
|   1 |  TABLE ACCESS BY USER ROWID| ZZTEST |	   1 |	    1 |      1 |00:00:00.01 |	    1 |
-----------------------------------------------------------------------------------------------

Test 2 : dix rowid. Deux pour la colonne BUFFERS alors que les ROWID pointent vers le même bloc Oracle selon DBMS_ROWID.

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
SQL> select /*+ gather_plan_statistics */ * from zztest where rowid IN ('AAAUKFAAMAAACRDAAA','AAAUKFAAMAAACRDAAB','AAAUKFAAMAAACRDAAC','AAAUKFAAMAAACRDAAD','AAAUKFAAMAAACRDAAE','AAAUKFAAMAAACRDAAF','AAAUKFAAMAAACRDAAG','AAAUKFAAMAAACRDAAH','AAAUKFAAMAAACRDAAI','AAAUKFAAMAAACRDAAJ');
SQL> select * from table(dbms_xplan.display_cursor(null,null,'iostats last'));
 
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID	f963u8zq3nbbh, child number 1
-------------------------------------
select /*+ gather_plan_statistics */ * from zztest where rowid IN
('AAAUKFAAMAAACRDAAA','AAAUKFAAMAAACRDAAB','AAAUKFAAMAAACRDAAC','AAAUKFA
AMAAACRDAAD','AAAUKFAAMAAACRDAAE','AAAUKFAAMAAACRDAAF','AAAUKFAAMAAACRDA
AG','AAAUKFAAMAAACRDAAH','AAAUKFAAMAAACRDAAI','AAAUKFAAMAAACRDAAJ')
 
Plan hash value: 904234787
 
------------------------------------------------------------------------------------------------
| Id  | Operation		    | Name   | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	    |	     |	    1 |        |     10 |00:00:00.01 |	     2 |
|   1 |  INLIST ITERATOR	    |	     |	    1 |        |     10 |00:00:00.01 |	     2 |
|   2 |   TABLE ACCESS BY USER ROWID| ZZTEST |	   10 |      1 |     10 |00:00:00.01 |	     2 |
------------------------------------------------------------------------------------------------
 
Note
-----
   - statistics feedback used for this statement

Par avance merci pour vos retours

[pachot]

Salut,

BUFFERS, c'est bien comme tu le penses les lectures de blocks, qui s'appelle ailleurs logical reads, buffer_gets, consistent reads,...

Si tu lis plusieurs lignes d'un même bloc, c'est un seul buffer get du moment que c'est dans le même user call (fetch). Mais la session ne peut pas garder le bloc épinglé (pinned) entre 2 appels clients et du coup c'est recompté comme un buffer get à chaque fetch même si on revient sur le même bloc.
Mon hypothèse c'est que tu lances ça depuis sqlplus avec les valeurs par défaut pour ROWPREFETCHSIZE (=1) et ARRAYSIZE (=15) et donc le premier fetch lit 1 ligne -> 1 buffer gets et le fetch suivant lit les 9 lignes suivante, toujours dans le même bloc -> 1 buffer get. C'est le même bloc mais visité 2 fois.
Tu peux jouer avec ces paramètres pour voir la différence.
Tu peux aussi rajouter un ORDER BY -> tout sera lu en 1 fois -> 1 buffer get seulement. Le fetch iront lire dans la workarea en mémoire -> pas plus de buffer gets.

On doit voir ça aussi dans le dump brut de sql_trace vu que chaque ligne FETCH met son nombre de bloc (cr=)

Franck.

[Ikebukuro]

Merci beaucoup Franck,

QU'est-ce que je ferais sans toi