undo系列学习之深入浅出事务槽

undo表空间有个脾气，就是新事务优先，长查询滞后！

情况有两：查询在前、查询在后

查询在后：

if [查scn>提交scn]

if [查sid = 提交 sid]

返回新值；

else

返回旧值；

end if；

查询在前：

第一个if条件就不满足，直接跑去构造CR块。

如果在整个交易的过程中，运行了很长时间，但突然在交易尾巴出错了，则只是单独rollback这一个，而不是整个交易全部回滚掉。

工业环境，undo表空间布局的原则是：以空间换时间！也就是undo表空间当尽量大。保持自动扩展，且要注意maxsize。

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

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

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个

看一下表a用了多少个数据块：

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：

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部分内容摘入如下：

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

 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，然后再访问数据行。

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是不会覆盖的。而且，延迟释放锁！