作者：杨子忧愁_347 | 来源：互联网 | 2014-07-11 17:33
undo系列学习之深入浅出事务槽oracle数据块头部有个事务槽（ITL）。当多个事务槽同时修改数据块，而且，此时，pctfree（数据块空闲空间的比例）不足10%，则会出现ITL争用。这种现象容易发生在update和delete身上...SyntaxHighlighter.al
undo系列学习之深入浅出事务槽
oracle数据块头部有个事务槽（ITL）。当多个事务槽同时修改数据块，而且，此时，pctfree（数据块空闲空间的比例）不足10%，则会出现ITL争用。这种现象容易发生在update和delete身上。因为，insert时，oracle会优先分散地插入其他空闲块。如：
看一下表a有多少个事务槽：
[sql]
sys@ORCL> select ini_trans,max_trans from dba_tables
2 where owner=&＃39;HR&＃39; and table_name=&＃39;A&＃39;;
INI_TRANS MAX_TRANS
---------- ----------
1 255
缺省下是1个，最多可以有255个
www.2cto.com
看一下表a用了多少个数据块：
[sql]
hr@ORCL> select dbms_rowid.rowid_relative_fno(rowid),
2 dbms_rowid.rowid_block_number(rowid),
3 id
4 from a;
DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) ID
------------------------------------ ------------------------------------ ----------
4 460 1
4 460 2
4 460 3
4 460 1
可知：表a在4号文件上，第460个数据块。
可以把id=2，数据块为460的4号文件dump出来，看一下块头的ITL：
www.2cto.com
[sql]
alter system dump datafile 4 block 460
sys@ORCL> select spid from v$process where addr in (select paddr from v$session
2 where sid in (select sid from v$mystat where rownum=1));
SPID
------------
10696
ITL部分内容摘入如下：
[sql]
Block header dump: 0x010001cc
Object id on Block? Y
seg/obj: 0xce9d csc: 0x00.15a47b itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x10001c9 ver: 0x01 opc: 0
inc: 0 exflg: 0
www.2cto.com
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0003.025.000001fa 0x01c00566.0293.1e ---- 2 fsc 0x0000.00000000
0x02 0x0004.020.00000151 0x0080068f.0144.11 C--- 0 scn 0x0000.000f71fa
注释：
Itl：事务槽编号
Xid：指向事务表
Uba：指向具体的回滚块
Flag：是否已提交
Lck：锁定的标志
Scn/Fsc：提交的时间点
假定此时有两个事物，T1和T2：
当一个事务修改了很多个块，oracle采用只更新undo segment header的事务信息，而数据块头部的信息不更新，或者进行少量更新。可见，事务信息最具可信度的当属undo段头部的事务表了，它里面的事务信息最真实的反应了事务的状态。这也是为什么有时候select也会产生redo的原因。
数据行被T1加锁，T2要修改数据行时，发现有锁定标志，就到ITL中找到T1，查看Flag，此时有两种情况：
1）已提交：那么T2会把数据行的行头锁给削掉（通常锁是不会被及时清除的），这个行为会产生redo，然后再访问数据行。 www.2cto.com
2）未提交：如果是未提交，T2就会怀疑了，是不是真的？因为他不相信T1,此时，他秉承“绝知此事要躬行”的良好态度，通过T1的xid找到undo段的段头的事务表，去看下事情的真实情况，此时也有两种情况：
2.1）已提交：那么这下子T2就心死了，回来后，把T1的相关事务信息清空，并且，把行头的锁也给削掉，这个行为产生redo。
2.2）未提交：那么T2就确定了该行确实上头有人啊...动不得哈,回来后，通过T1的xid找到回滚块，将剩余未提交的行和在回滚块中的行，重构一个CR块，然后直接读取CR块。
假设这时，T2要找的是8号段，第15行，第13次被覆盖的块所对应的事务是否已提交，如果T2找到的却是8号段第13行的第15次被覆盖的事务，则oracle会果断的认为，该事务已经提交了，因为没有提交的事务为active，oracle是不会覆盖的。
作者 linwaterbin
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 
