So as you can see, not only are IMU nodes holders of undo information, but they are also a mapping structure between a changed buffer and the undo. In a way, they intercept the traditional pointer from a buffer (located in the interested transaction list) to the undo block holding the change. When Oracle writes the IMU to the appropriate undo segment and flushes the IMU out of shared pool memory, the undo pointer is changed to point to the undo segment.

IMU structures reside-you guessed it-in the shared pool. As we know, when we care about memory structure access serialization, a control structure is required. Oracle chose to create a number of IMU latches, which, as you will learn soon, allow for the possibility of IMU latch contention.

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.