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

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

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

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

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

    oracle在数据块上存储了ITL和锁定等事务信息，在事务提交之后，oracle必须清除这些事务数据。这就是块清除。块清除主要要清除的数据有行级锁和ITL信息。
    如果提交后，脏块仍在buffer cache里，那么oracle可以清除ITL信息，此之谓“快速块清除”。但这有个限制，若脏块超出10%，则对超出部分不再进行清除。
    如果提交后，脏块已flush到数据文件（或者超过10%的部分）oracle选择延迟块清除，等到下一次访问该块时再来清除ITL和锁定信息。oracle通过延迟块清除来提高数据库的性能，加快提交操作。
    需要注意的是，虽然这个事务已经提交，不可以回滚，但是在覆盖之前，这个前镜像信息仍然存在，通过某些手段，我们应该仍然能够得到这个信息。