http://blog.csdn.net/biti_rainy/article/details/34554
同一个BLOCK中的数据，只要有一条被更新，即使只查询没有被更新的数据,甚至通过索引直接由 ROWID 查询数据，我们可以想象为根本就不看被更新的数据一眼，但是，依然会产生 CR block
CR并不是因为查看到的数据被更改过才去产生一致读，而是只要block里面存在活动事务、或者 block SCN > 查询SCN 都会产生 CR block
若存在没有活动的事务但是还没有产生commit SCN 的（ITL 中 fsc 项为0） 则先产生 delay block cleanout
0×1 xid: 0×0005.040.00000117 uba: 0x0080233e.01f9.11 –U- 10 fsc 0×0000.0272a3b7
XID 是当前事务的事务表信息
而 uba 该事务的回滚段的地址
回滚段中记录的关于block的改变，除了数据的改变还有 ITL 的改变
所以根据当前 ITL 信息可以产生CR block，CR block 里面包含了原来的ITL信息， 这样根据before ITL 信息产生 CR block ,这个CR block 里面包含了before ITL ,这样又继续重复这个过程，直到 commit scn 都小于 查询SCN 的 block 或者不再有ITL为止，产生 CR 的过程结束，若没有找到就返回 1555 错误
当然，不一定非要是查询到的记录上有XID 信息，这依然成立,行上的 lock 主要是针对 DML 起作用
对于select 是以时间点为准的，对于 DML 不是以时间点为准的，也就是说current mode ,当前看见的是什么就是什么，而不管时间点的一致性和过去是什么
query mode ——– consistent gets
current mode ——– db block gets