Whenever an Oracle buffer is changed, the associated change (called a redo vector) is consolidated with other redo vectors to form a single redo entry, and then written into the redo log buffer. Unfortunately, even if an undo segment buffer is changed, its change must also be recorded in the redo log buffer. But since IMU nodes are not undo segments, their changes do not generate redo!7 So, IMU will reduce the amount of redo an instance generates. This impacts all redo-related operations, including, redo creation, copying redo into the log buffer, and writing the buffered redo to an online redo log. If you have throughput-related redo issues, IMU can help.

By default, Oracle provides sessions a transactionally consistent view of the database. While this is a wonderful feature for most business applications, it involves significant overhead. If you recall from Chapter 6, when an undo block is needed but does not reside in the buffer cache, it must be read from disk and placed into the buffer cache. This requires both CPU and IO resources. However, if the undo information is located in an IMU node, the associated read-consistency overhead is significantly reduced. So, if you have a lot of read-consistent-related issues, IMU can help.

Using IMU instead of traditional undo segments does not present a recovery problem for many reasons,8 including the following: