Discussion :

[nax71]

Voila ma question.
Supposons une base avec 3 groupes de fichiers redo log (1 membre par grp pour faire simple).
Je commence une transaction longue (des INSERT/UPDATE/DELETE mais pas de COMMIT)
Le premier fichier redo_log se remplit, Oracle switch, le 2 se remplit aussi, Oracle switch pour le troisième.
Comme il n’y a pas eu de COMMIT, DBWn n’écrit rien dans les fichiers des données, tout reste dans les fichiers de REDOLOG.
Que-est ce qui se passe si le troisième se remplit aussi etant donnée que la transaction n'est pas finie (pas de COMMIT) ?

Merci pour vos réponses.

[orafrance]

c'est pas dans les redos mais dans le undo tant qu'il n'y a pas de commit

Sinon : http://mbouayoun.developpez.com/archredo/ et http://mbouayoun.developpez.com/fichredo/

[pachot]

Bonjour,

Si si, dbwr écrit les blocs, que les changements soient commités ou non. Si ce n'était pas le cas, le commit serait très très long !

dbwr les écrit au fur et à mesure en aprticulier pour libérer de la place en buffer cache.

A chaque log switch, un checkpoint est lancé, ce qui force à écrire sur disque les blocs modifiés (et là encore, que les changements soient commités ou non), sans attendre que ce soit terminé.

Par contre, quand le troisième est rempli, avant d'écraser le premier, lgwr s'assure que tous les blocs qui sont protégés par ce premier fichier de log soient écrits sur disque. C'est à dire, il faut que le premier checkpoint soit terminé.
Sinon, il attend, on voit passer 'checkpoint not complete' dans l'alert.log, et la session va attendre sur 'log file sync'. C'est un problème de performance si ça arrive trop souvent.

Donc, avec ça, les redo log sont toujours suffisants pour récupérer les modifications faites en mémoire (buffer cache) en cas de crash de l'instance.
-> soit les modifs on été écrites dans les datafiles, et là plus besoin de redo
-> soit elles sont seulement en mémoire, et il y a toujours le redo nécessaire pour les refaires

Cordialement,
Franck.

[nax71]

Merci pour vos reponses.

Je ne suis pas d'accord avec toi orafrance (sauf votre respect vu ton profil).
Je m'explique, si j'ai bien compris le contenu des fichiers redo n'est pas lie au COMMIT (bien qu'il le contient).
ORACLE écrit bien dans les redo files quand on a 1/3 dur redol log buffer plein ou s'il y a plus d'1M des données, etc. , même sans COMMIT
Le undo c'est pour revenir en arrière malgré un COMMIT. Le redo c'est pour une récupération suite à un possible plantage. (Je me trompe ?).

En ce qui concerne la réponse de pachot.
Elle est très claire mais d’après ma compréhension les data files contient que des données valides donc qui on eu un COMMIT.
En supposant que le 3eme redolog est plein et que le premier redolog est écrasé (tjr pas COMMIT) et que des données non comites sont dans les data file. S'il y a un plantage SMOn n'a plus de moyen de revenir en arrière (SMON lit que le redo log) et les datafiles ne retient pas l'historique des modifications.

Cdt,

[pachot]

Bonjour,

J'insiste: les datafiles contiennent des données non commitées.

S'il y a plantage, les redo sont lus pour arriver au même état que avant le plantage: il récupère tous les datafiles (incluant les undo).
Et ensuite, smon va rollbacker les transactions qui étaient en cours, en utilisant les undo.

Un recovery, c'est deux étapes:
-> rollforward pour rejour les modifications depuis le checkpoint
-> rollback des transactions qui n'étaient pas commitées

Cordialement,
Franck.

[Mathias44]

Bonjour,

Il se trouve qu'orafrance a également raison
LGWR journalise les modifications de blocs dans les redologs, et comme l'explique bien pachot, une entrée du redolog n'est pas écrasée tant que le bloc n'est pas physiquement écrit sur disque. Or, tant que la transaction n'est pas commitée, l'image avant est stockée dans les blocs undo, qui sont également écrits sur disque par le DBWR ; l'entrée correspondante dans le redolog peut donc être écrasée.

[nax71]

Avec le rajout de Mathias ca devient plus claire.

Pour lier au cas réel.
On une base qui analyse des packages fichiers et fait des statistiques.

Il y a environ 50 analyses par jour (~10 000 fichiers analysés par jour).
L'analyse et le remplissage de la base sont automatiques (des scripts java).

Malgre cette activité statspack reporte maximum 0.4 transactions par secondes.
Statspack est lance en job avec 1 snapshot par heure.
Et pendant les periodes d'analyse on switch de log file 1 fois par minute (1 log file a 50M)

Je trouve assez peux ce qui doit s'expliquer par tres peux de commit.
Je n'ai pas access a l'applicatif Java.


merci pour vos réponses.