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通过延迟块清除来提高数据库的性能，加快提交操作。
需要注意的是，虽然这个事务已经提交，不可以回滚，但是在覆盖之前，这个前镜像信息仍然存在，通过某些手段，我们应该仍然能够得到这个信息。
