Skip to content

数据技术

介绍free lists及shared pool lru list.
Shared pool中chunk的分配
1、shared pool中的chunk的大小是不一样的，但是是连续的
2、因为chunk是分配的最小单元，因此session需要给对象分配空间的时候，会以chunk为单位进行申请
3、可用的chunk（free）会形成一个链表 feee lists，便于进行分配的时候，可以通过遍历链表寻找到可用的适合的chunk，链表是chunk进行组织和管理的一种方式
4、一个可用的chunk链表是一个bucket，shared pool中会有很多的bucket，不同的bucket中的chunk的大小不同，一般是随着bucket编号的增加而增长的
5.当需要从shared pool中寻找chunk的时候，首先会定位一个bucket，然后遍历bucket，寻找最合适的chunk, 如果chunk的空间比需要的空间大，那么这个chunk就拆分成两个，一个被分配、一个成为free，重新挂接到相应大小的bucket上。
6、在寻找chunk的过程中，如果一个bucket中没有合适的chunk，接着寻找另外一个非空的bucket，如果所有的bucket中都没有合适的chunk，那么就从rec类型的链表中释放一部分的空间，为free，或将free做适当合并 。。注意：只有rec类型的chunk能够被释放空间，即使释放了空间，这些空间可能都不是连续的，都是一些很小的chunk，这样可能形成这样一种情况，shared pool中有空间但是是大量的非常小的chunk，这样在寻找chunk的时候，也很难寻找到合适的chunk–共享池碎片
7、shared pool中所有类型的chunk都是以链表的方式进行管理的
##############
free list 空闲列表
按bucket划分，共有255个，bucket 0—bucket 254
每个bucket上挂有一个 chunk list； free lists上的都是未使用的chunk–状态free
free lists上Bucket大小的分布情况： –环境LINUX 32位/ORACLE 11.2.0.4
Bucket 0-199之前 Bucket size以4bytes递增
Bucket 200-239这一段的Bucket size以64bytes递增
Bucket 240–254的Bucket size增长看起来没太大规律，总之是递增了哈哈。
因为free chunk数量非常的多，这样划分每个Bucket容纳的chunk数量减少，查找效率提高，对shared pool latch的争用也大大减少。注意：如果在shared pool中出现了大量的小的free chunk，就会出现share pool latch争用的情况，即使增加共享池的大小，这个问题随着时间还是会出现的。
RESERVED FREE LISTS:
RESERVED FREE LISTS上的bucket个数我DUMP出来的是15个。
保留FREE LISTS，在SQL语句所需CHUNK大于4400bytes时，会在RESERVED FREE LISTS中查找空闲CHUNK。
如果SQL语句所需CHUNK不大于4400bytes时，只会在free list 中查找CHUNK。
这个是由隐含参数控制的：_shared_pool_reserved_min_alloc minimum allocation size in bytes for reserved area ，默认值4400
###################
DUMP 共享池查看free lists/bucket/RESERVED FREE LISTS结构：–用新建会话来做
alter session set events ‘immediate trace name heapdump level 2’;
select value from v$diag_info where name like ‘De%’;
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_7876.trc
查看TRACE文件内容： –找这一段的方法：VI搜索HEAP DUMP
Chunk 2bffa844 sz= 22460 freeable “character set m”
Total heap size =146798680 — 146798680/1024/1024 –139.99813 初始化参数：shared_pool_size–140M
FREE LISTS: ——空闲列，可以明显看出bucket大小分配的规律–从小到大，共有255个buckets，从16bytes到64k，采用此方法分配内存，可以有效的减少内存碎片。每个Bucket之间都用double linked 相互连接
Bucket 0 size= 16
Chunk 2bc00048 sz= 0 kghdsx
Bucket 1 size=20 20字节的Bucket 1，有很多个Chunk，节约篇幅省略了
Chunk 23a60468 sz= 20 free ” ”
Chunk的地址、大小、状态
Chunk 23ceb498 sz= 20 free ” ”
Chunk 237fcde4 sz= 20 free ” ”
Bucket 2 size=24 –Bucket 2 –24字节,也就是Bucket 2的 size范围在20-24字节。。
Chunk 245b13e4 sz= 24 free ” ”
Chunk 23ace7c0 sz= 24 free ” ”
Chunk 239c5a28 sz= 24 free ” ”
Bucket 3 size=28
Chunk 24540e9c sz= 28 free ” ”
Chunk 2521209c sz= 28 free ” ”
Chunk 23483448 sz= 28 free ” ”
………………
Bucket 198 size=1388
Bucket 199 size=1452 ———- Bucket 200之前 Bucket size以4bytes递增
Chunk 2347d2ac sz= 1492 free ” ”
Bucket 200 size=1516 ———-Bucket 200之后 Bucket size以64bytes递增
Chunk 24b28a94 sz= 1548 free ” ”
Bucket 201 size=1580
Chunk 2433bb14 sz= 1620 free ” ”
Chunk 2463a89c sz= 1620 free ” ”
Chunk 24b829c4 sz= 1620 free ” ”
Bucket 202 size=1644
Chunk 23498518 sz= 1704 free ” ”
Chunk 23de90d0 sz= 1696 free ” ”
………………
Bucket 236 size=3820
Bucket 237 size=3884
Bucket 238 size=3948
Bucket 239 size=4012 ————–Bucket 200到-Bucket 239这一段的Bucket size以64bytes递增
Bucket 240 size=4096 ———–Bucket 239之后 的Bucket size增长看起来没太大规律，总之是递增了哈哈
Bucket 241 size=4100
Bucket 242 size=4108
Bucket 243 size=8204
Bucket 244 size=8460
Bucket 245 size=8464
Bucket 246 size=8468
Bucket 247 size=8472
Bucket 248 size=9296
Bucket 249 size=9300
Bucket 250 size=12320
Bucket 251 size=12324
Bucket 252 size=16396
Bucket 253 size=32780
Bucket 254 size=65548
Total free space = 518232
RESERVED FREE LISTS: –保留FREE LISTS，解析方法同上。保留池中CHUNK都比较大
Reserved bucket 0 size=16
Chunk 23420320 sz= 676 R-free ” ”
Chunk 23427b94 sz= 3420 R-free ” ”
Chunk 2342618c sz= 952 R-free ” ”
Chunk 23800050 sz= 1040 R-free ” ”
Chunk 23400050 sz= 2824 R-free ” ”
Chunk 25bff028 sz= 4032 R-free ” ”
Chunk 293ff788 sz= 2144 R-free ” ”
Reserved bucket 1 size=4400 –这个如果用的会，4564-4400，剩下164字节会成为新CHUNK
Chunk 23430a40 sz= 4564 R-free ” ”
Reserved bucket 2 size=8204
Reserved bucket 3 size=8460
Reserved bucket 4 size=8464
Reserved bucket 5 size=8468
Reserved bucket 6 size=8472
Chunk 2342b988 sz= 9136 R-free ” ”
Reserved bucket 7 size=9296
Reserved bucket 8 size=9300
Reserved bucket 9 size=12320
Reserved bucket 10 size=12324
Reserved bucket 11 size=16396
Chunk 234161f8 sz= 16448 R-free ” ”
Reserved bucket 12 size=32780
Reserved bucket 13 size=65548
Chunk 23401d50 sz= 72296 R-free ” ”
Chunk 23815668 sz= 125312 R-free ” ”
Chunk 23c00050 sz= 180380 R-free ” ”
Reserved bucket 14 size=1990652
Total reserved free space = 6712468 –总空闲保留空间是6.4M，shared_pool_reserved_size 初始化参数大小是 7M，用了0.6M
######################

shared pool LRU链
shared pool LRU链上挂的都是recreate、freeabl状态的chunk,一个SQL语句可能需要多个CHUNK，在LRU链上找到recreate状态的chunk，然后在 recreate状态的chunk下再下挂freeabl状态的CHUNK，–避免全部CHUNK在LRU链上导致LRU链太长。
TRACE文件中找到关于(lru first)的一段，方法同上：
Reserved bucket 14 size=1990652
Total reserved free space = 6712468
UNPINNED RECREATABLE CHUNKS (lru first):
Chunk 246c9848 sz= 348 recreate “KGLHD ” latch=(nil) — latch状态为空， Chunk SIZE是348字节，状态 recreate，
Chunk 237cb10c sz= 4096 recreate “KGLH0^b9197c6e ” latch=(nil)
Chunk 24bb5df0 sz= 364 recreate “KGLHD ” latch=(nil)
Chunk 241aa1b8 sz= 4096 recreate “KGLH0^59449e50 ” latch=(nil)
Chunk 252640a0 sz= 364 recreate “KGLHD ” latch=(nil)
Chunk 23a619a0 sz= 4096 recreate “KGLH0^d5f1e0d7 ” latch=(nil)
Chunk 23465600 sz= 348 recreate “KGLHD ” latch=(nil)
Chunk 2346575c sz= 1036 recreate “KGLHD ” latch=(nil)
Chunk 23465b68 sz= 4096 recreate “KGLH0^c6e0d102 ” latch=(nil) –一个recreate状态CHUNK下的多个freeable状态CHUNK
ds 24bdecb0 sz= 4096 ct= 1
Chunk 23466b68 sz= 4096 freeable “SQLA^1536bb77 ” ds=0x23db5bd8
Chunk 23467b68 sz= 144 freeable “KGLDA ”
Chunk 23467bf8 sz= 4096 freeable “KGLH0^ba3f9b05 ” ds=0x2425e238

shared pool之二：free lists/shared pool lru list

日志挖掘概念：
结论如下：执行日志挖掘操作的可以使用DBA用户或SYSDBA用户，不能使用普通用户。
日志挖掘可以查看到当前用户自己的操作，也可以查看到其它用户的操作。
其它用户已经执行但未提交的操作，也可以查到。
可以挖掘到其它DBA用户或SYSDBA用户的操作。
—–有些语句的返回提示如下面一句连接后的“Connected.”这种为节约篇幅，删了。不要质疑哈哈。
对于DDL操作 ：对于执行DDL前的操作无法挖掘，但是不报错。只显示DDL语句及DDL之后的DML操作。见： logmnr挖掘中间有DDL的操作示例
BYS@ bys001>conn scott/tiger
Connected.
SCOTT@ bys001>desc v$logmnr_contents
ERROR:
ORA-04043: object “SYS”.”V_$LOGMNR_CONTENTS” does not exist
证明普通用户不能使用日志挖掘，连这个视图都看不到的。
##############################################
实验1：使用SYSDBA用户对SYS用户进行日志挖掘
在SYSDBA用户下建表插入数据进行日志挖掘。
SCOTT@ bys001>conn / as sysdba
Connected.
SYS@ bys001>select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
————————
14390465
SYS@ bys001>create table t(a number);
SYS@ bys001>insert into t values(1);
SYS@ bys001>commit;
SYS@ bys001>select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
————————
14390508

可以直接使用这样一条语句：select a.group#,a.member,b.status from v$logfile a,v$log b where a.group#=b.group#;

SYS@ bys001>select group#,status from v$log;
GROUP# STATUS
———- —————-
1 INACTIVE
2 INACTIVE
3 CURRENT
SYS@ bys001>col member for a50

SYS@ bys001>select group#,member,type from v$logfile;

GROUP# MEMBER TYPE
———- ————————————————– ——-
3 /u01/app/oracle/oradata/bys001/redo03.log ONLINE
2 /u01/app/oracle/oradata/bys001/redo02.log ONLINE
1 /u01/app/oracle/oradata/bys001/redo01.log ONLINE
1 /u01/app/oracle/oradata/bys001/redo01a.log ONLINE
SYS@ bys001>execute dbms_logmnr.add_logfile(LogFileName => ‘/u01/app/oracle/oradata/bys001/redo03.log’,Options => dbms_logmnr.new);
PL/SQL procedure successfully completed.
SYS@ bys001>execute dbms_logmnr.start_logmnr(options =>dbms_logmnr.dict_from_online_catalog,startscn =>14390465,endscn =>14390508);
PL/SQL procedure successfully completed.
SYS@ bys001>select operation,sql_redo,sql_undo from v$logmnr_contents where table_name=’T’;
OPERATION
——————————–
SQL_REDO
—————————————————————————————————-
SQL_UNDO
—————————————————————————————————-
DDL
create table t(a number);

INSERT
insert into “SYS”.”T”(“A”) values (‘1’);
delete from “SYS”.”T” where “A” = ‘1’ and ROWID = ‘AAASuWAABAAAVS5AAA’;
#########################################################
实验二：使用SYSDBA用户对普通用户SCOTT下的操作进行挖掘
SYS@ bys001>conn scott/tiger
Connected.
SCOTT@ bys001>create table test(a number);
SCOTT@ bys001>select dbms_flashback.get_system_change_number from dual;
select dbms_flashback.get_system_change_number from dual
*
ERROR at line 1:
ORA-00904: : invalid identifier —普通用户不能查询当前SCN
SCOTT@ bys001>conn / as sysdba
Connected.
SYS@ bys001>select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
————————
14390661
开始插入一条数据。
SYS@ bys001>conn scott/tiger
Connected.
SCOTT@ bys001>insert into test values(3);
SCOTT@ bys001>commit;
SCOTT@ bys001>conn / as sysdba
Connected.
SYS@ bys001>select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
————————
14390688
SYS@ bys001>execute dbms_logmnr.add_logfile(LogFileName => ‘/u01/app/oracle/oradata/bys001/redo03.log’,Options => dbms_logmnr.new);
PL/SQL procedure successfully completed.
SYS@ bys001>execute dbms_logmnr.start_logmnr(options =>dbms_logmnr.dict_from_online_catalog, startscn =>14390661,endscn =>14390688);
PL/SQL procedure successfully completed.
SYS@ bys001>select operation,sql_redo,sql_undo from v$logmnr_contents where table_name=’TEST’;
OPERATION
——————————–
SQL_REDO
—————————————————————————————————-
SQL_UNDO
—————————————————————————————————-
INSERT
insert into “SCOTT”.”TEST”(“A”) values (‘3’);
delete from “SCOTT”.”TEST” where “A” = ‘3’ and ROWID = ‘AAASuXAAEAAAAlGAAA’;
####################################################

实验三：使用SYSDBA，SCOTT用户插入数据不提交，可以挖掘到相应日志————也证明了commit和写日志的无关性。
这里需要使用两个会话，因为在同一个SQLPLUS会话下，切换用户会引起COMMIT。—–实验得出
会话一：查询出当前SCN
SYS@ bys001>select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
————————
14391177
会话二：使用SCOTT用户插入一条记录
SCOTT@ bys001>insert into test values(99);
SCOTT@ bys001>select * from test;
A
———-
3
333
99
会话一：记录当前SCN
SYS@ bys001>select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
————————
14391194
SYS@ bys001>execute dbms_logmnr.add_logfile(LogFileName => ‘/u01/app/oracle/oradata/bys001/redo03.log’,Options => dbms_logmnr.new);
PL/SQL procedure successfully completed.
SYS@ bys001>execute dbms_logmnr.start_logmnr(options =>dbms_logmnr.dict_from_online_catalog,startscn =>14391177,endscn =>14391194);
PL/SQL procedure successfully completed.
SYS@ bys001>select operation,sql_redo,sql_undo from v$logmnr_contents where table_name=’TEST’;
OPERATION
——————————–
SQL_REDO
—————————————————————————————————-
SQL_UNDO
—————————————————————————————————-
INSERT
insert into “SCOTT”.”TEST”(“A”) values (’99’);
delete from “SCOTT”.”TEST” where “A” = ’99’ and ROWID = ‘AAASuXAAEAAAAlGAAC’;

会话二：回滚之前的插入，证明之前的插入确实是未提交的。
SCOTT@ bys001>rollback;
Rollback complete.
SCOTT@ bys001>select * from test;
A
———-
3
333
##########################################################
实验四：使用普通DBA用户可以挖掘出SYS用户的操作
SYS@ bys001>conn bys/bys
Connected.
BYS@ bys001>select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
————————
14391461
BYS@ bys001>conn / as sysdba
SYS@ bys001>insert into t values(9);
SYS@ bys001>commit;
SYS@ bys001>conn bys/bys
BYS@ bys001>select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
————————
14391482
BYS@ bys001>execute dbms_logmnr.add_logfile (LogFileName => ‘/u01/app/oracle/oradata/bys001/redo03.log’,Options => dbms_logmnr.new);
PL/SQL procedure successfully completed.
BYS@ bys001>execute dbms_logmnr.start_logmnr(options =>dbms_logmnr.dict_from_online_catalog ,startscn =>14391461,endscn =>14391482);
PL/SQL procedure successfully completed.
BYS@ bys001>select operation, sql_redo,sql_undo from v$logmnr_contents where table_name=’T’;
OPERATION
——————————–
SQL_REDO
—————————————————————————————————-
SQL_UNDO
—————————————————————————————————-
INSERT
insert into “SYS”.”T”(“A”) values (‘9’);
delete from “SYS”.”T” where “A” = ‘9’ and ROWID = ‘AAASuWAABAAAVS5AAB’;

使用logmnr对其它用户的操作执行日志挖掘的四个对比实验

这个话题讨论在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:0x010000fd OBJ:22327 SCN:0x0000.00719188 SEQ:1 OP: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:4294967295 SCN: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”

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

ORACLE临时表介绍：
ORACLE数据库除了可以保存永久表外，还可以建立临时表temporary tables。这些临时表用来保存一个会话SESSION的数据，或者保存在一个事务中需要的数据。当会话退出或者用户提交commit和回滚rollback事务的时候，临时表的数据自动清空，但是临时表的结构以及元数据还存储在用户的数据字典中。

Oracle临时表分为 会话级临时表 和 事务级临时表。
会话级临时表是指临时表中的数据只在会话生命周期之中存在，当用户退出会话结束的时候，Oracle自动清除临时表中数据。
事务级临时表是指临时表中的数据只在事务生命周期中存在。当一个事务结束（commit or rollback），Oracle自动清除临时表中数据。
临时表中的数据只对当前Session有效，每个Session都有自己的临时数据，并且不能访问其它Session的临时表中的数据。因此，临时表不需要DML锁。

当一个会话结束(用户正常退出 用户不正常退出 ORACLE实例崩溃)或者一个事务结束的时候，Oracle对这个会话的表执行 TRUNCATE 语句清空临时表数据.但不会清空其它会话临时表中的数据.可以索引临时表和在临时表基础上建立视图.同样,建立在临时表上的索引也是临时的,也是只对当前会话或者事务有效. 临时表可以拥有触发器.

全文的REDO/UNOD大小的单位均为BYTES。

一、环境及用户
BYS@bys1>select * from v$version;

BANNER
——————————————————————————–
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production
PL/SQL Release 11.2.0.1.0 – Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 – Production
NLSRTL Version 11.2.0.1.0 – Production

BYS@bys1>select force_logging from v$database;

FOR
—
NO
BYS@bys1>select * from user_role_privs;
USERNAME GRANTED_ROLE ADM DEF OS_
—————————— —————————— — — —
BYS DBA NO YES NO
BYS@bys1>select * from tab;
TNAME TABTYPE CLUSTERID
—————————— ——- ———-
DEPT TABLE
EMP TABLE
SYS_TEMP_FBT TABLE

创建一个表，600W条数据–源数据为dba_objects，通过多次查询插入。

BYS@bys1>create table test9 as select * from dba_objects;
Table created.

BYS@bys1>insert into test9 select * from test9; —多次使用此语句插入数据

BYS@bys1>commit;
Commit complete.
BYS@bys1>select count(*) from test9; 将近700W条。
COUNT(*)
———-
6957120

#########################################

二、创建一个普通表，并统计建表及插入数据等操作所产生的REDO及UNDO大小
注：其中每一步后的查看REDO及UNDO大小我都查询了好几遍，节约篇幅未列出；并且测试系统上只有此客户端在数据库环境中进行操作。

建表前后的REDO/UNDO大小变化
BYS@bys1>select name,value as bytes from (select b.name,a.value from v$mystat a,v$statname b where a.STATISTIC#=b.statistic#) where name=’redo size’ or name like ‘undo change%’;
NAME BYTES
—————————————————————- ———-
redo size 1824
undo change vector size 188

BYS@bys1>create table test1 as select * from test9 where 1=0;
Table created.
BYS@bys1>select name,value as bytes from (select b.name,a.value from v$mystat a,v$statname b where a.STATISTIC#=b.statistic#) where name=’redo size’ or name like ‘undo change%’;

NAME BYTES
—————————————————————- ———-
redo size 238604
undo change vector size 6924

插入数据前后的REDO/UNDO大小变化
BYS@bys1>insert into test1 select * from test9; —需要时间较长，我这里用了8分半。
6957120 rows created.

Elapsed: 00:08:26.37
BYS@bys1>select name,value as bytes from (select b.name,a.value from v$mystat a,v$statname b where a.STATISTIC#=b.statistic#) where name=’redo size’ or name like ‘undo change%’;
NAME BYTES
—————————————————————- ———-
redo size 813924652
undo change vector size 30676180
提交前后的REDO/UNDO大小变化
BYS@bys1>commit;
Commit complete.

Elapsed: 00:00:00.05
BYS@bys1>select name,value as bytes from (select b.name,a.value from v$mystat a,v$statname b where a.STATISTIC#=b.statistic#) where name=’redo size’ or name like ‘undo change%’;
NAME BYTES
—————————————————————- ———-
redo size 813924888
undo change vector size 30676180

查询前后的REDO/UNDO大小变化：
第一次查询产生REDO是因为延迟块清除：
BYS@bys1>set autotrace on
BYS@bys1>select count(*) from test1;
COUNT(*)
———-
6957120
Elapsed: 00:01:38.73
Execution Plan
———————————————————-
Plan hash value: 3896847026

——————————————————————–
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
——————————————————————–
| 0 | SELECT STATEMENT | | 1 | 26827 (1)| 00:05:22 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| TEST1 | 7495K| 26827 (1)| 00:05:22 |
——————————————————————–

Note
—–
– dynamic sampling used for this statement (level=2)

Statistics
———————————————————-
29 recursive calls
1 db block gets
198000 consistent gets
99253 physical reads
5000 redo size
425 bytes sent via SQL*Net to client
419 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
BYS@bys1>set autotrace off
BYS@bys1>select name,value as bytes from (select b.name,a.value from v$mystat a,v$statname b where a.STATISTIC#=b.statistic#) where name=’redo size’ or name like ‘undo change%’;
NAME BYTES
—————————————————————- ———-
redo size 813932848
undo change vector size 30678540

正常查询并没有产生REDO和UNDO
BYS@bys1>select count(*) from test1;

COUNT(*)
———-
6957120

Elapsed: 00:00:26.95
BYS@bys1>select name,value as bytes from (select b.name,a.value from v$mystat a,v$statname b where a.STATISTIC#=b.statistic#) where name=’redo size’ or name like ‘undo change%’;
NAME BYTES
—————————————————————- ———-
redo size 813932848
undo change vector size 30678540

统计情况如下：
create table test1 as select * from dba_objects where 1=0;语句：产生REDO/UNDO分别为： 236780 6736

insert into test1 select * from dba_objects;语句：产生REDO/UNDO分别为： 813686048 30669256
COMMIT语句：产生REDO/UNDO分别为：236和0

三、创建一个ON COMMIT DELETE ROWS 临时表，并统计建表及插入数据等操作所产生的REDO及UNDO大小
PRESERVE ROWS临时表中的测试和ON COMMIT DELETE ROWS结果类似，不再重复贴了。

在上一步做完后退出SQLPLUS再登陆进行操作。

建表前后的REDO/UNDO大小变化
BYS@bys1>select name,value as bytes from (select b.name,a.value from v$mystat a,v$statname b where a.STATISTIC#=b.statistic#) where name=’redo size’ or name like ‘undo change%’;
NAME BYTES
—————————————————————- ———-
redo size 1956
undo change vector size 164
BYS@bys1>create global temporary table temp1 on commit delete rows as select * from test9 where 1=0;
Table created.
BYS@bys1>select name,value as bytes from (select b.name,a.value from v$mystat a,v$statname b where a.STATISTIC#=b.statistic#) where name=’redo size’ or name like ‘undo change%’;
NAME BYTES
—————————————————————- ———-
redo size 26404
undo change vector size 6692

插入数据前后的REDO/UNDO大小变化
BYS@bys1>insert into temp1 select * from test9;
6957120 rows created.
BYS@bys1>select name,value as bytes from (select b.name,a.value from v$mystat a,v$statname b where a.STATISTIC#=b.statistic#) where name=’redo size’ or name like ‘undo change%’;
NAME BYTES
—————————————————————- ———-
redo size 43254212
undo change vector size 30540820
BYS@bys1>select count(*) from temp1;
COUNT(*)
———-
6957120
BYS@bys1>select name,value as bytes from (select b.name,a.value from v$mystat a,v$statname b where a.STATISTIC#=b.statistic#) where name=’redo size’ or name like ‘undo change%’;
NAME BYTES
—————————————————————- ———-
redo size 43254212
undo change vector size 30540820

提交前后的REDO/UNDO大小变化
BYS@bys1>commit;
Commit complete.
BYS@bys1>select name,value as bytes from (select b.name,a.value from v$mystat a,v$statname b where a.STATISTIC#=b.statistic#) where name=’redo size’ or name like ‘undo change%’;
NAME BYTES
—————————————————————- ———-
redo size 43254448
undo change vector size 30540820

查询前后的REDO/UNDO大小变化：–无变化
BYS@bys1>select count(*) from temp1;
COUNT(*)
———-
0
BYS@bys1>select name,value as bytes from (select b.name,a.value from v$mystat a,v$statname b where a.STATISTIC#=b.statistic#) where name=’redo size’ or name like ‘undo change%’;
NAME BYTES
—————————————————————- ———-
redo size 43254448
undo change vector size 30540820
统计情况如下：
create global temporary table temp1语句： 产生REDO和UNDO分别为： 24448 6528

insert into temp1 select * from dba_objects;语句：产生REDO和UNDO分别为：43227808 30534128
COMMIT语句：产生REDO/UNDO分别为： 1346 和0

四：两次操作产生的REDO/UNDO大小对比
普通表统计情况如下：
create table test1 as select * from dba_objects where 1=0;语句：产生REDO/UNDO分别为： 236780 6736

insert into test1 select * from dba_objects;语句：产生REDO/UNDO分别为： 813686048 约775.99M 30669256
COMMIT语句：产生REDO/UNDO分别为：236和0
ON COMMIT DELETE ROWS 临时表统计情况如下：
create global temporary table temp1语句： 产生REDO和UNDO分别为： 24448 6528

insert into temp1 select * from dba_objects;语句：产生REDO和UNDO分别为： 43227808 约41M 30534128
COMMIT语句：产生REDO/UNDO分别为： 1346 和0

总结：临时表的建立和插入数据也产生REDO和UNDO。
建立临时表时因为修改了数据字典所以产生了少量REDO与UNDO；

提交时是在REDO中插入一条提交的标签，所以只产生少量REDO。

那么在插入数据时，临时表还是会产生REDO和UNDO，但是REDO量比普通表插入相同数据量时产生的REDO少很多，UNDO大小相近，这个是怎么解呢？

大致是因为：临时表产生了undo，而undo的变化又产生了REDO LOG， 所以临时表的DML操作也产生了REDO。
但是临时表产生的REDO的大小却比普通表DML操作的小，是因为临时表中不记录表中数据变化所产生的REDO，只记录了UNDO数据变化所产生的REDO。

临时表会产生UNDO，是因为临时表操作和普通表是一样的，也要支持rollback和commit，这样自然要记录到undo中。

普通表与临时表DML操作会产生REDO/UNDO对比与分析

1.一致性读：
假设从9点时发出一条查询，此查询语句运行了一分钟，那么查询的是9点时表内信息，如果在9时至9：00：30之间修改并提交了数据，查询语句扔查询结果仍是9点时的表内的数据。

实验步骤如下：
在SESSION1中发出查询语句（增加条件延长查询语句运行时间）
在SESSION2中修改并提交。（需要在SESSION1查询语句运行期间进行）
SESSION1:
9:26:50 SQL> select * from test;
A
———-
1
2
3
4
5
6
7
16
18
19
10 rows selected

下面这条语句能够执行一分钟左右，在语句执行时，抓紧时间去SESSION2中提交修改的数据。

可以看到，查询出的是发出查询时表内的数据：

9:27:26 SQL> select * from test where a=7 and (select count(*) from dba_objects,dba_tables)>1 and (select count(*) from dba_objects,dba_tables)>2 ;
A
———-
7
9:28:05 SQL>

SESSION2:
9:27:13 SQL> select * from test;
A
———-
1
2
3
4
5
6
7
16
18
19
10 rows selected
9:27:14 SQL> update test set a=a+7 where a=7;
1 row updated
9:27:54 SQL> commit;
Commit complete
9:27:57 SQL> SELECT * FROM TEST
A
———-
1
2
3
4
5
6
14
16
18
19
10 rows selected
9:28:50 SQL>

2.current read：
读取当前的 data block，最新的 data block，比如在update， delete的时候就总是current read。
因为要对最新的data block做更改，对过去更改没有实际意义。
执行过程描述：
session 1 开始了一个update 操作，通过consistent read（a=9） 获取了 数据块的id。使用WHERE后语句使得这个UPDATE操作需要持续很长时间。
session 2 在SESSION1的UPDATE未执行时，修改了 a=9 这一行的数据，变成了a=18
session 1 通过一个通过最开始查询a=9拿到的block id去以current read读取数据块，结果发现数据块不符合filter的条件a=9。所以 session 1没有更新。

session 1：
SQL> set time on
9:06:43 SQL> select a,DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) from test;
A DBMS_ROWID.ROWID_BLOCK_NUMBER(
———- ——————————
1 242
2 242
3 242
4 242
5 242
6 242
7 242
8 242
9 242
10 242
10 rows selected

在SESSION1执行以下语句，因为执行时间较长，大约要一分钟，在执行期间去SESSION2提交更改的数据。
9:10:15 SQL> update test set a=a+1 where a=9 and (select count(*) from dba_objects,dba_tables)>1;
0 rows updated
9:10:40 SQL>
9:14:04 SQL> select * from test;
A
———-
1
2
3
4
5
6
7
8
18
10
10 rows selected
9:14:10 SQL>

SESSION2:
SQL> set time on
9:07:48 SQL> update test set a=a+9 where a=9;
1 row updated
9:10:34 SQL> commit;
Commit complete
9:10:37 SQL>

一致性读和current read演示