So, IMU nodes provide all the undo-related capabilities without any of the standard segment management overhead. Brilliant!

Another amazing feature of IMU is when it comes time to transform the in-memory undo into undo segment format, multiple IMU nodes can be collapsed or consolidated to minimize the amount of undo segment data. For example, suppose a transaction updates a buffer at three different times: T1, T2, and T3. Using traditional undo segments, this will cause three changes to the same buffer, complete with all the associated overhead with changing a buffer. With IMU in use, while three IMU entries are created, when it comes time to update the actual undo segment buffer, the three IMU nodes are collapsed to reduce the amount of undo. Plus the IMU nodes can remain in memory, so read-consistent queries can access the IMU nodes directly, instead of working with the traditional undo segments.

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.