Oracle 中的buffer Cache 也就是 SGA 是影响ORACLE 数据库关键性能的地方之一。 数据的任何处理和输出，都是通过内存来进行的，包括UPDATE ，INSERT 一个数据都会将数据先调入到内存中，然后处理，处理后再刷入到磁盘中。（这个过程很复杂，每种数据库都在这个位置有自己独门的处理方式，也就有了性能的高低之分）
Oracle 在这方面的处理是十分精妙的，在ORACLE 11G 中，buffer cache 中数据的提取原理
1 ORACLE 中所有的内存中的操作和寻址都离不开 HASH 算法
2 ORACLE 中的文件（磁盘）的数据库BLOCK 到内存中 buffer cache 是通过计算HASH 值后，将数据放入到 buffer cache 中的，通过 bucket 表来进行寻址，快速获得数据。
3 HASH 算法都有一个重复的问题，一个HASH 寻址可能会有多个数据，ORACLE 通过双向链表来解决数据的地址重复冲突
下图，ORACLE 通过HASH 算法根据FILE_ID 和 blocked_id 将磁盘映射的数据放在BUFFER CACHE 中，在查找数据是，通过FILE_ID BLOCKED_ID 将以及 Buffer Address (内存地址)， 来将数据和快速定位的指针进行绑定，通过快速的HASH 查询将获得内存的数据。
但再好的设计，也会因为数据量和复杂度的关系，产生问题。 这样的设计带来的问题就是 cache buffers chain latch 的竞争。
一个 CBC (cache buffer chain) 可以保护多个 bucket 到 双向链表的锁，（内存中也有共享锁和独占锁）
在ORACLE 中，很可能会多个bucket 连接通过一个 CBC ，这就会有一个争用（主要还是内存太贵，如果内存便宜其实每个连接都有自己的CBC 更好），这就会产生一个争用，可能 2 3 同时使用需要访问内存，但CBC这是明显就是瓶颈所在，幸好ORACLE中有共享，如果是读的情况，则CBC锁很快会释放，只要相关的锁添加到 BH 中（BH，就是蓝色的地方 BUFFER HEADER）， 则CBC 就会释放，虽然有这样的设定但还是避免不了争用和竞争。
1多个进程频繁的调用 CBC 访问不同的 链表产生 LATCH，这叫做热链竞争
2 多个进程频繁的调用CBC 访问同一个链表的不同 BH，这叫做热块竞争
相关的热链竞争可以通过调整参数进行调整，而最难解决的是热块竞争，所以ORACLE 中的表设计，表空间安排，良好的SQL 都可以缓解热块的竞争，但不能根治。
重点：ORACLE 之所以能做到读不阻塞写，主要的原因就是在当 A 进程在读内存块1时，如果有B 进程要修改内存块1时，相关内存系统会将 A 读到的内存块，进行克隆，然后将克隆后的内存块给 B 进程（DML）使用，这时两个读写进程就相安无事了。
此时如果再有C 进程，还想读内存块 1时，ORACLE的特异功能也不能再拯救这样的操作，因为此时ORALCE 已经将 内存块 1 加了 XCUR 锁，，进程C只能被阻塞，等待内存块1 被修改完毕。
这个阻塞就叫做 buffer busy waits . 所以在ORACLE (其实其他数据库也一样)， DML 操作的缓慢是让数据库性能下降的 根源之一
一般ORACLE 解决这样的问题，可以通过打散数据，进行HASH 分区来尽量环境这样的情况。
碎觉！
