[Noyau] Accès aux blocks dans le buffer cache

Bonjour a tous,
Je voulais savoir comment se fait la recherche de donnees dans le database buffer cache. Est ce que Oracle fait l'identification du/des block(s) de donnees dans lequel il va chercher les donnees ou il fait parcourir tous les blocks presents dans le database buffer cache? Une autre question, comment Oracle fait la correspondance entre les blocs de donnes qui sont sur le disque et ceux presents en database buffer cache:c-a-dire avant l'execution d'une requette comment il peit decider que le bloc de donnees concerne est charge ou pas en memoire?

Merci d'avance ...

Bonjour Gtaoufik et bienvenue sur le forum Oracle :D ,
La recherche dans le database buffer ne se fait pas en parcourant ce dernier. En effet Oracle sait de part l'adresse ou son trouve son block, tout comme une recherche sur disque.En effet imaginez vous si oracle devait parcourir tout le database buffer pour retrouver son block , les performances seraient desastreuses pour des SGA énormes ( cela encore plus si Oracle doit aller chercher sur le disque la data).

Rappellons d'ailleurs qu'un block de données est soumis à deux régles pour rester en mémoire: Le LRU ( Last recently used ) et depuis la 9i Oracle à introduit le principe de Touch Count.

Un bloc n'est pas soit lu sur le disque soit sur dans le buffer , mais toujours à partir du buffer. Si ce dernier n'est pas dans le buffer oracle le monte dans le buffer puis le lit.Une liste existe la LRU list qui va permettre à Oracle de savoir si la donnée demandé ( indentifié par son ROWID ) est dans le buffer ou pas.

Merci pour l'accueil Jaouad,
Mais avant l'execution de la requette, comment oracle peut determiner (a partir de la requette) l'addresse du block concernee. Est ce qu'il garde par exemple l'information que le bloc X contient le contenu de la table T qui sera interroge par notre requette.
Merci...

Comment un bloc reste t'il en mémoire :

Last recently used (LRU) :

Citation:

---

Oracle maintient une liste avec les blocs de données en mémoire ( data Buffer ). Si un bloc de donnée est utilisé ( select par exemple) alors celui devient le bloc le plus recement utilisé et il est placé de début de liste. Lorsque Oracle a besoin de place dans le buffer cache ( chargement de données dans le buffer cache) il va sortir les blocs les moins utilisés donc ceux qui se trouve en fin de liste.

---

Touch Count :

Citation:

---

Oracle s'est apercu de la limite de son algo puisque un bloc qui n'a pas été utilisé depuis quelques temps ou en fort periode de charge , un bloc peut être sortit du buffer cache mais on peut en avoir besoin dans les instant qui suivent. Oracle , voulant dans ce càs la eviter une lecture physique, a pondéré son algo par le touch count , à savoir chaque fois qu'un bloc de données est utilisé son compteur est incrémenté.Lorsqu' Oracle a besoin de place , il ne va pas forcément sortir celui qui est en fin de liste si son compteur est élevée.

---

Une requête contient plusieurs phases. Dans la phase de parsing Oracle va determiner quel est le bloc de donnée ou la donnée concerné par la requête. IL va à partir de la rowid identifié les données désirés, puis vérifié si ces données sont dans le cache, sinon accées disque pour les remonter dans le cache et enfin lecture.
D'ou l'importance de ne remonter de les données désirés ( par exemple par un index ) et d'avoir un buffer cache bien taillé :wink:

Ce que je peut te dire qu' Oracle utilise un algorithme de hachage pour trouver les données dans le buffer cache.
et si tu veut une explication complete alors il faut connaitre avant :
* L'algorithme de Hachage (tu peut trouver un article complet dans la section algo)
* RDBA
* les listes LRU, LRUW , LRU-P, LRU-XOet CKPTQ
* Les LATChs voir cours de JOUAD

pour ta reponse oracle utilise la paire <RDBA,class> pour identifier les blocs

Merci pour vos réponses.

Pour lire le bloc dont il a besoin, le serveur suit les étapes suivantes :

1. A l'aide d'une fonction de hachage, le serveur commence par vérifier s'il trouve le bloc requis dans le buffer cache. S'il le trouve, il est deplacé vers l'extrémité MRU de la liste LRU. Il s'agit d'une lecture logique ;
en effet, aucune E/S n'a eu lieu. Les autres étapes ne sont pas effectuées, car le processus serveur possède le bloc requis.

Si le bloc est introuvable dans le buffer cache, le serveur doit lire le bloc à partir du fichier de données.

2. Il recherche d'abord une mémoire tampon disponible dans la liste LRU. Les mémoires tampon trouvées lors de l'analyse LRU et qui ont été modifiées par un processus serveur sont placées dans la file d'attente des points de reprise (checkpoint) pour être recopiées sur le disque pendant un point de reprise.

3. Si la taille limite de la file d'attente des points de reprise est dépassée, le serveur signale au processus DBWn de vider les tampons 'dirty" du cache tampons. Si le serveur ne trouve pas de mémoire tampon disponible dans le délai de recherche imparti, il demande au processus DBWn d'effectuer une purge.

4. Une fois qu'il trouve une mémoire tampon disponible, le serveur lit le bloc provenant du fichier de données dans la mémoire disponible du buffer cache de la base. Le processus serveur Oracle éloigne la mémoire tampon de l'exetrémité LRU de la liste. Si le bloc n'est pas cohérent en lecture, le serveur crée une copie cohérente en lecture à partir d'une image du passé.

Citation:

---

Envoyé par bouyao

Si le bloc est introuvable dans le buffer cache, le serveur doit lire le bloc à partir du fichier de données.

---

C'est une lecture physique.

Citation:

---

Envoyé par bouyao

3. Si la taille limite de la file d'attente des points de reprise est dépassée, le serveur signale au processus DBWn de vider les tampons 'dirty" du cache tampons. Si le serveur ne trouve pas de mémoire tampon disponible dans le délai de recherche imparti, il demande au processus DBWn d'effectuer une purge.

---

Ici les deux types d'évènements d'attente à surveiller et qui peuvent amene à un tuning sont :
Cache buffers LRU chain latch
free buffer waits

Dans ce càs , le fait d'augmenter le nombre de buffers est une erreur

Le touch_count a été introduit en 7 en non pas en 9i :oops:

Si il n' a pas toutes les informations :D

Le touch count à été introduit en 8 et non en 7

Effectivement . :oops:

Un petit exemple :

On veut connaitre le numéro de fichier et du bloc de la table DUAL (car il contient une seule ligne)

Code:

---

1 2 3 4 5

SQL> select file_id,block_id from dba_extents where segment_name='DUAL' and owner='SYS';   FILE_ID BLOCK_ID ---------- ---------- 1 2081

---

on va voir le touch count dans le bloc

Code:

---

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 37 38 39 40 41 42

SQL> select tch from x$bh where file#=1 and dbablk=2081;   TCH ---------- 1   SQL> select * from dual;   D - X   SQL> select tch from x$bh where file#=1 and dbablk=2081;   TCH ---------- 1 1 SQL> select * from dual;   D - X   SQL> select tch from x$bh where file#=1 and dbablk=2081;   TCH ---------- 2 1 SQL> select * from dual;   D - X   SQL> select tch from x$bh where file#=1 and dbablk=2081;   TCH ---------- 3 1

---

on voit bien que TCH s'incremente mais pas la premiere fois pourquoi ? (peut être le bloc n'etait pas encore dans le buffer cache)
ce qui m'etonne c'est pourquoi la première fois j'avais une seule ligne pour la table x$bh et maintenant j'ai deux lignes ?

EDIT : oracle 10R2

Parce qu'il peut exister plusieurs entrée pour un bloc et un file_id , dissocié par leur ADDR , mais c'est byzarre la table Dual ( est ce une spécificité de la 10g ?)

Code:

---

1 2 3

SELECT FILE# , dbablk , COUNT (*) FROM x$bh HAVING COUNT (*) > 1 GROUP BY FILE# , dbablk ;

---

Est ce que cela sous entenderait qu'un bloc peut être présent deux fois , et en même temps, dans le buffer cache 8O ?