CR (consistent read) blocks create 说明

网上google的资料，之后的结果，之前网页打不开：

The CR blocks created：Oracle metric is the number of CURRENT blocks cloned to create CR (consistent read) blocks. The most common reason for cloning is that the buffer is held in an incompatible mode.

Read consistency is used when competing processes are reading and updating the data concurrently.

The gc cr block receive time：Oracle metric is theglobal cache cr block receive timestatistic records the total time required for consistent read requests to complete. In other words, it records the accumulated round-trip time for all requests for consistent read blocks.

白鳝的Blog里解释，连接如下：

http://www.oraclefans.cn/forum/showblog.jsp?rootid=3276

当我们想要查找某个数据的时候，发现这个数据块的版本比我们要查找的要新，那么我们只能从UNDO中去查找这个数据的前映像（PRE IMAGE），在回滚段中找到这个数据的前映像后，把前映像和CURRENT的数据块合并，就形成一个CR BLOCK，这样，通过查询CR BLOCK就可以得到一致性的数据了。

这个CR BLOCK的生成不是在PGA里进行的，而是要在DB CACHE里申请一个数据块，然后生成CR BLOCK。这个CR BLOCK创建后，如果下一回还要访问这个版本的数据块，那么就不需要创建新的CR BLOCK，而直接可以使用以前创建的CR BLOCK了。每创建一个CR BLOCK，CR BLOCKS CREATED计数器就会增加1。

由于CR BLOCK和CURRENT BLOCK的RDBA都是相同的，因此它们会被放到相同的HASH链上。因此如果某些BLOCK的CR BLOCK的版本过多，也会导致BUFFER CACHE CHAINS闩锁竞争加剧。

有关RDBA的说明，参考我的Blog：

Oracle rdba和dba说明

http://blog.csdn.net/xujinyang/article/details/6829256

如果在生成CR BLOCK的过程中，发现UNDO中的PRE IMAGE由于提交的时间比较长，已经被覆盖，那么，就会出现著名的ORA-1555。

如果单位时间内CR BLOCKS CREATED较大，那么应该检查系统的CPU资源是否出现瓶颈，另外要注意检查BUFFER CACHE相关的闩锁，是否存在竞争。

bufferCachechian产生原因：

当一个会话需要去访问一个内存块时，它首先要去一个像链表一样的结构中去搜索这个数据块是否在内存中，当会话访问这个链表的时候需要获得一个Latch，如果获取失败，将会产生Latch cache buffer chain等待，导致这个等待的原因是访问相同的数据块的会话太多或者这个列表太长（如果读到内存中的数据太多，需要管理数据块的hash列表就会很长，这样会话扫描列表的时间就会增加，持有chache buffer chain latch的时间就会变长，其他会话获得这个Latch的机会就会降低，等待就会增加）。

有关Latch的更多说明，参考Blog：

Oracle Latch说明

http://blog.csdn.net/xujinyang/article/details/6832692

-------------------------------------------------------------------------------------------------------