有关延迟块儿清除、快照过旧、读一致的总结

有关延迟块儿清除、快照过旧、读一致的总结，希望把这三个知识点串联一起做个总结，没有巨细无遗的写完每个地方，欢迎大家一起讨论，如果有前辈指出错误的地方更是不胜感激。

Blockcleanout 并不是指把脏块儿写入磁盘，只是单纯的指把DB buffer中一个块从 dirty 变为 clean，表明这个块里面的数据是干净的、最新的，本质上是更新 block header 中的一个标志位——ITL(Interested Transaction List)和block
SCN。

什么是delayed block cleanout？

每当事务commit 时，事务修改过的块儿就会被 cleanout，不过Clean out有2种方式:fast commit cleanout和delayed blockcleanout。

        1.fastcommit cleanout 算是真正意义上的 cleanout，当做fast commit cleanout时，Oracle将事务commit
时的系统scn作为commitSCN，马上更新block上 ITL 、block scn 和 undo segment header的Transaction table的slot（槽）上的 scn，三者是一致的。

        2.delayedblock cleanout 是将 cleanout 操作延后了，由于某些原因只是用commit SCN更新了undo segment header 的 Transaction table 上的slot scn，而并未做block上的更新，等待下次使用此block的时候，再用undo
segment header 的 Transaction table 上的slot scn（与之前事务的commit SCN相同）去更新 block scn 和 ITL。（当下一次操作如SELECT,UPDATE,INSERT或DELETE访问到这些块时需要在读入后完成块清除）

    为什么要执行delayed block cleanout呢？

        这是出于性能考虑的，我们首先来看哪些块会做delayed block cleanout

    前提：Oracle有一个modifiedblock list 结构（checkpoint queue机制？），用来记录每个transaction更改过的block，每个transaction可以在这个list上面记录大约10%buffercache这多的modified
block。

       事务commit 时：

更改过的block低于10%，则oracle可以根据modified
block list定位到那些块并做fast commit cleanout。

更改过的block超过10%，则超出部分就做delayed
block cleanout。

未commit前，由于事务耗时太长已经被写至磁盘的块做delayed block cleanout。

    这里就可以看出，不立即cleanout 的原因有二，但本质都是不能立刻在DB
4000
buffer中找到对应的块儿，前者是超出10%，没有在list中记录，后者是已经写入磁盘，如果再重新读回DB buffer再修改，IO太多，都影响性能。

    和快照过旧是什么关系？

    前提：别的会话用过这个块儿（clean），或者正在占用这个块儿（dirty），都会在块儿上记录ITL（itl、xid、flag、uda、scn\fsc）。

   1.当发出一条select语句时，ORACLE会记录下这个时刻SCN,然后在buffer cache中查找需要的BLOCK,或者从磁盘上读。

   2.首先要查看最近一个修改这个块的事务的flag，如果需要cleanout 就马上执行。如果执行成功或者不需要执行就接着比较ITLSCN和select SCN，如果ITL SCN > select SCN,证明块儿的版本是比要select的新，要执行读一致找旧版本。

   3.ORACLE就会根据ITL中的uba找到UNDO信息获得该block的前镜像，然后在buffercache 中构造出CR块，此时ORALCE也会检查构造出来的CR块儿中ITL记录的SCN，如果SCN还大于select时刻的SCN，那么一直重复构造前镜像，直到找到需要的块儿，这样ORACLE就实现了多版本。但如果在构造前镜像的过程中所需的UNDO信息被覆盖了，就会报快照过旧的错误。所以简单来说，是利用递推方式去找到和自己select同一SCN的那个块儿的版本，如果找不到就是快照过旧。

    而对于延迟清除的块儿，尽管对应的事务已经commit，但自己本身还是dirty状态。之前commit的时候只是更新undo segment header的Transaction table的slot（槽）上的 scn，而块儿自己的itl 和 block scn却没有更新。当再次访问到这个块儿的时候，肯定要完成剩余的工作，即上面第二步说的马上cleanout——更新这个块儿的itl scn
和 blockscn。之前说过，如果clean执行成功就接着比较ITL SCN和selectSCN来决定是否需要要执行读一致。但如果因为undo被覆盖，就获得不了commit SCN，连cleanout也不能执行，也就比较不了大小了。报错还是快照过旧。