Calcul du DBA pour un Full Table Scan?

**Ikebukuro** · 01/12/2016, 13h49

Bonjour tout le monde,

J'ai compris qu'Oracle, lorsqu'il veut lire un bloc de données, vérifie d'abord si celui-ci est dans le database buffer cache avant de le lire sur disque dur (c'est beaucoup plus long dans ce cas). Dans le cas d'un plan d'exécution utilisant un index, on calcule le DBA (Data Block Adress) via les infos du rowid obtenus dans cet index.
MAIS si le plan d'exécution retenu par le CBO est un FULL TABLE SCAN, comment Oracle peut-il faire cette vérification puisqu'il n'a pas de rowid à sa disposition et donc ne peut pas calculer de DBA?

Merci pour vos réponses.

**Waldar** · 02/12/2016, 10h23

Les lignes des tables ont bien des rowid :
https://docs.oracle.com/cd/B19306_01...columns008.htm

**Ikebukuro** · 02/12/2016, 12h43

Merci pour ta réponse Waldar mais cela ne me satisfait pas.

Les ROWID sont au niveau des rows donc il faut lire les data blocs pour avoir ces rowid. Ensuite avec ces rowid je peux calculer le DBA et vérifier si ce bloc est en mémoire MAIS à quoi bon puisque j'ai déjà lu le bloc sur disque dur donc pas la peine de savoir si le bloc est dans la SGA ?

Ce qui serait intéressant ce serait si Oracle faisait une lecture SEULEMENT des ROWID pour chaque rows, qu'il puisse obtenir ces ROWID sans lire les data blocs en entier (comment?). Et dans ce cas là je comprends car avec ces rowid il peut vite définir où lire le bloc : en SGA ou sur disque dur. Mais on est bien d'accord pour dire que si on n'utilise pas d'index ET si Oracle, lors d'un FULL TABLE SCAN, cherche si les data blocs de la table sont en mémoire avant de les lire sur disque dur, je ne vois toujours pas comment il fait.

**pachot** · 02/12/2016, 21h24

Bonjour,
Pour un Full Table Scan oracle a les addresses des extents (blocs contigus) et le high water mark à partir du le segment header, et va donc lire ces plages de blocs du premier au dernier.
Cordialement,
Franck,

**Ikebukuro** · 03/12/2016, 13h43

Bonjour Pachot,

Sauf erreur de ma part, ce n'était pas ma question

Ma question n'est pas comment Oracle fait un Full Table Scan mais comment Oracle détermine si un bloc de données est dans la SGA ou non lorsque le plan d'exécution retenu est un Full Table Scan.

**pachot** · 03/12/2016, 19h17

Ah ok. Facile: il le cherche d'abord dans le buffer cache et s'il ne le trouve pas fait un 'physical read' pour l'y mettre. Dans les deux cas, il connait le rowid du ou des bloc(s).

**Ikebukuro** · 03/12/2016, 19h39

Tu dis "Dans les deux cas, il connait le rowid du ou des bloc(s)."
Peux-tu me dire comment, dans le cas d'un FTS, Oracle connait le rowid ? Il le récupère où? Pas au niveau de la table car il est obligé dans ce cas là de lire les blocs de données donc où?
Serait-il possible qu'Oracle les lise dans l'index de la PK pour tester si tel bloc est en SGA ou non, même dans le cas d'un FTS?

**pachot** · 04/12/2016, 09h17

Il connait les block address car il sait quels extents il doit lire.

**Ikebukuro** · 04/12/2016, 13h05

Je suis désolé mais là je ne comprends pas du tout ta réponse.
Pourrais-tu détailler et dire où Oracle trouve les rowid sans passer par les data blocs?

**pachot** · 04/12/2016, 15h49

Ok, alors une analogie.
Pour trouver une maison dans une rue soit tu connais le numéro de la rue et tu y vas directement (= acces par index) soit tu te fais la rue du début jusqu'à ce que tu tombes sur la bonne maison. Dans les deux cas, tu connais le numéro à la fin.

**Ikebukuro** · 06/12/2016, 08h55

Désolé de le dire ainsi mais on tourne en rond...
A chaque fois tu me dis quelle est la différence entre un accès par index et un FTS.

Ma question est : est-ce que lors d'un FTS, Oracle teste si les blocs de données se trouvent en SGA avant de les lire sur disque dur?

**mnitu** · 06/12/2016, 10h12

La requête est

Code :

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

1
2
 
Select * From emp

pour laquelle le plan d'exécution est un full table scan.

Pour avoir une idée de comment le processus s'amorce supposons qu'il exécute la requête suivante pour obtenir les informations de départ:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 
 
SQL> 
SQL> Select relative_fno, block_id, blocks
  2    From dba_extents t
  3   Where segment_name = 'EMP'
  4  /
RELATIVE_FNO   BLOCK_ID     BLOCKS
------------ ---------- ----------
           1     110336          8
 
SQL>

ce qui permet d'identifier le header block. A partir de celui il calcule l'id du premier block contenant les données. Ainsi il peut calculer le DBA et vérifier si ce block est en mémoire ou pas. Ensuite il lui suffit de poursuivre.

**13thFloor** · 06/12/2016, 10h46

Envoyé par Ikebukuro

Désolé de le dire ainsi mais on tourne en rond...
A chaque fois tu me dis quelle est la différence entre un accès par index et un FTS.

Ma question est : est-ce que lors d'un FTS, Oracle teste si les blocs de données se trouvent en SGA avant de les lire sur disque dur?

Hello,
de toute façon au-dela d'un certains pourcentage (je ne me rapelle plus le nombre) la totalité des blocs va être recherché sur disque (event direct read).
Ex : si le nombre de blocs à lire est > 10% du nombre de blocs du cache data => direct read.

**Ikebukuro** · 06/12/2016, 12h28

Je vous remercie pour vos réponses, j'y vois plus clair

**pachot** · 06/12/2016, 17h05

Envoyé par Ikebukuro

Ma question est : est-ce que lors d'un FTS, Oracle teste si les blocs de données se trouvent en SGA avant de les lire sur disque dur?

Alors la réponse est oui. Il est toujours necessaire de voir si un bloc est en buffer pour savoir s'il a été modifié par une autre session.

**philcero** · 08/12/2016, 04h21

Bonjour,

je ne suis pas tout à fait d'accord avec vous, le moteur Oracle va chercher les blocs de données de deux manières.

Généralement les blocs sont montés en SGA pour toute opération type CRUD à hauteur du besoin.

Mais des blocs sont montés directement en PGA (Pas en SGA) pour toute opération permettant des DIRECT PATH READ (Donc sans passage par la case BUFFER) :

Lecture de blocs depuis le TABLESPACE temporaire (SORT).
Lecture de blocs de tables durant un PARALLEL FULL TABLE SCAN ou un FULL TABLE SCAN sur "grosse table".
Lecture de blocs composant des LOB segments.

Maintenant le lien entre le ROWID et la lecture de bloc, dans le sens opérationnel, n'est pas si évident.

Si j'utilise un accès via INDEX alors l'index va me donner les ROWID à lire (ROWID dans lesquels j'ai toute l'information technique pour aller chercher les blocs dans les DATAFILES), sinon je suis en FTS.

En FTS le dictionnaire va donner au moteur toutes les informations des EXTENTS qui composent la table et il va tous les remonter en SGA ou PGA suivant la catégorisation de la grosseur de la table (Et là les ROWID ne servent à rien en ce qui concerne la localisation et la montée de la DATA en mémoire).

**pachot** · 08/12/2016, 14h33

Bonjour,

Le direct path read que vous décrivez ne change rien au fait que:

Envoyé par pachot

Il est toujours nécessaire de voir si un bloc est en buffer cache pour savoir s'il a été modifié par une autre session.

Avant de faire un direct path read, Oracle doit:
- voir en buffer cache le pourcentage de blocs qui s'y trouve, car c'est un critère de décision
- voir en buffer cache lesquels de ces blocs on été modifiés, car c'est un autre critère de décision
- lancer un checkpoint pour les blocks modifiés avant de pouvoir démarrer un direct read

Le buffer cache (ou le global cache en RAC) est le seul endroit où l'on peut vérifier qu'on a la dernière version d'un bloc. Pour tout bloc qui doit être lu il faut d'abord vérifier s'il est en buffer cache. C'est d'ailleurs son role principal.

Envoyé par philcero

En FTS le dictionnaire va donner au moteur toutes les informations des EXTENTS qui composent la table et il va tous les remonter en SGA ou PGA suivant la catégorisation de la grosseur de la table

Ce ne sont pas des extents qui sont lus mais des blocs. Seuls les blocs qui ne se trouvent pas en buffer cache sont lus sur disque.
Ce n'est pas que la grosseur de la table qui est déterminante mais aussi le % de blocs déjà en buffer cache, et le % de dirty blocs.

Cordialement,
Franck.

**Ikebukuro** · 09/12/2016, 11h58

Merci à vous tous pour vos réponses.

Effectivement, dans DBA_EXTENTS on a un BLOCK_ID et un ID de fichier.
A partir de ces données, Oracle peut calculer le DBA via DBMS_UTILITY.MAKE_DATA_BLOCK_ADDRESS et vérifier si le bloc est en SGA ou non.

MAIS un extent est composé de N blocs et dans DBA_EXTENTS on a seulement l'ID du premier bloc de l'extent, la doc est très claire.

Code :

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

1
2
3
4
DBA_EXTENTS
EXTENT_ID    Extent number in the segment
BLOCK_ID    Starting block number of the extent
BLOCKS         Size of the extent in Oracle blocks

Quid des autres blocs? Où trouver leur ID?
Dans le SELECT suivant, je vois que pour ma table j'ai 17 extents et le numéro du premier bloc_id de chaque extent.
Je pensais qu'Oracle calculerai les numéros des bloc_id manquant en prenant tous ceux entre le block_id de l'extent N et le block_id de l'extent N+1 mais je vois des trous dans la liste des block_id.
128 à 152 : 24 blocs? J'ai créé quelques enregistrements mais ensuite j'ai attendu quelques minutes pour en créer d'autres --> des blocks ID ont été affectés à un autre extent_id d'un autre segment_id?
152 à 160 puis jusqu'à 264 : 8 blocs par extent? J'ai créé des milliers de lignes en une boucle PL/SQL, c'est pourquoi les block_id se suivent par paquet de 8 je pense.
Mais un gros trou de 264 à 384 : combien de blocs liés à ma table parmi ces 120 blocs?

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
SQL> select block_id, blocks, file_id, extent_id from dba_extents where owner = 'HR' order by 1;
 
  BLOCK_ID     BLOCKS    FILE_ID  EXTENT_ID
---------- ---------- ---------- ----------
       128          8          4          0
       152          8          4          1
       160          8          4          2
       168          8          4          3
       176          8          4          4
       184          8          4          5
       192          8          4          6
       200          8          4          7
       208          8          4          8
       216          8          4          9
       224          8          4         10
 
  BLOCK_ID     BLOCKS    FILE_ID  EXTENT_ID
---------- ---------- ---------- ----------
       232          8          4         11
       240          8          4         12
       248          8          4         13
       256          8          4         14
       264          8          4         15
       384        128          4         16

**philcero** · 13/12/2016, 13h24

Pour faire plus simple :

Dans cette partie de la DOC ORACLE, ils expliquent exactement quand un FTS est décidé (Paragraphe "11.2.1.2 When the Optimizer Uses Full Table Scans") :

http://docs.oracle.com/cd/E29505_01/...8/optimops.htm