Figure 7-16. How traditional undo segment are used, as well as the various key components (data buffer, undo buffer, redo buffer, and online redo log) change as a transaction progresses

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