在Oracle中数据锁(这里主要指TX类型行锁)实际上是数据的属性，存储在块首部，称之为事务槽(ITL)。COMMIT操作的职责包括释放块上的锁，实际的释放方式即清除块上相应的事务槽，但这里存在一个性能的考量。设想一个UPDATE大量数据的操作，因为执行时间较长，一部分已修改的块已被缓冲池flush out写至磁盘，当UPDATE操作完成执行COMMIT操作时，则需要将那些已写至磁盘的数据块重新读入，这将消耗大量I/O，并使COMMIT操作十分缓慢;为了解决这一矛盾，Oracle使用了延迟块清除的方案，对待存在以下情况的块COMMIT操作不做块清除：
在更新过程中，被缓冲池flush out写至磁盘的块
若更新操作涉及的块超过了块缓冲区缓存的10%时，超出的部分块。
虽然COMMIT放弃对这些块的块清除(block cleanout)操作，但COMMIT操作仍会修改回滚段的段头，回滚段的段头包括了段中的事务的字典，COMMIT操作将本事务转化为非ACTIVE状态。
当下一次操作如SELECT,UPDATE,INSERT或DELETE访问到这些块时可能需要在读入后完成块清除，这样的操作称之为块延迟清除(deferred block cleanout);块延迟清除通过事务槽上的回滚段号，槽号等信息访问回滚段头的事务字典，若事务不再活跃或事务过期则完成清除块上的事务槽，事务槽清除后继续执行相应的操作。
块延迟清除的影响在SELECT操作过程中体现的最为明显。总结来说块延迟清除是COMMIT操作的一个延续，始终是一种十分轻微的操作，且该种操作是行级的，不会使段(Segment)的属性有所改变。
案例分析：
场景一：
会话一更新一小表，更新的block数小于db_block_buffers*10%，当会话一进行commit时，更新的block还存在于buffer cache中。
由于更新的块数较少，Oracle采用SO(state block)列表来管理更新块。SO主要包括了更新块的事物状态信息。
当会话一进行提交时，会从SO列表中获取更新块的事物信息，从而进行更新块的事物信息清理。清理主要包括块头itl状态列的更新(Flag，Lck ，Scn/Fsc)和行锁标记的清理。Oracle对于这种块清理称之为快速块清理。(Fast Block Cleanout)。
发生延迟块清除后，块头的Flag往往显示如下：
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0009.01f.0000bed8 0x04c00016.13bf.28 --U- 3 fsc 0x0000.063f1a51
其中U表示upper bound(上界)，意味着快速块清除。
场景二：
会话一更新一大表，更新的blocks数大于db_block_buffers*10%，当会话一进行commit前，部分更新的block由于种种原因已经刷新至至数据文件。
当会话进行commit时，Oracle对存在于SO列表的更新块进行快速块清理，同时更新undo segment head中的事物槽(将事物槽state标记从10置回9，表示该事务已经提交)。
但需要注意的是，Oracle在commit时，并不会处理已刷新在数据文件中的block(此时数据块头还flag标记仍然显示未提交状态，Lck依然显示该块中行锁的行数，Scn/Fsc为空，行锁标记依然为lb: 0x2)。
Oracle采用此方进行提交时，并不需要再次将该事务涉及到的block从物理文件中读取，而只需要进行快速块清理和更新undo segment head中的事物槽即可。从而保证提交的性能最优化。
当有另一会话再次读取已刷新至数据文件的block时，如果发现此block itl列表有未提交事物时，那么Oralce将进行延迟块清除(defered block cleanout)。
当进行延迟块清除时，Oracle将获取数据块中未提交事物的xid中的seq和undo segment head中事物槽的seq进行比较。
如例子所示，数据块的ITL显示如下：
ITL Xid Uba Flag Lck Scn/Fsc
0x01 0x0009.018.0000bdd4 0x04c00016.13a5.32 C-U- 0 scn 0x0a00.063f0838
0x02 0x0009.01f.0000bed8 0x04c00016.13bf.28 ---- 3 fsc 0x0000.00000000
undo segment head的和此事物相关的事物槽显示如下：
index state cflags wrap# uel scn dba
---------------------------------------------------------------
0x1f 9 0x00 0xbed8 0xffff 0x0a00.063f1a51 0x04c00016
undo segment head的事物控制列表如下：
TRN CTL:: seq: 0x13c0 chd: 0x002d ctl: 0x001f inc: 0x00000000 nfb: 0x0000
mgc: 0x8201 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x04c0000d.13c0.04 scn: 0x0a00.063f17f1
事物控制列表中scn主要表示事物槽被覆盖前的scn。
如上所示ITL 0x02中有未提交事物，那么首先会获取0x02事物中xid(回滚段为0x0009，事物槽为0x01f，seq为 0000bed8)和undo segment head对应事物槽比较(主要比较xid.seq和事物槽的wrap#)。
如果两者相等，那么进行延迟块清除时，Oracle将获取事物槽中的scn写往ITL列表中的Scn/Fsc列。
如果两者不相等，这里分为两种情况：
1、undo的事物槽被其他事物覆盖，那么进行延迟块清除时，Oracle将获取undo segment head的事物控制列表的scn写往ITL列表中的Scn/Fsc列。
这里需要注意的是,此时的scn并不是事物提交时的真正scn，而且肯定比事物提交时的scn大，那这样会不会影响事物一致性呢，接下来例子会进行说明。
2、undo表空间被删除，此时undo$并不会将此表空间删除，只会将STATUS$从2改为1，而且每个undo segment依然保留着最近一次提交的scn。如下所示
SQL> select SCNBAS,SCNWRP,STATUS$,file#,name from undo$;
SCNBAS SCNWRP STATUS$ FILE# NAME
---------- ---------- ---------- ---------- ------------------------------
258954408 2560 1 13 _SYSSMU127$
258954399 2560 1 13 _SYSSMU128$
258954395 2560 1 13 _SYSSMU129$
258954404 2560 1 13 _SYSSMU130$
那么进行延迟块清除时，Oracle会去undo$中对获取对应的undo segment中的scn写往ITL列表中的Scn/Fsc列。
同样需要注意的是，此时的scn并不一定事物提交时的真正scn，可能会比提交的scn大。发生延迟块清除后，块头的Flag往往显示如下：
ITL Xid Uba Flag Lck Scn/Fsc
0x01 0x0009.018.0000bdd4 0x04c00016.13a5.32 C-U- 0 scn 0x0a00.063f0838
其中C表示该事物已结束，U表示Upper bound(上界)，C-U-往往表示延迟块清除。 |
