oracle 成长历程-3.4.4 Hash Buckets and Chains

3.4.4    Hash Buckets and Chains

从如何搜索buffer这个角度讲，存在这么一个数据结构：有一定数量的hash bucket，每个bucket下面是一个双向链表cache buffer chain，链表上挂着一个一个buffer。如何搜索一个buffer在哪里，以及如何定位一个buffer应该放到哪里，是通过hash算法找到那个bucket，然后遍历cache buffer chain。bucket的数量由_db_block_hash_buckets控制。这个链表上的latch是cache buffer chain，latch的数量由_db_block_hash_latches控制。

对hash chain的访问都必须被cache buffer chain latch所保护。Hash chain本身更新是通过普通的链表机制。每次访问都必须加latch。

在oracle8.0之前，每一个hash bucket都有一个cache buffers chains latch（hash latch），并且hash bucket都只有一个hash chain链表。换句话说，hash latch,hash backet和hash chain之间是1：1：1的关系。默认的hash bucket个数为大于db_block_buffers / 4的最小质数，通过隐含参数_db_block_hash_buckets可以修改该值。例如，假如db_block_buffers = 50000，则该实例中有12501个hash latch，有12501个hash bucket，有12501个hash chain。

从oracle8i开始，oracle将hash latch和hash bucket之前的关系改成了 1：m，但hash bucket和hash chain之间还是1：1，也就是一个hash latch可以同时保护多个hash chain链表。这样，可以显著的减少系统中hash latch的个数。Hash latch的默认个数还是和db_block_buffers的值相关。当数据缓冲区小于1G时，一般都是1024个。通过隐含参数_db_blocks_hash_latches可以修改该值。

 

备注：buffer cache所指向的数据块（buffer）的状态。一共有六种状态：

²  FREE(0)=可以被重用的数据块；

²  XCURRENT(1)=实例以排它方式获取的当前模式数据块；

²  SCURRENT(2)=可以与其它实例共享的当前模式数据块；

²  CR(3)=作为一致性读镜像的数据块，永远不会被写入磁盘；

²  READING(4)=正在从磁盘读出的数据块；

²  MRECOVERY(5)=正在进行介质恢复的数据块；

²  IRECOVERY(6)=正在进行实例恢复的数据块。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/347643/viewspace-620119/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/347643/viewspace-620119/