Discussion :

[Ikebukuro]

Salut,

J'ai plusieurs questions à vous soumettre sur les Wait Events.

1) Dans le livre "Oracle Database 12c Performance Tuning Recipes", page 161 il est écrit
"Db file scattered read: These are waits incurred by an user process for a physical I/O to return when reading buffers into the SGA buffer cache. The scattered reads are multiblock reads and can occur because of a full table scan or a fast full scan of an index."

Ce que je ne comprends pas c'est : est-ce que la valeur du wait event en secondes représente le temps d'attente pour que les blocs de données soient lus du disque dur vers la SGA ou la durée du travail effectué lors de cette opération? Le process serveur met 10 secondes pour copier les data blocs du disque dur dans la SGA, c'est un vrai travail donc je ne vois pas pourquoi ce serait considéré comme un temps d'attente : on est d'accord?

2) Lorsqu'il y a des Buffer Busy Waits, c'est uniquement lorsque deux process veulent accéder au même data bloc MAIS uniquement pour le mettre à jour (genre : Update ou Insert ou Delete). La règle chez Oracle est : les Readers ne bloquent ni les Readers ni les Writers, les Writers ne bloquent pas les Readers mais seulement les autres Writers. Donc un Full Table Scan sur une table chargée en mémoire qui prend 1 minutes et un update sur tous les rows de cette même table prenant 5 minutes par un autre process ne doit générer aucun temps d'attente.

C'est uniquement si un Writer lock tous les data blocs de la table avec un Update de la table que les autres Writers doivent attendre le COMMIT ou ROLLBACK de la transaction précédente, est-ce bien cela?

Merci pour vos réponses car le sujet est ardu!

[pachot]

Bonjour,

1) Le 'wait time' du wait event correspond au temps elapsed de l'opération. C'est exact que c'est un vrai travail, mais c'est un travail pour l'OS et pas pour la base de donnée. Pendant la durée d'exécution de la lecture physique vers la mémoire, le système travaille, mais le process Oracle est en attente (ce qui veut dire pas d'instruction CPU à exécuter) jusqu'à ce que les données soient là.

En fait les wait events sont une mesure du temps mis à chaque appel système:
Par exemple, lorsqu'il y a un bloc à lire sur disque:
1. on note le timestamp: clock_gettime()
2. on appelle la fonction de lecture: pread()
3. on note le timestamp: clock_gettime()
4. on enregistre le wait event avec la durée entre 3. et 1.

Donc ce temps inclus du temps de travail dans l'OS (CPU en mode kernel), du temps d'attente disque (seek, transfer), peut-être du temps d'attente en runqueue si les CPU sont saturées, ...
Vu d'Oracle, c'est le temps où on attent qu'un bloc lu sur disque soit disponible en mémoire

2) L'idée des lectures qui ne bloquent pas les écritures concernent les transactions et c'est parce que les lectures peuvent lirent une version précédente du bloc. Si elles doivent accéder à la même version du bloc, il y a contention. Ici, 'buffer busy wait' est mesuré lorsqu'une session lit un buffer en mémoire. Et on ne peut jamais lire un buffer qui est en train d'être modifié - sinon on lit quelque chose d'incohérent. Lorsque le premier lit le bloc du disque pour le mettre en buffer cache, ceux qui veulent lire le même bloc doivent attendre que cette lecture soit complète. Ensuite, si une session modifie un bloc, elle l'épingle ('pin') le temps de la modification et les lecture vont attendre que ce soit fini pour l'épingler à leur tour.

Cordialement,
Franck.

[Ikebukuro]

Salut Franck,

Merci pour tes réponses mais je ne comprends pas ta remarque "Si elles doivent accéder à la même version du bloc, il y a contention.". On est d'accord pour dire que si on lit un bloc (SELECT sans clause FOR UPDATE), plusieurs sessions peuvent lire le même bloc et donc la même version. Idem si je veux lire un bloc (SELECT) en cours de modification, alors je lis une version précédente du bloc (principe de la lecture cohérente). Dans ces cas là il n'y a pas de Wait.

En revanche si un user veut modifier un bloc déjà épinglé comme "en cours de modification" par un autre user, alors il doit attendre et ne peut pas lire une version précédente puisque c'est la dernière version du bloc qu'il doit lire, celle en cours de modification par l'autre user et là il y a un Wait.

[pachot]

On parle d'attentes à des niveaux très différents.
Le select for update va attendre sur un wait event 'enqueue' une fois qu'il aura lu le bloc et qu'il aura vu le verrou posé par une autre transaction.
Mais 'buffer busy wait' est au niveau de l'accès au bloc en mémoire, bien avant de le lire où d'y écrire. N'importe que programme doit sérialiser l'accés aux zones de mémoire partagée.

[Ikebukuro]

Allez, un petit up de 2 ans et demi

Si je comprends bien, un exemple de "BUFFER BUSY WAIT" c'est quand deux sessions S1 et S2 veulent mettre à jour des données dans le même bloc B1 mais des rows différents (R1 et R2).
On est d'accord pour dire que S1 doit acquérir un pin sur B1, poser un lock sur R1, faire sa modif et, une fois celle-ci finie (hors COMMIT ou ROLLBACK), relâcher le pin sur B1, permettant à S2 d'acquérir ce pin pour modifier R2.

On est bien d'accord, S2 n'a pas besoin d'attendre le relâchement du lock sur R1 pour modifier R2, même s'ils sont dans le même bloc.

Cette histoire de modification d'un bloc de données, qui ne peut pas se faire de façon concurrente, pour cause d'acquisition de pin, c'est une sorte de verrou posé sur un bloc de données tant que l'opération n'est pas terminée.