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:

* A database writer will never write a changed buffer to disk unless the associated redo information has already been written to an online redo log. (A database writer can trigger the log writer to flush the redo log buffer.) This means Oracle will not permit the situation where a changed on-disk block exists without the associated redo written to an online redo log. If an instance or media failure occurs, any changed on-disk block will have its recovery information in the redo stream. So, a buffer change is not a recovery issue; it's the change to an on-disk block that is a recovery issue, and Oracle has already dealt with this.