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!

We now start working on the second ITL, which is associated with transaction 5.2.6. This transaction committed at SCN time 12350, which is after our query began so we need to apply its undo. From the ITL entry, we get the undo block address of 2,70 and access the undo block. The transaction numbers are now compared. Since the transaction has committed, the undo is not guaranteed to be protected. Increasing the undo retention setting keeps the undo around longer, but there is no guarantee.