Discussion :

[Zidmann]

Bonjour,

J'aimerais savoir s'il est possible, sous une base de données Oracle 10gR2, de déterminer si les informations d'une table sont encore chargées en SGA.

Je sais que lorsque Oracle travaille sur une table donnée, qu'il n'a pas déjà en mémoire RAM, il stocke le contenu de la table et d'autres informations dans la SGA.
Ainsi si dans la requête suivante, on utilise encore cette table, il est inutile d'aller chercher les informations sur le disque dur grâce au cache et on évite ainsi de perdre du temps à recharger les dernières informations.

Comme cette mémoire est limitée et selon les besoins de place de l'instance, la base de données libère certaines informations et il se peut alors que Oracle doive de nouveau charger les informations.

Est-ce que vous connaitriez un moyen pour savoir si des informations d'une table spécifique sont encore stockées ou ont été purgées entre temps.

Merci d'avance de vos réponses

Cordialement,


Zidmann.

[pachot]

Bonjour,

Ca pourrait se voir dans V$BH. Mais quel est le but ?

Et on parle de quelles données ? les blocs de table, les blocs d'index ? les blocs d'undo éventuellement nécessaires pour la lecture consistente ?

Il peut aussi y avoir plusieurs copies du même bloc...

Sinon, un select /*+ full(table) */ count(*) from table après un set autotrace montre le nombre de consistent gets et de physical reads. La différence est ce qu'il y avait déjà en SGA.

Cordialement,
Franck.

[Zidmann]

Bonjour,

Voici plus de détails sur ce que je fais exactement :
J'utilise une table (tA), à un instant T, dans une requête (rA); par conséquent, les informations de cette table nécessaires pour cette requête sont chargées dans la SGA du serveur. Cette même requête (rA) est de nouveau chargée à un autre instant T'(>T). Toutefois entre T et T' plusieurs requêtes SQL ont été exécutées ce qui a probablement nécessitait beaucoup de chargements en SGA et donc la base a du probablement remplacer les blocs initialement chargées en SGA à l'instant T pour la requête rA par ceux des autres requêtes.

Mon objectif est de savoir quels sont les blocs de quelles tables ou de quels indexes sont présents et stockés avant le début du premier test (avant l'instant T) puis de savoir combien de blocs de la table tA et de ses indexes chargés initialement en SGA à l'instant T sont encore présent intacts à l'instant T'.

Les blocs que je cherche à analyser sont des blocs de la table et de son ou ses indexes quand ils existent. Je suis potentiellement aussi intéressé par les blocs d'undo.

Est-ce qu'il y aurait des requêtes SQL qui permettrait de savoir quelles tables ont leurs blocs chargés en SGA avec le nom de la table, le nombre de blocs de la table présents en SGA ?

J'aimerais savoir par contre pour quelle raison Oracle peut décider de faire des doublons des blocs qu'il a chargé en SGA ? Quelle est l'utilité ?

Merci d'avance de vos réponses,

Zidmann

[Mohamed.Houri]

J'aimerais savoir par contre pour quelle raison Oracle peut décider de faire des doublons des blocs qu'il a chargé en SGA ? Quelle est l'utilité ?

Des copies de blocs de données sont faites dans le buffer cache (merci de bien faire la différence entre SGA et buffer cache. La SGA contient entre autres, le cache du code appelé Library cache, et le cache des données appelé le buffer cache dont il est question ici) afin de reconstruire une image consistante correspondant à l’instant T du démarrage de la requête.

Lorsqu’Oracle arrive au bloc de données à retourner pour le client et se rend compte qu’il doit reconstruire une image consistante il :

1. Fait une copie de ce bloc de données dans le buffer cache
2. Prend l’undo correspondant à partir de l’undo tablepsace ---> ** (voir explication ci-dessous)
3. Applique cet undo à cette copie pour retrouver l’image qui correspond au SCN de la requête en question
4. Renvoi enfin cette image consistante au client

Une autre session voulant reconstruire une image consistante du même bloc peut :

1. Soit refaire les 4 opérations ci-dessus dans le cas où l’image obtenue à l’étape 4 a été sortie du buffer cache
2. Soit renvoyer la même image obtenue lors de l’opération 4 si celle-ci se trouve encore dans le buffer cache.
3. Soit utiliser la copie du bloc obtenue lors de l’opération 1 (si celle-ci se trouve encore dans le buffer cache) et lui appliquer l’undo correspondant à son propre SCN (car la copie 4 peut correspondre à une session dotée d’un SCN différent) pour en renvoyer une nouvelle image consistante

** Le bloc initialement lu contient une entrée ITL (Interested Transaction List) qui pointe sur une information appelée ‘’undo record address’’. Cette adresse contient le numéro du fichier, le numéro du bloc et le numéro de l’enregistrement dans le bloc undo. Grâce à ces informations contenues dans le bloc de données nécessitant une lecture consistante, Oracle va directement au bon undo bock( via un db file sequential read) pour rechercher les instructions (update/insert/delete) à appliquer à la copie du bloc dans le buffer cache.

[pachot]

Bonjour,

Est-ce qu'il y aurait des requêtes SQL qui permettrait de savoir quelles tables ont leurs blocs chargés en SGA avec le nom de la table, le nombre de blocs de la table présents en SGA ?

Par exemple:

Code :

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

1
2
3
4
5
6
select o.owner,o.object_name,o.object_type,sum(case when b.status='xcur' then 1 else 0 end) "xcur",sum(case when b.status='cr' then 1 else 0 end) "cr"
from v$bh b left outer join dba_objects o on (b.objd=o.data_object_id)
where b.status in ('cr','xcur')
group by o.owner,o.object_name,o.object_type
order by o.owner,o.object_name,o.object_type
;

J'aimerais savoir par contre pour quelle raison Oracle peut décider de faire des doublons des blocs qu'il a chargé en SGA ? Quelle est l'utilité ?

L'isolation des transactions fait qu'on peut voir des états différents d'un bloc, ce sont les CR (consistent read) de la requête ci-dessus -> description de Mohamed.

Cordialement,
Franck.

[Zidmann]

Bonjour,

C'est exactement ce que je voulais.
Merci de votre aide.

Cordialement,

Zidmann