Discussion :

[Ikebukuro]

Bonjour amis DBAs Oracle !

Je viens vers vous pour avoir vos éclairages une fois de plus à une question qui me pose problème
Si ça se trouve c'est hyper basique mais je sèche.

J'ai une table avec N blocs, j'en modifie un en mémoire et je ne fais pas de Commit.
Un ALTER SYSTEM CHECKPOINT arrive et là que se passe t-il? Tous les dirty blocs sont écrits sur disque dur MAIS le bloc non commité en mémoire ne va pas écraser le bloc commité sur disque dur sinon quid du ROLLBACK après?


Comment est-ce que Oracle gère cela?
1) Il écrit sur le disque dur le deuxième bloc en plus du premier? Pb : le nombre de blocs dans DBA_TABLES (colonne BLOCKS) est faux.
2) Il écrit dans le premier bloc, en plus des données commitées, les données non commitées et il nettoiera le bloc lors du prochain COMMIT ou ROLLBACK? Pb : le nombre de bytes dans la table DBA_SEGMENTS (colonne BYTES) est faux.


Et non, la réponse ne peut pas être : "Quand tu fais un ALTER, un COMMIT est fait d'office donc pas de question".
Oracle nous dit que les ALTER SESSION et ALTER SYSTEME ne font pas partie du DDL donc pas de COMMIT implicite (ALTER DATABASE oui à priori).
https://docs.oracle.com/cd/B28359_01...htm#SQLRF52344
"The DDL statements are:
ALTER ... (All statements beginning with ALTER, except ALTER SESSION and ALTER SYSTEM—see "Session Control Statements" and "System Control Statement")"

[skuatamad]

J'ai une table avec N blocs, j'en modifie un en mémoire et je ne fais pas de Commit.
Un ALTER SYSTEM CHECKPOINT arrive et là que se passe t-il? Tous les dirty blocs sont écrits sur disque dur MAIS le bloc non commité en mémoire ne va pas écraser le bloc commité sur disque dur sinon quid du ROLLBACK après?

Je ne suis pas DBA, je ne peux donc pas répondre directement à ta question.

Mais Oracle écrit sur disque les modifications bien avant de Commit.
En effet conceptuellement une base va Commit bien plus souvent que Rolback, donc pour que le Commit d'une grosse transaction soit performant les données sont écrites sur disque au fur et à mesure et c'est par contre l'opération de Rollback qui sera lente car il faudra annuler toutes les modifications réalisées.

Je cherchais un lien asktom sur le sujet, mais peut être que je l'avais lu uniquement dans son livre.

Lors de mes recherches je suis tombé sur ce post de Franck qui je pense t'éclairera :
Oracle Log Writer and Write-Ahead-Logging

PS: merci pour l'info sur alter session et alter system, je ne savais pas que ce n'était pas du DDL.

[Ikebukuro]

Salut Skuatamad,

Effectivement, tu n'es pas DBA car tu me parles des redo logs alors que moi je parle des données utilisateurs
Néanmoins ce que tu dis est juste, pour les redo logs, qui sont écrits par LGWR au fil de l'eau et bien avant le COMMIT. Pour les données utilisateurs, en revanche c'est un autre process, DBWR qui écrit sur disque dur en général après le COMMIT.

Ah, je vois que je ne suis pas le seul à découvrir que le ALTER SESSION et le ALTER SYSTEM ne sont pas du DDL

[pachot]

Bonjour,
Avec Oracle, les modifications sont toujours faites sur la version courante du block, et sont complètement indépendantes du commit. Le commit, c'est juste un update de la table des transactions pour dire que la transaction est finie, et à partir de quel moment les modifications sont visibles par les autres sessions. Donc la taille sur disque ne change pas.
Ce sont les autres sessions qui lisent les données modifiées qui peuvent se retrouver à faire une copie du bloc pour reconstruire une image sans les modifications non-commitées des autres sessions. Cette copie n'existe qu'en mémoire. Jamais sur disque.
Cordialement,
Franck.

[skuatamad]

Pour les données utilisateurs, en revanche c'est un autre process, DBWR qui écrit sur disque dur en général après le COMMIT.

Pour moi des données utilisateurs peuvent également être écrites au fil de l'eau :
DBWR and Server process

o some REDO and SOME data/rollback blocks have been written. Same as above then -- we rollforward, applying the REDO to the blocks that were not checkpointed -- and then we rollback.

[edit]Je viens de me rendre compte que dans la citation il est mentionnée "that were not checkpointed", du coup ça ne correspond pas vraiment au cas que tu étudies.

[pachot]

Pour moi des données utilisateurs peuvent également être écrites au fil de l'eau :
DBWR and Server process

Oui. les données son écrites de manière complétement indépendantes des commits ou rollback. Le seul lien, c'est que:
- la session qui modifie laisse son identifiant de transaction dans le bloc modifié (ITL = Interrested Transaction List)
- elle écrit les anciennes valeurs dans le UNDO
- lorsqu'elle commit, elle indique le SCN (System Change number) du commit dans la table des transaction du UNDO
Et lorsqu'une session lit un block, elle suit les ITL pour savoir s'il faut appliquer du UNDO pour construire son image consistente.

[Ikebukuro]

Merci Franck pour tes éclaircissements

Je vois une fois de plus que je bloque sur les UNDOs, va savoir pourquoi mais ça reste encore pour moi mystérieux et ça commence à bien me gonfler

[dell68]

Bonjour ,
j'ai consulté le problème, et je t'envoi un cours complet sur cette thématique
http://oracleinaction.com/checkpoints/ avec ceci http://oracleinaction.com/uncommitte...-in-datafiles/
bonne chance

[Ikebukuro]

Hé c'est sympa comme liens, je lirai ça à tête reposée

Un gros merci!