[20160529]快速提交的一个疑问3.txt
--链接 http://blog.itpub.net/267265/viewspace-2108017/
--在上一次链接里面提到在快速提交时,itl槽的_ktbitun._ktbitfsc记录是dml记录长度减少的长度.
--如果清除后,会kdbh.kdbhavsp相加写回kdbh.kdbhavsp,以前一直对快速提交没有很好的理解,我一直以为会清除数据信息里面的lock,实
际上在下次ITL覆盖时清除,还是通过一个例子来说明:
1.环境:
SCOTT@test01p> @ ver1
PORT_STRING VERSION BANNER CON_ID
------------------------------ -------------- -------------------------------------------------------------------------------- ----------
IBMPC/WIN_NT64-9.1.0 12.1.0.1.0 Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production 0
--家里只有12c,而且还是windows的版本.
create table t ( id number ,text varchar2(200)) segment creation immediate;
insert into t select rownum ,lpad('a',50,'a') from dual connect by level<=4;
commit ;
SCOTT@test01p> select ora_rowscn,rowid,t.id from t;
ORA_ROWSCN ROWID ID
---------- ------------------ ----------
22661664 AAAZpJAAJAAAACNAAA 1
22661664 AAAZpJAAJAAAACNAAB 2
22661664 AAAZpJAAJAAAACNAAC 3
22661664 AAAZpJAAJAAAACNAAD 4
SCOTT@test01p> @ rowid AAAZpJAAJAAAACNAAA
OBJECT FILE BLOCK ROW DBA TEXT
---------- ---------- ---------- ---------- -------------------- ----------------------------------------
105033 9 141 0 9,141 alter system dump datafile 9 block 141 ;
SCOTT@test01p> alter system checkpoint ;
System altered.
SCOTT@test01p> alter system dump datafile 9 block 141 ;
System altered.
2.检查转储:
Block header dump: 0x0240008d
Object id on Block? Y
seg/obj: 0x19a49 csc: 0x00.159ca1f itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x2400088 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x000a.021.00005ad1 0x01400506.0549.0c --U- 4 fsc 0x0000.0159ca20
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
--//可以发现ITL=0x01 ,快速提交,Lck=4有4条记录.
3.修改记录看看:
update t set text=lpad('A',35,'A') where id=1;
commit;
alter system checkpoint ;
alter system dump datafile 9 block 141 ;
--//检查转储:
Block header dump: 0x0240008d
Object id on Block? Y
seg/obj: 0x19a49 csc: 0x00.159ca99 itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x2400088 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x000a.021.00005ad1 0x01400506.0549.0c C--- 0 scn 0x0000.0159ca20
0x02 0x000f.01c.00000271 0x0140037a.00bd.07 --U- 1 fsc 0x000f.0159ca9b
--//注意看fsc 前面部分 0x000f.
--//可以发现itl=0x01的flag=C---, Lck=0.
--//通过bbed观察也是一样:
BBED> p *kdbr[1]
rowdata[99]
-----------
ub1 rowdata[99] @8017 0x2c
BBED> x /rncc
rowdata[99] @8017
-----------
flag@8017: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8018: 0x00
cols@8019: 2
col 0[2] @8020: 2
col 1[50] @8023: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
--//可以发现lock=0x00,已经清除.
BBED> p kdbh
struct kdbh, 14 bytes @100
ub1 kdbhflag @100 0x00 (NONE)
b1 kdbhntab @101 1
b2 kdbhnrow @102 4
sb2 kdbhfrre @104 -1
sb2 kdbhfsbo @106 26
sb2 kdbhfseo @108 7818
b2 kdbhavsp @110 7834
b2 kdbhtosp @112 7849
4.继续测试:
--//如果我再次修改id=1的记录.应该会使用itl=0x01,因为修改记录都是id=1的记录,这样itl=0x02的槽会清除,flag会改为c,lck=0.
测试看看:
update t set id=1 where id=1;
commit ;
alter system checkpoint ;
alter system dump datafile 9 block 141 ;
Block header dump: 0x0240008d
Object id on Block? Y
seg/obj: 0x19a49 csc: 0x00.159cce9 itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x2400088 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0005.00c.00005b0e 0x014009b4.05a4.2b --U- 1 fsc 0x0000.0159ccf4
0x02 0x000f.01c.00000271 0x0140037a.00bd.07 C--- 0 scn 0x0000.0159ca9b
--//可以itl=0x02的信息已经清除,改为提交,lck=0. scn的前面部分变成了0.
--//通过bbed观察:
BBED> p kdbh
struct kdbh, 14 bytes @100
ub1 kdbhflag @100 0x00 (NONE)
b1 kdbhntab @101 1
b2 kdbhnrow @102 4
sb2 kdbhfrre @104 -1
sb2 kdbhfsbo @106 26
sb2 kdbhfseo @108 7818
b2 kdbhavsp @110 7849
b2 kdbhtosp @112 7849
--//kdbhavsp 增加 15. 7834+15=7849
--总结:
--主要是通过测试理解一些细节性的东西.
