* Time T1: For space reasons, time T1 is not shown in Figure 7-17, but it's the same as in Figure 7-16. At time T1, buffer 142 contains row 136, which has a column value of 105.

* Time T2: A transaction changes row 136's value from 105 to 110. This results in three key operations. First, the buffer is changed (no change from traditional undo management). Second, an IMU node is set to reflect the undo associated with the change and the undo link in block 142's ITL points to the IMU node. IMU nodes reside in the shared pool. and they must be accessed using one of the IMU latches. They operate in an LRU algorithm, although Oracle can artificially age the nodes and change IMU memory allocation. Third, the redo associated with buffer 142 change must be recorded in the redo log buffer. Notice that since there was no undo buffer involved (so obviously it was not changed), there is no associated undo buffer redo, and all the potential associated segment management overhead.

* 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.