| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: delayed logging block cleanout -- Any other comments?
just to add:
a transaction remembers all blocks it modified in Block List (BL) state
objects in memory -- and there is indeed a maximum, which corresponds
(roughly) to 10% of the total number of cache buffers plus 40 blocks. These
BL state objects are used during the fast block cleanout at commit time.
during fast block cleanout, the two statistics "commit cleanouts" and "commit cleanouts successfully completed" are bumped up; the ratio of these two is an indication of the success of the fast block cleanout.
moreover, if a certain BL state object causes "trouble" for whatever reason (there are many reasons why a specific block in cache might fail a fast cleanout attempt) the BL state object is abandoned alltogether, leaving all work to the deferred cleanout mechanism.
Kind regards,
Lex.
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Jonathan Lewis
Sent: Thursday, May 27, 2004 15:34
To: oracle-l_at_freelists.org
Subject: Re: delayed logging block cleanout -- Any other comments?
It's a long time ago, but I remember when I first read Steve's note I didn't think it was complete. My tests had suggested that
On "commit cleanout" an in-memory block could have its ITL updated with the SCN, and this buffer would then be dirty and get written out. The redo for the cleanout was NOT logged, however, so the block on disc was in a state that was NOT described by the redo.
The next transaction to update to that block would generate UNDO that made it look as if the block had previously been cleaned out, so that if the next transaction rolled back, the block would be left in a state that looked as if the previous transaction had done a full clean out. At no stage would there be any REDO generated that would otherwise move the block from 'not cleaned' to 'clean'. (Hence "delayed logging" is a euphemism for "never logged").
Going back to the beginning - if on the commit, the block was not available in memory, then it would not be cleaned at all. On the next read into memory (whether for query only or for update) the block would be cleaned. If the read was query only, the redo generated would be the full cleanout redo, and the block would be dirtied. If the read was for update, the UNDO for the update would be as in the first example - the UNDO that would take the block back to a clean state that had never actually existed.
I don't have an old version to repeat the tests on - but perhaps the change in your results is related to the size of the buffer, and the size of the update which would have some effect on how many blocks would be subject to commit-time partial cleaning, and how many blocks would still be in memory in and cleanable anyway.
Regards
Jonathan Lewis
 |
 |