由于传统的UNDO管理模式，oracle对于undo和data block，需要先读入到data

buffer中进行修改，并产生data的redo。

修改的过程：产生undo的redo，更改undo block，产生data的redo，修改data

block

这就会产出i/o问题。

第一，undo信息如果不在data buffer中，首先要从外部文件读入

第二，undo的所有变化都要同时产生redo，在事务递交时候被写入到redo log中

从oracle10g开始，引入了in memory undo的新技术，IMU技术就是在shared

pool中分配一片内存空间imu pool。用来避免undo信息以前在buffer cache中的

读写操作，从而可以进一步减少redo生成，同时可以大大减少以前的undo

segment的操作。

每个新的事务都会分配一个imu buffer，用来记录undo的信息。

总结 imu机制好处：1提高CR读的速度 2减少i/o

隐含参数_in_memory_undo 来控制该特性是否启动.默认是true。

隐含参数_imu_pools 默认值3 提供并发

imu的使用信息，如递交次数可以通过v$sysstat视图查询

select name ，value from v$sysstat where name like ‘%commits’；

v$sgastat查询系统当前的imu内存分配大小

select * from v$sgastat where name=‘KTI-UNDO’；

select name，gets，misses，immediate_gets，sleeps from v

$latch_children where name like ‘%undo latch’；

imu模式下，undo信息依然会被redo保护，因为instance recovery需要undo信息

来回滚未提交的事务，是数据库处于一致性状态。

事务开始时，依旧会在数据块的头部分配ITL，并且，指向undo segment header

的事务表，但回滚块的信息不需要马上写入。这时，undo数据是被记录在imu

buffer里面，这个行为不被redo保护。 一下二种情况，undo数据会被写回到

undo块：

1.imu buffer空间不足时，会发生imu flush，将undo flush到

database_buffer_cache里的回滚块中

2.LGWR将redo写到redo log file时，会发生imu commit，将private redo

strands写到redo log file，将imu buffer 写到回滚块

当imu buffer flush到回滚块时，oracle会进行合并处理，减少回滚块的消耗以

及redo的产生。

在10g开始，同时会在shared pool里，分配一个private redo buffer，每个事

务产生的redo都会放在这里。

有了private redo strands机制，针对imu buffer产生的日志，就直接在shared

pool里面记录。

rac和streams里面imu默认没有开启的

imu和redo private strands技术，参考了redo log buffer 和

database_buffer_cache的关系模拟出来的。

附上几张UNDO的图