oracle 延迟块清楚,关于延迟块清除的原理是什么?为什么要进行块清除

论坛上有人问这样一个问题，我以前也是不是太理解，只知道当一个大的事务需要处理的时候，进行延迟块清除，这样加快处理速度．但是今天感觉这个解释比较容易理解．

delay block cleanout :

主要针对大事务，可能在commit的时候，一些数据脏快已写入数据文件，提交时，无法把这些数据块标记commit,该数据块的下一个读者对其进行delay block cleanout 。数据块的下一个读者首先检查该块的事务状态是否为活动，不活动的话，修改事务的标志(flag)。这样可以避免不必要的事务读。

对于为什么要用最小的scn更新itl，对于查询安全要怎么理解 ：

commit 的时候没有来得及更改这个block(delay block cleanout)，事后cleanout 的时候已经找不到当时对应的scn了，但是，从回滚段中可以得到一个最小的提交scn并且该事务已经提交肯定小于这个从回滚段中还存在的最小scn。那么oracle给这个 cleanout 的事务分配一个从回滚段中找到的最小事务scn。这虽然不准确，但是是安全的，对于数据访问也不构成影响。所以叫 upper bound ,猜测的一个scn的上限。

cleanout分为2钟，一种是fast commit cleanout,另一种是delayed block cleanout.

oracle有一个modified block list结构，用来记录每个transaction更改过的block，每个transaction大约可以记录10%buffer cache这多的modified block。(即为每个事务可记录的modified block大约是buffer cache的10%)这部分block就是当发生commit的时候，oracle可以根据modified block list定位到那些块并做fast commit cleanout。如果一个transaction修改的块超过10% buffer cache,那么超过的块就执行delayed block cleanout。当做fast commit cleanout时，oracle不会清理 Row locks lb标志位，ITL lck标志位。

另一种情况是delayed block cleanout，当transaction还未commit或rollback时modified block已经被写回磁盘，当发生commit时oracle并不会把block重新读入做cleanout，而是把cleanout留到下一次对此块的dml或select。当delayed cleanout时候如果undo segment header的transaction table slot还没有被覆盖，那么可以找回该事务递交的exact scn，如果slot已经被覆盖，那么将会使用undo segment header中的control scn来做为upper bound scn。

针对读一致性考虑：

每个数据头部都会记录一个提交ＳＣＮ，当数据更改提交后，提交scn同时被修改，这个scn在查询时可以用来进行一致性判断．

假如：查询开始时间为Ｔ１，则在查询获取的数据块中，如果数据块的提交scn小于T1,则oracle接受该数据，如果提交的scn大于t1或者数据被锁定修改尚未记录commit　scn，则oracle需要通过回滚段构造前镜像来返回结果．

关于ORA-01555的理解：

如果当一个查询触发延迟块清除的时候，ORACLE 需要去查询回滚段获得该事务提交的ＳＣＮ，如果事务前镜像信息已经被覆盖，并且查询的ＳＣＮ小于回滚段记录中记录的最小提交ＳＣＮ信息，那么oracle将无法判断查询的scn和事物提交scn的大小．

如果当一个查询触发延迟块清除的时候，ORACLE 需要去查询回滚段获得该事务提交的ＳＣＮ，如果事务前镜像信息已经被覆盖，并且查询的ＳＣＮ大于回滚段记录中记录的最小提交ＳＣＮ信息，则将commit 标记为 回滚段中所能找到的最小 scn(对于查询安全)．