在传统的undo管理模式中,Oracle对undo和data block是一视同仁。这样大致会有三种弊端:1)事务开始时,存放事务表的段头不在内存,server process需要将此i/o上来2)存放旧值的回滚块不在内存3)rollback或者CR读的时候,所需的回滚块被DBWn写到磁盘,oracle也需将此i/o,可能会产生大量的consistent gets和physical reads由此,我们知道,undo会产生redo,又会写undo segment,进而可能产生大量的I/O。undo也是expensive的。10g新特性:IMU机制IMU在shared pool里面分配一片IMU pool,用来缓存回滚块。每个新事务都会分配一个IMU buffer(私有的),一个buffer里有很多node,一个node相当于一个block(回滚块)。好处大致有二:1)提高CR读的速度2)减少I/O我们可以借助v$sysstat查询oracle是否启用了IMU:
- sys@ORCL> select name,value from v$sysstat where name like "%IMU%";
-
- NAME VALUE
- ---------------------------------------------------------------- ----------
- IMU commits 3933
- IMU Flushes 116
我们还可以借助v$sgastat查询系统当前分配的IMU内存:
- sys@ORCL> select * from v$sgastat where name="KTI-UNDO";
-
- POOL NAME BYTES
- ------------ -------------------------- ----------
- shared pool KTI-UNDO 1235304
如果IMU commits和IMU Flushes一直在增长,则表明oracle正在使用IMU。传统的undo管理图如下:IMU模式下,undo信息依然会被redo保护,因为instance recovery需要undo信息去回滚未提交的事务,使数据库处于一致性状态,如果redo没有保护好undo,那么一旦instance crash,数据库有可能处于不一致状态。事务开始时,依旧会在数据块头部分配ITL,并且,他依然会指向undo segment header的事务表,但是回滚块的信息不需要马上写入。这时,undo数据是被记录在IMU buffer里面,这个行为不被redo保护。在以下两种情况,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缺省是false的!IMU及Redo Private Strands技术,其实,是参考了redo log buffer和database_buffer_cache的关系模拟出来的。他最大的关注点,就在于对回滚块的处理。dblink 同步到远处远程数据库undo系列学习之深入浅出事务槽相关资讯 undo
- Oracle 11g undo_retention 以及 (05月28日)
- undo表空间使用率 (07/23/2015 16:29:56)
- undo表空间概述 (02/24/2015 20:32:43)
| - Oracle中利用undo进行数据的恢复操 (11/27/2015 09:31:30)
- undo表空间修复小结 (07/08/2015 08:43:13)
- Oracle 11gR2 Database UNDO表空间 (01/29/2015 11:30:59)
|
本文评论 查看全部评论 (0)