当前位置:Gxlcms > mysql > 深入解析OracleIMU模式下的REDO格式

深入解析OracleIMU模式下的REDO格式

时间:2021-07-01 10:21:17 帮助过:28人阅读

这个话题讨论在ITPUB,链接:http://www.itpub.net/thread-1838538-1-1.html 1. 什么是IMU?IMU的主要作用是什么,也就是说为了解决什么问题? IMU---In Memory Undo,10g新特性,数据库会在shared pool开辟独立的内存区域用于存储Undo信息, 每个新事务都会

这个话题讨论在ITPUB,链接:http://www.itpub.net/thread-1838538-1-1.html

1. 什么是IMU?IMU的主要作用是什么,也就是说为了解决什么问题?

IMU--->In Memory Undo,10g新特性,数据库会在shared pool开辟独立的内存区域用于存储Undo信息,
每个新事务都会分配一个IMU buffer(私有的),一个buffer里有很多node,一个node相当于一个block(回滚块)。

IMU特性:
IMU顾名思义就是在内存中的undo,现在每次更改data block,Oracle 不用去更改这个undo block(也不会生成相应的redo了),而是把undo信息缓存到IMU里去了,只有最后commit或者flush IMU时,这些undo 信息才会批量更新到undo block,并生成redo。可以避免Undo信息以前在Buffer Cache中的读写操作,从而可以进一步的减少Redo生成,同时可以大大减少以前的UNDO SEGMENT的操作。IMU中数据通过暂存、整理与收缩之后也可以写出到回滚段,这样的写出提供了有序、批量写的性能提升。

IMU主要作用:
减少CR块-->在构造CR block时,不用像以前那样从undo block中获取undo record了,而是用共享池私有IMU区域里的信息来构造cr block,减少了BUFFER CACEH中 CBC LATCH竞争。
减少REDO日志条目数-->不再是每条DML语句一个redo records,而是每个事务一个redo records--REDO RECORD的产生会传到 LOG BUFFER,,会申请LATCH。
减少LATCH-->首先因为减少REDO RECORD数目;其次用一个IMU latch 代替 redo allocation latch 和 redo copy latch这两个,也减少了LATCH争用.
查询系统中IMU LATCH的数量--也就是Private redo strand area的个数。

IMU 私有REDO区对应的内部表:x$kcrfstrand IMU UNDO区对应的内部表:x$ktifp
BYS@ bys3>select count(name) from v$latch_children where lower(name) like 'in mem%';
COUNT(NAME)
-----------
84
BYS@ bys3>select count(*),name from v$latch_children where lower(name) like 'in mem%' group by name;
COUNT(*) NAME
---------- ----------------------------------------------------------------
84 In memory undo latch
下面语句可以查询IMU LATCH的获取情况
select name,gets from v$latch_children where lower(name) like 'in mem%';

2.在哪些场景下不会使用IMU特性?(ORACLE 10g出现了IMU,默认开启IMU)

在RAC环境中不支持IMU。
开启FLASHBACK DATABASE时会开启打开辅助日志,此时不能用IMU。
事务过大--据说每个IMU Buffer的Private redo strand area大小大概是64KB(64位的Oracle版本是128KB),大事务不能用。比如一个事务,先有一条UPDATE,此时将REDO私有区域使用完了,此事务的其它DML语句,将自动使用非IMU模式。
共享池太小时,ORACLE会自动不使用IMU。
无法获取IMU LATCH时,将自动使用非IMU模式。

3.如何手动关闭和开启IMU模式?


10G和11G中默认是开启IMU特性的,开启关闭语句如下:--修改后最好重启使之生效,或者至少切换一次REDO日志。
alter system set "_in_memory_undo"=false;
alter system set "_in_memory_undo"=true; --关闭IMU后使用此语句改回使用IMU特性。

4、谈谈一条UPDATE语句从第一步到第九步的整个过程?在IMU模式下对REDO日志做DUMP分析(上图所示:IMU模式的REDO格式)。

UPDATE语句从第一步到第九步的对应上图是:

第一步:将更改的数据存放到PGA
第二步:将BUFFER CACHE中旧数据拷贝到共享池的私有IMU buffer
第三步:将PGA中修改后的数据存放到private redo private redo--在IMU中才有。
第四步:修改buffre cache中的数据
做提交操作后:
第五步:从IMU中拷贝修改前值到BUFFER CACHE中构建一个CR块-----即使未提交时SMON每3秒也会做此工作
第六步:第四步修改修改buffre cache中的数据产生的redo日志写入log buffe
第七步:第五步操作构造CR块,产生的redo日志写入 log buffe
第八步:由lgwr写出log buffer到redo log file
第九步:dbwr 将脏数据写入data file

5.UPDATE操作DUMP REDO 内容实验记录:

INSERT 和DELETE语句的,详见:点击打开链接
REDO RECORD
- Thread:1 RBA: 0x000141.00000027.0010 LEN: 0x031c VLD: 0x0d
SCN: 0x0000.00719188 SUBSCN: 1 01/07/2014 20:27:05
(LWN RBA: 0x000141.00000027.0010 LEN: 0002 NST: 0001 SCN: 0x0000.00719187)
####一个REDO RECORD: RECORD头+CHANGE VECTOR组成(一个CV就是一个操作)
以上是日志头,Thread:1 线程号,RAC时会有1,2等
RBA: 0x000141.00000027.0010 将16进制转换为十进制分别是日志文件号、日志块号、在块上第N字节
VLD: 0x0d日志类型--IMU模式时是这个;非IMU时是:VLD: 0x05
SCN: 0x0000.00719188 SUBSCN: 1 01/07/2014 20:27:05 ----
BYS@ bys3>select scn_to_timestamp(to_number('719188','xxxxxxxx')) from dual;
SCN_TO_TIMESTAMP(TO_NUMBER('719188','XXXXXXXX'))
---------------------------------------------------------------------------
07-JAN-14 08.27.05.000000000 PM
--是此REDO条目产生时的SCN号,转为十进制现转为时间戳为:08.27.05, 插入语句完成是在20:27:00 BYS@ bys3>commit;-- --这个是在插入语句完成5秒后,此SCN与CHANGE#4提交时SCN一致。
(LWN RBA: 0x000141.00000027.0010 LEN: 0002 NST: 0001 SCN: 0x0000.00719187)
括号中SCN: 0x0000.00719187 比上一行:SCN: 0x0000.00719187 少了1个SCN。
####

CHANGE #1 TYP:2 CLS:1 AFN:4 DBA:0x010000fd OBJ:22327 SCN:0x0000.007164a1 SEQ:1 OP:11.5 ENC:0 RBL:0
#####AFN:4,操作是在4号文件做的-dba_data_files.file_id;OBJ:22327--操作的对象的OBJECT_ID。OP:11.5-有的版本是OP:11.19--更新操作
KTB Redo
op: 0x11 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: F xid: 0x0005.002.00000edc uba: 0x00c041cd.02ea.01
Block cleanout record, scn: 0x0000.0071917c ver: 0x01 opt: 0x02, entries follow...
itli: 1 flg: 2 scn: 0x0000.007164a1
KDO Op code: URP row dependencies Disabled -- --URP=UPDATE ROW PIECE。有时会是:KDO Op code:21 row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x010000fd hdba: 0x010000fa
itli: 2 ispac: 0 maxfr: 4858
tabn: 0 slot: 8(0x8) flag: 0x2c lock: 2 ckix: 0
ncol: 3 nnew: 1 size: 2 --ncol: 3 nnew: 1 表示操作的表有3个列,操作了一列,size: 2
--列字符长度增加2:database减去chedan---根据多次update并DUMP的日志来看,这里的size的值应该是:当前CHANGE中的值减去另一个。。
col 1: [ 8] 64 61 74 61 62 61 73 65 --set dname='database' --col 1: [ 8],第二列,8个字符

BYS@ bys3>select dump('database',16),dump('dataoracle',16) from dual;
DUMP('DATABASE',16) DUMP('DATAORACLE',16)
------------------------------------- --------------------------------------------
Typ=96 Len=8: 64,61,74,61,62,61,73,65 Typ=96 Len=10: 64,61,74,61,6f,72,61,63,6c,65
#########################
CHANGE #2 TYP:0 CLS:25 AFN:3 DBA:0x00c000c0 OBJ:4294967295 SCN:0x0000.00719153 SEQ:1 OP:5.2 ENC:0 RBL:0
ktudh redo: slt: 0x0002 sqn: 0x00000edc flg: 0x000a siz: 164 fbi: 0
uba: 0x00c041cd.02ea.01 pxid: 0x0000.000.00000000
### #####################事务信息
TYP:0 普通块 ,CLS:25 class大于16是UNDO块-递增。AFN:3 绝对文件号dba_data_files.file_id--是UNDO的文件号
DBA:0x00c000c0 数据块在内存中地址
OBJ:4294967295 --十进制,转为16进制是FFFFFFFF
SCN:0x0000.00719153 转换为16进制可与操作时对比
OP:5.2 -> operation code 向UNDO段头的事务表写事务信息-事务开始
uba: 0x00c041cd.02ea.01 UNDO块地址
#######################

CHANGE #3 TYP:0 CLS:1 AFN:4 DBA:0x010000fdOBJ:22327 SCN:0x0000.00719188 SEQ:1OP:11.5 ENC:0 RBL:0
KTB Redo --同CHANGE #1的解析
op: 0x02 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: C uba: 0x00c041cd.02ea.02
KDO Op code: URP row dependencies Disabled ---UNDO ROW PIECE
xtype: XA flags: 0x00000000 bdba: 0x010000fd hdba: 0x010000fa
itli: 2 ispac: 0 maxfr: 4858
tabn: 0 slot: 9(0x9) flag: 0x2c lock: 2 ckix: 0
ncol: 3 nnew: 1 size: 6
col 1: [10] 64 61 74 61 6f 72 61 63 6c 65 --第2列,10个字符--此次操作的字符数
BYS@ bys3>select dump('database',16),dump('dataoracle',16) from dual;
DUMP('DATABASE',16) DUMP('DATAORACLE',16)
------------------------------------- --------------------------------------------
Typ=96 Len=8: 64,61,74,61,62,61,73,65 Typ=96 Len=10: 64,61,74,61,6f,72,61,63,6c,65

###########################
CHANGE #4 TYP:0 CLS:25 AFN:3DBA:0x00c000c0 OBJ:4294967295SCN:0x0000.00719188 SEQ:1 OP:5.4 ENC:0 RBL:0
ktucm redo: slt: 0x0002 sqn: 0x00000edc srt: 0 sta: 9 flg: 0x2 ktucf redo: uba: 0x00c041cd.02ea.02 ext: 15 spc: 7890 fbi: 0
######OP:5.4 表明是提交操作。AFN:3 对应的是UNDO文件,slt: 0x0002 修改了UNDO文件的这个事务槽,uba: 0x00c041cd.02ea.02


CHANGE #5 TYP:1 CLS:26 AFN:3 DBA:0x00c041cd OBJ:4294967295 SCN:0x0000.0071917c SEQ:1 OP:5.1 ENC:0 RBL:0
ktudb redo: siz: 164 spc: 0 flg: 0x000a seq: 0x02ea rec: 0x01
###OP:5.1 --把数据修改前值放到UNDO --AFN:3 --在UNDO文件里操作,UNDO文件号是3。。CLS:26 --比CHANGE #2中大1,顺序增长哈哈
xid: 0x0005.002.00000edc
ktubl redo: slt: 2 rci: 0 opc: 11.1 [objn: 22327 objd: 22327 tsn: 4]
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00c041cc.02ea.04
prev ctl max cmt scn: 0x0000.00718dff prev tx cmt scn: 0x0000.00718e4e
txn start scn: 0x0000.00000000 logon user: 32 prev brb: 12599753 prev bcl: 0 BuExt idx: 0 flg2: 0
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: L itl: xid: 0x0009.004.00000ebc uba: 0x00c037d5.0249.08
flg: C--- lkc: 0 scn: 0x0000.0070cfea
KDO Op code: URP row dependencies Disabled -----UNDO ROW PIECE
xtype: XA flags: 0x00000000 bdba: 0x010000fd hdba: 0x010000fa
itli: 2 ispac: 0 maxfr: 4858
tabn: 0 slot: 8(0x8) flag: 0x2c lock: 0 ckix: 0
ncol: 3 nnew: 1 size: -2 ----列字符长度减少2:chedan 减去database---根据多次update并DUMP的日志来看,这里的size的值应该是:当前CHANGE中的值减去另一个
col 1: [ 6] 63 68 65 64 61 6e ---- 原值是chedan,,第二列,6个字符

BYS@ bys3>select dump('chedan',16),dump('test',16) from dual;
DUMP('CHEDAN',16) DUMP('TEST',16)
------------------------------- -------------------------
Typ=96 Len=6: 63,68,65,64,61,6e Typ=96 Len=4: 74,65,73,74


CHANGE #6 TYP:0 CLS:26 AFN:3 DBA:0x00c041cd OBJ:4294967295 SCN:0x0000.00719188 SEQ:1 OP:5.1ENC:0 RBL:0 --解析同上
ktudb redo: siz: 92 spc: 7984 flg: 0x0022 seq: 0x02ea rec: 0x02
xid: 0x0005.002.00000edc
ktubu redo: slt: 2 rci: 1 opc: 11.1 objn: 22327 objd: 22327 tsn: 4
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
KDO undo record:
KTB Redo
op: 0x02 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: C uba: 0x00c041cd.02ea.01
KDO Op code: URP row dependencies Disabled -----UNDO ROW PIECE
xtype: XA flags: 0x00000000 bdba: 0x010000fd hdba: 0x010000fa
itli: 2 ispac: 0 maxfr: 4858
tabn: 0 slot: 9(0x9) flag: 0x2c lock: 0 ckix: 0
ncol: 3 nnew: 1 size: -6 -列字符长度减少2:test减去database---根据多次update并DUMP的日志来看,这里的size的值应该是:当前CHANGE中的值减去另一个
col 1: [ 4] 74 65 73 74 --此次操作,第二列,4个字符

BYS@ bys3>select dump('chedan',16),dump('test',16) from dual;
DUMP('CHEDAN',16) DUMP('TEST',16)
------------------------------- -------------------------
Typ=96 Len=6: 63,68,65,64,61,6e Typ=96 Len=4: 74,65,73,74





################################################验证SMON进程

实验步骤: --这个实验思路有错误的。不应该是DMUP REDO日志,因为当时还没从log buffe写入redo log file,可以考虑使用--我还未做。

Event 10500 - Trace SMON Process 跟踪SMON进程 event = "10500 trace name context forever, level 1" D

12:12:04 BYS@ bys3>select a.group#,a.sequence#,a.archived,a.status,b.type,b.member from v$log a,v$logfile b where a.group#=b.group#;

GROUP# SEQUENCE# ARC STATUS TYPE MEMBER
---------- ---------- --- ---------------- ------- ------------------------------
1 334 NO CURRENT ONLINE /u01/oradata/bys3/redo01.log
2 332 YES ACTIVE ONLINE /u01/oradata/bys3/redo02.log
3 333 YES ACTIVE ONLINE /u01/oradata/bys3/redo03.log
Elapsed: 00:00:00.03
12:12:09 BYS@ bys3>select * from dept;
DEPTNO DNAME LOC
---------- -------------- -------------
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
40 OPERATIONS BOSTON
11 database database
22 dataoracle sh
Elapsed: 00:00:00.01
12:12:24 BYS@ bys3>update dept set dname='mysql' where deptno=11;
1 row updated.
Elapsed: 00:00:00.01

12:12:29 BYS@ bys3> ---UPDATE语句完成的时间是:12:12:29,只做UPDATE语句,不要提交,立刻去DUMP REDO LOGFILE.


另一会话在上一步做操作时来DUMP : event = "10500 trace name context forever, level 1"

人气教程排行