* Time T3: The transaction once again changes row 136 from a value of 110 to 115. First, buffer 142 is changed. Second, an IMU node is set to reflect the undo associated with the change, and buffer 142's ITL is updated to point to the most current IMU entry. Third, the buffer 142 change is recorded in the redo log buffer. Again, there is no undo buffer change, so no undo is written into the redo log buffer. Notice the chain of undo has been developed entirely of IMU nodes, allowing the transaction to roll back to time T1 and also allowing others to see row 136 at time T1.

* Time T4: The transaction commits. Buffer 142's ITL is changed, and the commit redo entry is written into the redo log buffer for possible recovery needs. A commit triggers the log writer to flush the redo log buffer to the current online redo log.

The IMU nodes are not required to be flushed, but can remain in memory just as long as Oracle wants them to stay. When Oracle does replace or destroy the IMU nodes, buffer 142's ITL entry will simply be changed to point to undo segment buffer 310 instead of the IMU node. But until that happens, any transaction needing a view of buffer 142 before time T4 will reference the IMU! So, the read-consistency operation (which includes buffer copying/cloning and undo application) can be done entirely in memory, using IMU nodes, and without the associated undo block/buffer overhead. A cloned block is still a buffer and must endure the traditional cloning activity of having undo applied, but the undo is coming from the IMU and not undo segment blocks.