一般的清除是COMMIT清除，当需要修改（DML）的块大于BUFFER CACHE的10%的时候就会出现
延迟块清除，在一般的OLTP系统不会出现这样的情况。以为修改的数据量巨大，执行COMMIT的时候
只会修改ITL FLAG信息(ITL FLAG信息是U，一般的COMMIT清除是C，在没有提交的时候是没有记录的就是-----）和SCN，而对于在行上LB信息就不会清除（这叫FAST COMMIT，也是为什么COMMIT及时在数据量
很大的情况下依然很快的原因），只有依靠下次的延迟的块清除，
延迟的块清除不但会导致SELECT语句生成REDO，而且会把原本干净的已经写入磁盘的
数据块，重新读入BUFFER CACHE，然后完成延迟块清除后重新写入磁盘，这就导致了
大量的不必要的物理写，清除其实就是清理块的头信息的ITL信息，ITL信息能够记录哪行被修改，
同时ITL.XID 能够对应事物信息，同时也能找到UNDO HEADER，
ITL.UBA能够找到UNDO块的信息
在行中的lb（lock BTTE）记录了ITL信息，也就是在ITL对应哪一行
Block header dump: 0x024014ed
Object id on Block? Y
seg/obj: 0x2e61 csc: 0x00.ec539 itc: 1 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 xid: 0x0005.000.00000805 uba: 0x00c02619.0304.01 ---- 1 fsc 0x0000.00000000
tab 0, row 0, @0x7aa
tl: 14 fb: --H-FL-- lb: 0x1 cc: 4
col 0: [ 2] c1 02
col 1: [ 4] 52 4f 57 31
