* Time T3: The transaction once again changes row 136. But this time, from a value of 110 to 115. First, buffer 142 is changed. Second, the buffer change is recorded in the undo buffer, and the buffer's ITL is updated to point to the most current undo entry in undo buffer 210. Third, the changes for both buffer 142 and the undo buffer 210 are copied into the redo log buffer. Notice the chain of undo has developed, allowing the transaction to roll back to time T1 and also allowing others to see row 136 at time T1 as well.

* Time T4: The transaction commits. Buffer 142's ITL is changed, reflecting the commit, but for simplicity, I did not show the associated undo. The commit redo entry is written into the redo log buffer for possible recovery needs. The commit triggers the log writer to flush the redo log buffer to the current online redo log.

At time T4, row 136's value is 115. Any access to this block that started at time T4 or later will see a value of 115. However, even after the transaction commits, if a query started before time T4, a read-consistent view of buffer 142 must be created using buffer 142 at time T4 and undo buffer 210. I am leaving out quite a bit of detail (covered in Chapter 6), because the point I want to make here is that all this read-consistency work is referencing standard Oracle undo segment buffers, not highly optimized in memory structures.