[Oracle] IMU In Memroy Undo

博客首页 » Oracle IMU In Memroy Undo

发布于 08 Dec 2015 02:59
标签 blog
In Memroy Undo是Oracle 10g引入的提高Undo性能的机能

深入解析Oracle IMU模式下的REDO格式

http://www.itpub.net/thread-1838538-1-1.html

IMU解说

http://www.th7.cn/db/Oracle/201502/92649.shtml

ORACLE IMU In Memory Undo 学习

http://blog.itpub.net/500314/viewspace-1069780/

在传统的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:
[sql] view plaincopyprint?
sys@ORCL> select name,value from v$sysstat where name like '%IMU%';
NAME VALUE
------------— --
IMU commits 3933
IMU Flushes 116
sys@ORCL> select name,value from v$sysstat where name like '%IMU%';

NAME VALUE
------------— --
IMU commits 3933
IMU Flushes 116
我们还可以借助v$sgastat查询系统当前分配的IMU内存:
[sql] view plaincopyprint?
sys@ORCL> select * from v$sgastat where name='KTI-UNDO';
POOL NAME BYTES
-- ------ --
shared pool KTI-UNDO 1235304
sys@ORCL> select * from v$sgastat where name='KTI-UNDO';

POOL NAME BYTES
-------- --
shared pool KTI-UNDO 1235304
如果IMU commits和IMU Flushes一直在增长,则表明oracle正在使用IMU。
1343842001_2161.png 传统的undo管理图如下:
1343842001_2161.png 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都会放在这里
1343843798_4274.png

有了private redo strands机制,针对IMU buffer产生的日志,就直接在shared pool里面记录。
注意了,在RAC和streams里面,IMU缺省是false的!
IMU及Redo Private Strands技术,其实,是参考了redo log buffer和database_buffer_cache的关系模拟出来的。他最大的关注点,就在于对回滚块的处理

Oracle中的IMU详解

http://www.linuxidc.com/Linux/2012-09/70656.htm

[日期:2012-09-16] 来源:Linux社区 作者:changyanmanman
1、概述

Oracle 10g InMemory Undo新特性:

通过以前的介绍,可知道Undo的管理方式和常规的数据管理方式是相同的,当进行数据修改时,会在Buffer中创建前镜像,同时会记录相应的Redo,然后这些Undo数据同样会写出到UNDO SEGMENT上,当进行一致性读或回滚时,可能会产生大量的consistentgets和physical reads。注意到这里,Undo会产生Redo信息,又会写UNDO SEGMENT,进而又可能产生大量读取I/O,这些都是资源密集型操作。如果能够缩减Undo在这些环节的Redo与Undo写出,那么显然就可以极大地提升数据库性能,减少资源的消耗和使用。

从Oracle10g开始,Oracle在数据库中引入了In Memory Undo(可以被缩写为IMU)的新技术,使用这一技术,数据库会在共享内存中(Shared Pool)开辟独立的内存区域用于存储Undo信息,这样就可以避免Undo信息以前在Buffer Cache中的读写操作,从而可以进一步的减少Redo生成,同时可以大大减少以前的UNDO SEGMENT的操作。IMU中数据通过暂存、整理与收缩之后也可以写出到回滚段,这样的写出提供了有序、批量写的性能提升。

IMU机制与前面日志提到的PVRS紧密相关,由于每个IMU Buffer的大小在64~128KB左右,所以仅有特定的小事务可以使用,每个事务会被绑定到一个独立的空闲的IMU Buffer,同时相关的Redo信息会写入PVRS中,同样每个IMU Buffer会由一个独立的In Memory Undo Latch保护,当IMU Buffer或PVRS写满之后,数据库需要写出IMU中的信息。

一个新引入的隐含参数可以控制该特性是否启用,这个参数是_in_memory_undo,在Oracle 10g中这个参数的缺省值是TRUE(不同版本和平台参数的初始设置可能不同):

sys@TQGZS> @GetHidPar.sql
Enter value for par: _in_memory_undo
old 4: AND x.ksppinm LIKE '%&par%'
new 4: AND x.ksppinm LIKE '%_in_memory_undo%'
NAME VALUE DESCRIB
------ ----------------
_in_memory_undo TRUE Make in memory undo for top level transactions

IMU的内存在Shared Pool中分配,回想一下Redo Log Buffer的内存使用与功能,实际上IMU技术在某种程度上也是参考了Log Buffer的机制,通过以下查询可以获得系统当前分配的IMU内存:

sys@TQGZS> select * from v$sgastat where name ='KTI-UNDO';
POOL NAME BYTES
-------- --
shared pool KTI-UNDO 1235304

In Memory Undo池缺省的会分配3个,用以提供更好的并发:

sys@TQGZS> @GetHidPar.sql
Enter value for par: _imu_pool
old 4: AND x.ksppinm LIKE '%&par%'
new 4: AND x.ksppinm LIKE '%_imu_pool%'
NAME VALUE DESCRIB
------ ----------------
_imu_pools 3 in memory undo pools

IMU的使用信息,如提交次数可以通过V$SYSSTAT视图查询:

sys@TQGZS> select name,value from v$sysstat where name like '%commits';
NAME VALUE
------ --—-
usercommits 2877
IMUcommits 1549

新的内存Buffer通过In Memory Undo Latch来进行保护:

sys@TQGZS> select name,gets,misses,immediate_gets,sleeps
2 from v$latch_children where name like '%undo latch';
NAME GETS MISSES IMMEDIATE_GETS SLEEPS
------ -- -- --— --
In memory undolatch 0 0 0 0
In memory undolatch 0 0 0 0
In memory undolatch 0 0 0 0
In memory undolatch 0 0 0 0
In memory undolatch 0 0 0 0
In memory undo latch 0 0 0 0
In memory undolatch 0 0 0 0
In memory undolatch 0 0 0 0
In memory undolatch 0 0 0 0
In memory undolatch 0 0 0 0
In memory undolatch 0 0 0 0
In memory undolatch 0 0 0 0
In memory undolatch 0 0 0 0
In memory undolatch 4 0 2 0
In memory undolatch 214 0 25 0
In memory undolatch 6118 0 3064 0
In memory undolatch 4230 0 1084 0
In memory undolatch 39583 0 2842 0
18 rows selected.

除了前面提到的,还有几个隐含参数与IMU有关:
·_recursive_imu_transactions:控制递归事务是否使用IMU,该参数缺省值为False;

sys@TQGZS> @GetHidPar.sql
Enter value for par: _recursive_imu_transactions
old 4: AND x.ksppinm LIKE '%&par%'
new 4: AND x.ksppinm LIKE '%_recursive_imu_transactions%'
NAME VALUE DESCRIB
------ ----------------
_recursive_imu_transactions FALSE recursive transactions may be IMU

·_db_writer_flush_imu:控制是否允许DBWR将IMU事务的降级为常规事务,并执行UNDO SEGMENT的写出操作,缺省值为TRUE。

sys@TQGZS> @GetHidPar.sql
Enter value for par: _db_writer_flush_imu
old 4: AND x.ksppinm LIKE '%&par%'
new 4: AND x.ksppinm LIKE '%_db_writer_flush_imu%'
NAME VALUE DESCRIB
------ ----------------
_db_writer_flush_imu TRUE If FALSE, DBWR will not downgrade IMU txns for AGING

此外,在RAC环境中,IMU不被支持。

经过不同版本Oracle技术的不断演进,Oracle的内存管理已经和以前大为不同,现在Buffer Cache、Shared Pool、Log Buffer的内容正在不断交换渗透,Redo、Undo数据都可以部分地存储在共享池中,Oracle 11g的Result Cache也被记录在Shared Pool当中。


本页面的文字允许在知识共享 署名-相同方式共享 3.0协议和GNU自由文档许可证下修改和再使用,仅有一个特殊要求,请用链接方式注明文章引用出处及作者。请协助维护作者合法权益。


系列文章

文章列表

  • Oracle IMU In Memroy Undo

这篇文章对你有帮助吗,投个票吧?

rating: 0+x

留下你的评论

Add a New Comment