深入学习：In Memory Undo
黄玮（Fuyuncat）
资深 Oracle DBA，从事 Oracle 数据库管理、维护与开发工作十余年，有丰富的大型数据库设计、开发与维护方面的经验。个人网站 www.HelloDBA.com
编辑手记：文中通过一步步对比测试，分析了IMU（in memory undo）对日志产生的影响。我们一起来学习
IMU是从10g引入的一项技术，并且是Oracle的专利技术。但是，在10g中似乎没有完全激活，以下的测试在11g中进行。
在传统的事务更新过程中，如果一条数据记录被更新，就会从buffer cache中读取/分配一块UNDO数据块，并且立即会写入一条UNDO条目。如果同一个事务中有多条记录被更新，则undo buffer数据块中就会写入多条undo条目。引入IMU后，会从shared pool中分配出一个新的内存池——IMU pool。当一条数据记录被更新，仍然会从buffer cache中读取/分配一块undo数据块，但是，这块undo块并不会立即被更新，而是会在IMU pool中产生一个IMU node，IMU节点通过IMU map与数据记录更新对应。如果事务中有多条记录被修改，则IMU pool中就生产多个IMU nodes，而buffer中的undo block不会发生任何变化。当发生IMU commit或IMU flush时，才会通过IMU map将这些IMU node记录的undo信息写入undo buffer block中。并且，所有这些redo信息会和commit vector一起作为一个Redo条目写入Redo log中。整个过程中UNDO所产生的redo信息则大大减少。
隐含参数_in_memory_undo用于控制IMU特性的开关，可以在会话/系统级立即生效，默认为true。另外一个隐含参数_IMU_pools则控制IMU pool的数量，默认为3。此外，目前IMU的使用还存在一些限制，如undo管理方式（undo_management）必须为auto，在RAC中无效
1、IMU Commit
让我们看下IMU commit与传统事务commit时产生的redo size的变化。首先看传统模式下
第三次
提交
可以看到，每一条数据被update都产生一条redo 条目。 然后，我们激活IMU，再重复上述事务过程，
第一次修改并检查
第二次修改并检查
第三次修改并检查
提交
可见redo数量并没有随着数据的更新而增加，而是在IMU commit时增加。而当1条DML语句更新多条记录时，也可以使用到IMU：
从上面的例子中你也许注意到了，尽管UPDATE过程中redo size没有变化，但是，在IMU commit时，redo size的变化却很大，比传统模式下的commit产生的redo大许多。这是因为在IMU commit中，不仅仅包含了commit vector，还包含了commit之前数据变化，并且这些redo数据的写入是一次批量写入。我们可以将这个redo条目dump出来观察其内容：
可以看到，在trace日志中，这一redo条目包含了多个change：
2、IMU Flush
IMU pool也是按照LRU算法管理的。当IMU pool没有足够空闲内存可分配时，会将buffer链上LRU段的buffer块flush出来。其他一些事件也会导致IMU flush的发生，如switch logfile、rollback。但是，尽管IMU pool是从shared pool中分配的，手动flush shared pool并不会导致IMU flush。当IMU flush发生时，也会将undo、redo数据批量写入。
Tips: 通过dump出事务的undo block，可以比较IMU commit/flush前后undo block的变化——commit/flush之前没有写入数据。
3、IMU CR
在传统事务中，需要进行一致性读时，会从相应的UNDO数据块中读入undo数据进行undo操作。而在IMU中，在发生IMU commit或IMU flush之前，这些undo数据并未写入UNDO数据块中，此时一致性读就从IMU pool中读取相应的IMU node中的undo信息。
session1
session2
从trace文件可以看到，我们将buffer cache的内容都flush了，但是并未从undo文件中读取undo 信息（没有相应的IO等待）。
-----the end