With a couple of good figures for reference, understanding how both traditional undo and IMU work is very straightforward (at least at this abstracted level). Visually comparing Figure 7-16 (traditional undo management) and Figure 7-17 (IMU management), you can immediately see a significant difference. In Figure 7-17, there is the absence of undo segment activity until the transaction commits at time T4. And just as important, the multiple IMU nodes have been consolidated (not deallocated and officially called collapsed) into a single undo segment buffer 310. Here, I will walk you through this process.

Using Figure 7-16 as our reference, let's take a close look at how traditional undo management works.

* Time T2: A transaction changes row 136 from a value of 105 to 110. This results in three key operations. First, the buffer (remember this is done in the buffer cache and not on disk) is changed. Second, the undo must be recorded in an undo segment buffer (remember this is done in the buffer cache and not on disk), and the undo link in buffer 142's interested transaction list (ITL) must point to undo buffer 210. And finally, the redo associated with each buffer's change must be recorded in the redo log buffer. All of these operations are performed in memory, but if a buffer is not in memory, it must first be retrieved from disk, a free buffer found, and the buffer replaced. And of course, all the associated latching, pinning, and memory and IO management must occur.