Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

332
CHAPTER 9 ■ REDO AND UNDO
When I ran the processes concurrently again, both ran to completion. The undo tablespace’s
data file grew this time, because it was allowed to and the undo retention I set up
said to:
ops$tkyte@ORA10G> select bytes/1024/1024
2 from dba_data_files
3 where tablespace_name = 'UNDO_SMALL';
BYTES/1024/1024
---------------
11
So, instead of receiving an error, we completed successfully, and the undo grew to be large
enough to accommodate our needs. It is true that in this example, getting the error was purely
due to the fact that we read the table T via the index and performed random reads all over the
table. If we had full scanned the table instead, there is a good chance we would not get the
ORA-01555 in this particular case. This is because both the SELECT and UPDATE would have been
full scanning T, and the SELECT could most likely race ahead of the UPDATE during its scan (the
SELECT just has to read, but the UPDATE must read and update and therefore could go slower).
By doing the random reads, we increase the probability that the SELECT will need to read a
block, which the UPDATE modified and committed many rows ago. This just demonstrates the
somewhat insidious nature of ORA-01555. Its occurrence depends on how concurrent sessions
access and manipulate the underlying tables.
Delayed Block Cleanout
This cause of the ORA-01555 error is hard to eliminate entirely, but it is rare anyway, as the circumstances
under which it occurs do not happen frequently (at least not in Oracle8i and
above anymore). We have already discussed the block cleanout mechanism, but to summarize,
it is the process whereby the next session to access a block after it has been modified
may have to check to see if the transaction that last modified the block is still active. Once the
process determines that the transaction is not active, it cleans out the block so that the next
session to access it does not have to go through the same process again. To clean out the
block, Oracle determines the undo segment used for the previous transaction (from the blocks
header) and then determines if the undo header indicates whether it has been committed or
not. This confirmation is accomplished in one of two ways. One way is that Oracle can determine
that the transaction committed a long time ago, even though its transaction slot has
been overwritten in the undo segment transaction table. The other way is that the COMMIT SCN
is still in the transaction table of the undo segment, meaning the transaction committed a
short time ago, and its transaction slot hasn’t been overwritten.
To receive the ORA-01555 error from a delayed block cleanout, all of the following conditions
must be met:
• A modification is made and COMMITed, and the blocks are not cleaned out automatically
(e.g., it modified more blocks than can fit in 10 percent of the SGA block buffer cache).
• These blocks are not touched by another session and will not be touched until our
unfortunate query (displayed shortly) hits it.