热点块竞争和解决--cache buffers chains.docVIP

热点块竞争和解决--cache buffers chains 热点块的定义 ??? 数据库的热点块，从简单了讲，就是极短的时间内对少量数据块进行了过于频繁的访问。定义看起来总是很简单的，但实际在数据库中，我们要去观察或者确定热点块的问题，却不是那么简单了。要深刻地理解数据库是怎么通过一些数据特征来表示热点块的，我们需要了解一些数据库在这方面处理机制的特性。 ?? 数据缓冲区的结构 我们都知道，当查询开始的时候，进程首先去数据缓冲区中查找是否存在查询所需要的数据块，如果没有，就去磁盘上把数据块读到内存中来。在这个过程中，涉及到数据缓冲区中 LRU 链的管理（ 8i 开始以接触点计数为标准衡量 buffer 冷热从而决定 buffer 是在 LRU 的冷端还是热端），关于这部分内容，从 oracle concepts 中就能得到详尽的文档，我不准备去论述这部分内容，这也不是本文的重点。现在我们的重点是，到底进程是如何地去快速定位到自己所想要的 block 的，或者如何快速确定想要的 block 不在内存中而去进行物理读的。 ?? 我们仔细想一想，随着硬件的发展，内存越来越大， cache buffer 也越来越大，我们如何才能在大量的内存中迅速定位到自己想要的 block ？总不能去所有 buffer 中遍历吧！在此数据库引出了 hash 的概念（ oracle 中快速定位信息总是通过 hash 算法的，比如快速定位 sql 是否在 shared pool size 中存在就是通过 hash value 来定位的，也就是说 shared pool size 中对象也是通过 hash table 来管理的），了解一点数据结构的基本知识就知道， hash 的一大重要功能就是快速地查找。举个最简单的例子，假设我们有一个 hash table 就是一个二维数组 a[200][100], 现在有 1000 个无序数字，我们要从这 1000 个数字里面查找某个值是否存在，或者说当我们接收到某个数字的时候必须判断是否已经存在，当然，我们可以遍历这 1000 个数字，但这样的效率就很低。但现在我们考虑这样一种方法，那就是把 1000 个数字除以 200 ，根据其余数，放在 a[200][100] 里面 ( 假设相同余数的最大数量不超过 100) ，余数就是数组的下标。这样，平均来说一个数组 a[i] 里面可能有 5 个左右的数字。当我们要去判别一个数字是否存在的时候，对这个数字除以 200( 这就是一个最简单的 hash 算法 ) ，根据余数 i 作为下标去数组 a[i] 中查找，大约进行 5 次查找就能判别是否已经存在，这样通过开辟内存空间 a[200][100] 来换取了时间 ( 当然 hash 算法的选取和 hash table 的大小是一个很关键的问题 ) 。 明白了基本的 hash 原理之后，我们再来看 oracle 的 block 的管理。数据库为这些 block 也开辟了 hash table ，假设是 a, 则在一维上的数量是由参数 _db_block_hash_buckets 来决定的，也就是存在 hash table a[_db_block_hash_buckets ], 从 oracle8i 开始， _db_block_hash_buckets =db_block_buffers*2 。而一个 block 被放到哪个 buckets 里面，则是由 block 的文件编号、块号 (x$bh.dbarfl 、 x$bh.dbablk 对应了 block 的文件属于表空间中的相关编号和 block 在文件中的编号， x$bh 是所有 cache buffer 的 header 信息，通过表格的形式可以查询 ) 做 hash 算法决定放到哪个 bucket 的，而 bucket 里面就存放了这些 buffers 的地址。这样当我们要访问数据的时候，可以获得 segment 的 extent( 可以通过 dba_extents 查到看，详细的信息来源这里不做探讨 ) ，自然知道要访问的文件编号和 block 编号，根据文件和 block 编号可以通过 hash 算法计算出 hash bucket, 然后就可以去 hash bucket 里面去找 block 对应的 buffer 。 除此之外，为了维护对这些 block 的访问和更改， oracle 还提供了一种 latch 来保护这些 block 。因为要避免不同的进程随意地径直并发修改和访问这些 block ，这样很可能会破坏 block 的结构的。 latch 是数据库内部提供的一种维护内部结构的一种低级锁， latch 的生存周期极短 ( 微秒以下级别 ) ，进程加 latch