We begin with the first ITL that is associated with active transaction 7.3.8. Our server process needs to retrieve any undo that has occurred after our query started at SCN time 12330. Transaction 7.3.8's most recent undo can be found by following its ITL's undo block address (UBA) link to undo block 2,45. Our server process must then access undo block 2,45, which requires CBC activity and could also require an IO call along with LRU activity. Once we have access to undo buffer 2,45, we check to ensure we are working with the correct transaction by comparing transaction numbers. Both the data block and the undo block transaction numbers do match (7.3.8), so we're okay. Because the transaction is active, the undo information should not have been overwritten.

Still working with undo block 2,45, the SCN is 12348, which means the undo represents block changes that occurred after our query started at SCN time 12330. Therefore, we apply the undo to our cloned CR buffer, inching it a little further back in time.

Undo block 2,45 also has link to another undo block-2,90. This is referred to as the chain of undo and could possibly go on for quite some time, consuming significant computing resources. Our server process must now access undo block 2,90 (which requires CBC activity and could require an IO call along with LRU activity), and again compares transaction numbers to ensure they match. They do match, and now we examine the SCN. The SCN is 12320, which is before our query started at time 12330. Therefore, we do not apply the undo. If we did apply the undo, our CR buffer would represent a version of block 7,678 at time 12320, which is too early!