http://m.blog.itpub.net/12679300/viewspace-1244578/
Buffer Cache是SGA的一部分，Oracle利用Buffer Cache来管理data block，Buffer Cache的最终目的就是尽可能的减少磁盘I/O。 Buffer Cache中主要有3大结构用来管理Buffer Cache：Hash Bucket、Hash Chain List、LRU List；
Hash Bucket & Hash Chain List：Hash Bucket与Hash Chain List用来实现data block的快速定位。 注意：Hash Chain结构是在共享池中，使用典型内存结构Bucket->Chain->Header结构进行管理。而实际缓冲区信息存储在高速缓冲区中。
LRU List：挂载有指向具体的free buffer, pinned buffer以及还没有被移动到 write list的dirty buffer 等信息。所谓的free buffer就是指没有包含任何数据的buffer，所谓的pinned buffer，就是指当前正在被访问的buffer。
Write(Dirty)List：挂载有指向具体的 dirty block的信息。所谓的dirty block，就是指在 buffer cache中被修改过但是还没有被写入到磁盘的block。
用户内存中读数据的顺序：
a) 对该Block运用Hash算法，得到Hash值。
b）获得cache buffers chains latch
c) 到相应的Hash Bucket中搜寻相应Buffer Header
d) 如果找到相应的Buffer Header，然后判断该Buffer的状态，看是否需要构造CR Block，或者Buffer处于pin的状态，最后读取。
e) 如果找不到，就从磁盘读入到Buffer Cache中。
逻辑读的过程
1、Oracle以每个块的file#+block#和类型做HASH运算,得到HASH值。根据HASH值，到HASH表中取出指定块的内存地址
2、获取CBC Latch(实验的重点测试部分)
3、根据HASH值,搜索CBC链表
4、根据DBA找到BH(Buffer Header)加Buffer Pin
5、加完Buffer Pin马上释放CBC Latch
6、访问Buffer开始fetch数据
7、获取CBC Latch
8、释放Buffer Pin
9、释放CBC Latch
latch: cache buffer chains:
一个cache buffers chain Latch管理多个Hash Chain。 当多个进程同时检索Buffer Cache时，获得cache buffers chain Latch的过程中发生争用，就会产生 latch: cache buffers chain等待事件。
现象：大量的latch: cache buffers chains等待事件导致系统消耗量大量的CPU，最终导致系统hang住。
原因：1） 执行效率低下的SQL语句，多个进程同时扫描大范围的表或索引时；2）热点块争用；3）Hash Bucket太少；4）Hash Chain太长，扫描列表时间长；
总结以上的特征：
a) 占用大量的CPU资源；
b) 逻辑读比正常情况要多很多；
c) 等待事件里面肯定有latch: cache buffers chains
d) Latch的命中率一般在95%以下，严重的在90%以下；
http://blog.itpub.net/12798004/viewspace-1818231/
在Oracle9i以前，如果其它用户进程已经获得了这个latch，那么新的进程就必须等待，直到该用户进程搜索完毕(搜索完毕之后就会释放该latch)。从Oracle9i开始 cache buffers chains latch可以只读共享，也就是说用户进程A以只读(select)的方式访问Block，这个时候获得了该latch，同时用户进程B也以只读的方式访问Block，那么这个时候由于是只读的访问，用户进程B也可以获得该latch。但是，如果用户进程B要以独占的方式访问Block，那么用户进程B就会等待用户进程A释放该latch，这个时候Oracle就会对用户进程B标记一个latch:cache buffers chains的等待事件。
free buffer waits：是由于无法找到可用的buffer cache 空闲区域，需要等待DBWR 写入完成引起
- 一般是由于
- 低效的sql
- 过小的buffer cache
- DBWR 工作负荷过量
buffer busy waits：
read by other session：
buffer busy wait/ read by other session 一般以上2个等待事件可以归为一起处理，建议客户都进行监控 。 以上等待时间可以由如下操作引起
- select/select —- read by other session: 由于需要从 数据文件中将数据块读入 buffer cache 中引起，有可能是 大量的 逻辑/物理读 ;或者过小的 buffer cache 引起
- select/update —- buffer busy waits/ read by other session 是由于更新某数据块后 需要在undo 中 重建构建 过去时间的块，有可能伴生 enq:cr-contention 是由于大量的物理读/逻辑读造成。
- update/update —- buffer busy waits 由于更新同一个数据块（非同一行，同一行是enq:TX-contention） 此类问题是热点块造成
- insert/insert —- buffer busy waits 是由于freelist 争用造成，可以将表空间更改为ASSM 管理 或者加大freelist 。
latch: in memory undo latch
write complete waits