oracle事务槽（二）

oracle数据块头部有个事务槽（ITL）。当多个事务槽同时修改数据块，而且，此时，pctfree（数据块空闲空间的比例）不足10%，则会出现ITL争用。这种现象容易发生在update和delete身上。因为，insert时，oracle会优先分散地插入其他空闲块。如：

 

 

    看一下表a有多少个事务槽：

[sql] 

sys@ORCL> select ini_trans,max_trans from dba_tables        

  2        where owner='HR' and table_name='A';  

  

 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是不会覆盖的。