原文: DBA的思想天空- p31
- DB Cache是以 Block为单位组织的缓冲区，不同的 Block Size的数据块对应于不同的 DB Cache。从 Oracle9i开始，RDBMS 支持多种不同块大小的表空间，如果我们要使用它们就必须为这种特殊的数据块大小的数据文件设置单独的缓冲池。而默认的 DB Cache、Keep Pool、Recycle Pool只能用于默认块大小的表空间
- 用户访问 DBCache的数据比访问磁盘上的数据，速度要快数十倍甚至上百倍，因此应用系统应该尽可能多地从 DBCache 中访问数据。在大多数情况下,DBCache 的命中率越高访问性能就越好。
- 数据库刚刚启动时，DBCache中几乎没有用户数据的缓冲(除非在系统级触发器中做了事先加载)，当会话访问数据库的表和索引时，首先会检查DBCache中是否存在该数据如果不存在，就会从数据文件中读取该数据块到DBCache，然后再从DBCache中读取该数据。
- 定位 DB Cache中的数据块是通过散列算法实现的，对于DB Cache来说，Oralce 为了提高数据块定位的速度，为其设计了一个Hash链结构，将整个DBCache 中正在使用的数据块都放置到 Hash链上，这个 Hash链是由多个 Bucket组成的多链结构，每个 Bucket 就是一条链的链头，从链头引出一条独立的双向链。Oracle还设计了一个算法，通过数据文件的文件号和数据块的块号，进行一个散列运算，得到的散列值就是这个数据块所在的Bucket 的号码。
- 如果要查找某个数据块，通过散列算法，算出这个数据块所在链的链头Bucket 的位置，就可以很快地找到链头，从链头的双向链表结构扫描下去，即可找到相关的数据块。Bucket 的数量是固定的，一旦数据库启动后就不会改变，Bucket的数量由参数_DB_BLOCK_HASH_ BUCKETS确定，8i的认值是2 x DB BLOCK BUFFERS,也就是 Bufer 数量的两倍，9i的默认值是大于两倍 DB Block Bufer数量的最小素数，10g的默认值是大于两倍 DB Block Bufer 数量的最小的2的幂次的数值。
- 虽然 Oracle 的每个版本对该参数的定义略有不同，但是有一点是不变的，就是数据库缓冲区的Hash Chains的 Bucket的数量始终大于 DB Buffer数量的两倍。虽然我们无法获得 Oracle 内部散列算法的详细细节，但是有一点是肯定的，Oracle设计 Hash链的基本思路是，每个链上有最少的 Buffer数量，最佳的情况是每条链上只有一个 Buffer。
- 普通会话只读取和修改 DBCache,不负责将脏数据写人磁盘,该操作一般是由 DBWR后台进程来完成的。
- 如果某个会话要访问的数据当前已经被更改了，而这个会话需要访问该数据的前映像(Pre-lmage),那么可以通过 UNDO中保存的数据,结合当前的数据块,生成一个 Pre-lmage的数据块缓冲，这个数据块缓冲是针对同一个数据块的不同版本，因此它将和当前的数据块存放在相同的 Bucket上，也就是同一条Hash链上。也就是说，在DB Cache中，同-个数据块可能存在多个版本，这些版本都存储在同一条 Hash链上。
- 访问 Hash链时，为了保证数据访问的一致性，通过 cache buffers chains 闩锁来保护 Hash链的数据结构。因此如果出现cache bufers chains闩锁争用，那么一般来说都和 Hash 链的访问有关。如果碰到该闩锁等待十分严重，首先应该检查是否存在逻辑读(bufer get)十分高的 SQL，看看这些SQL的执行计划是否存在问题，是否对大表做了全表扫描。此外，较严重的热块冲突也会加大 cache bufers chains 闩锁的争用，这一点也需要注意
- 除了 Hash链外，DB Cache另外一个十分重要的链是 LRU链，如果某个会话需要分配一个数据块缓冲区用于存放一个新的数据时，就会从LRU链上查找。实际上，LRU链是多条链的总称，包含 LRU、LRU-W和 LRU-AUX等链，不过对于大多数 DBA来说，不需要很深人地了解 LRU的内部原理，只要知道 LRU链是一种以类似 LRU算法组织的链,最近不被使用的缓冲区会被最先重用即可。
- 确实，早期的DBCacbe在LRU上是会移动的，常用的缓冲会被换到 LRU的热端，不常用的缓冲会被挤到LRU的冷端，一般来说会话分配 Cache 时，会从 LRU 的冷端开始查找。在冷端找到脏块就把脏块移到LRU-W(DBWR的任务就是将LRU-W中的脏数据写人文件，然后将这些缓冲区从LRU-W上释放，变为可用缓冲)，找到没有被PIN住的非脏块，就完成了缓冲区的分配操作。
- 从 Oracle8i开始，LRU的算法有所改进，LRU链上的缓冲不再需要移动了，而是通过tch计数器来判断某个数据块是否为热块。改进后的算法，当会话在LRU上分配缓冲时，还是从 LRU的冷端开始查找，如果查到的某个非脏的缓冲区是热块(根据tch值的高低判断是否为热块 )，就会跳过这个热块继续往下查找。
- LRU链通过 cache buffers lru chains来保护，因此针对LRU链的操作都要使用该闩锁。如果该闩锁发生较为严重的争用，说明数据块缓冲的分配操作出现了性能瓶颈，大多数情况下，DB Cache容量不足都可能导致该闩锁严重争用。另外，如果数据库缓冲出现了严重的抖动(比如，某个SQL扫描了一张大表，几个的数据块被读入缓冲，不过这些缓冲只使用一次，很快就会被其他数据换出，如果经常出现类似的情况，数据库缓冲的抖动就会很严重)，也可能导致该闩锁争用的加剧。
- Oracle 的多缓冲技术可以有效地避免数据库缓冲区的抖动，除了默认的数据块缓冲池(Default Pool)外，还可以将经常访问的数据放入Keep Pool，一次性使用的数据可以使用 Recycle Pool。设置 Recycle Pool需要应用开发配合，因此目前使用并不是很多，Keep Pool的使用确实可以改善 LRU算法的性能，适合几乎所有系统。
- RAC 环境下的缓冲区融合技术是一把双刃剑，缓冲区融合技术解决了多个实例安全访问同一个数据库的问题，同时也大大提升了全局缓冲的访问性能，但是如果全局缓冲传输操作的数量过大，很容易导致性能问题。因此在RAC环境下，更需要减少热块冲突，减少不必要的节点间 DB Cache的传输。在RAC环境中，要提高全局缓冲的性能，除了在硬件上提高私有网络的带宽外，尽可能提高DBCache 的命中率也十分关键，DBCache命中率高了，可以减少大量由于 Cache未命中而导致的实例间消息的数量，使LMS进程有更多的时间处理真正的 Global Cache。
- 实际上 RAC环境的缓冲区融合(Cache Fusion)技术是一种十分优秀的群集技术，通过高速的私有网络实现全局资源的共享，其共享效率比磁盘共享要快十倍以上。一个典型的磁盘单块读的响应时间约为4毫秒，如果要通过磁盘共享数据，一个操作包含了多个文件 IO操作(写、读)，而通过缓冲区融合算法只需要将 Cache从一个节点传输到另外一个节点就行了，Cache 在高速的千兆网络上传输的时间一般来说小于1毫秒。
