Cr块和latch buffer cache chain
Cr块consistent read 块也就是用来维护oracle的读一致性的数据块。当查询某些数据的时候，发现数据块的版本比我们要查询的新，例如session1执行了dml操作并没有提交，session2此时查找跟session1相关的dml操作的数据信息，此时查询的数据却是原来的数据信息。
查询的过程会在undo段中查找该数据块的前映像后，然后把前映像和current块合并形成了一个CR block，通过查询cr block就可以满足数据的一致性了。
CR block存在与sga的buffer cache中，在db cache里申请一个数据块，然后对应的回滚段的前映像生成cr block。
cr块的数量是由隐含参数_db_block_max_cr_dba控制的，默认是最高同时存在5个cr块，构造cr块时cr block created计数器都会增加1.
由于cr block和current block的数据块的rdba都是相同的，会放在相同的hash链上，当然某些block的cr block的版本过多，自然会引起hash链上的竞争，导致latch buffer cache chain闩竞争。
当然在利用回滚段的前映像和current block构造cr 块时，很有可能回滚段的已经被覆盖，也就会出现常见的ora-01555快照过旧。
一个sql语句如何去查询数据信息了，根据以前的latch基本记载知道获取该数据块的latch然后才能对该数据块进行读取，其实一个sql访问数据信息的数据块，需要像链接一样的结构中去收索这个数据块是否在内存中，此时访问链表也需要一个latch，如果获取失败也就是会产生latch buffer cache chain等待了。
Latch buffer cache chain等待：
访问相同的数据块的session太多了导致了latch等待，也可能是由于此hash列表的增长，导致扫描hash列表的时间会增加，持有cache buffer chain latch的时间就会变长，其他session获得latch的时间就会增加，导致了latch buffer cache chain
几个细节：
Cr块不会写入回滚表空间所在的数据文件
cr块是从undo表空间中来的，就会存在一个物理读
读一个块可能会或不会需要cr块
[@more@]来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/25362835/viewspace-1055564/ ，如需转载，请注明出处，否则将追究法律责任。
