看了biti的关于一致性读的文章。还是有些不明白。

假设这样一种情况，一个大查询开始FTS查询大表 ，然后另外一个session更新了表末尾的某条数据并提交，更新了N次 ，由于多次事务的DML使得该block上的相关XID和LOCK信息早已荡然无存 ，该记录行上的 XID 已经被设置为 0  了，也就是根本找不着  ITL 信息 ，那这样的情况下，oracle 是怎么找出事务的 before  image ?

如果查询开始后，一个快被update并提交了很多次，dump 块里itl都没有活动的了，记录项对应的lb 都是0x0了，这个时候怎么和undo entries 对应呢？

数据的前象是存放在undo中，自然可以存放n版本。只要不被覆盖掉总是可以找到的。

根据判断scn的，若果该块的scn大于select开始的scn则在undo中找，只要undo中的前像不被覆盖就能找到。

1 延迟块清除
  一个update commit 时，如果修改的块已经写进df 或修改的块大于10%buffer_cache size
  别写进df 的块或者大于10%buffer_cache 的块就会块清除
  在块下次被update 或select 的时候会根据block活动的事物表，找对应的undo header 如果这个事物提交了。
  就清楚block 的锁定信息，修改这个事物的scn 如果，undo header 的事物已经不是这个事物了，就取 undo header 中
  的scn 当作这个事物的scn (就是undo$中对应段的信息)，如果select 的 scn 小于这个 scn ，系统就不知道这个事物是在
  select 前还是后提交的，就会触发回滚段旧的错误。
3 一致性读
  查询发起后，找到一个快，首先看查询scn 是否小于块的scn 或者块中是否有active 事物，如果有active 事物，就构照 cr
  块，找到undo block信息回滚，如果 查询scn<block scn ，就根据block 中 的itl 中最后的事物向前回滚。因为查询发起后
  快可能进行了多次commit,在回滚到第一个itl末尾，如果还有另外的事物，会显示这个itl,接着在回滚这个itl,一直回滚到查询scn>
  快的scn，回滚过程中如果找不到undo 信息，就出现回滚段旧的错误。

这是我总结的，不知道对不对。

块的ITl事务槽会被写到回滚段中的。

在UNDO里可以找到。只要UNDO没有被覆盖掉