【转载】缓冲处理器 buffer handle 的内部机制

最新推荐文章于 2023-05-10 20:24:45 发布

cuituo5185

最新推荐文章于 2023-05-10 20:24:45 发布

阅读量317

点赞数

　　很多 DBA 在评价数据库的性能时都花费一定的时间查看 logical I/O ，并将 logical I/O 作为 CPU 消耗的粗略指示。通常这是有道理的，但是由于某些原因有一定的误差。

　　一个重要的错误是Oracle可以通过不用执行logical I/O访问数据缓冲。

　　但是理解该问题的重要性前，必须明白logical I/O到底是什么，有两种可能的定义如下：一种是调用x$kcbwh中的子过程之一，另一种则是至少在cache buffers chains latch上得到一次。

　　但是如何确保在没有使用latch时访问一个缓冲块的安全呢—答案是你希望多次使用它（缓冲块），因此第一次使用latch得到它，然后在完成后释放latch，但是将其pin在临时地方，而不需要每次使用时都去竞争latch。

　　用来pin缓冲（实际上是缓冲头，而不是缓冲本身）的对象称为缓冲处理器（buffer handle）。

　　可用的缓冲处理器的数量依赖于启动时的设置，并且依赖于进程的数量--5 * processes。默认通常为5，由_db_handles设置。这些处理器存储在x$kcbbf结构中。

[@more@] 　　为了 pin 缓冲头，会话必须首先得到一个缓冲处理器，完成该动作的第一步是争夺 cache buffer handles latch 保护 x$kcbbf 数组的完整性。当然，如果会话每次想要 pin 缓冲时都必须争夺该 latch ，那么这种 latch 将会成为主要的冲突。因此允许每个会话建立一个小的保留集或者称处理器（ handle ）缓存。会话不需要得到 latch 使用，并重用这个小的处理器集。

　　当然某些查询可能会相当复杂，并且如果可以pin大量的缓冲，操作将会非常有效。因此如果有更多的空闲处理器可以使用，会话将允许得到多于5个的处理器。因此一个会话允许的最大处理器数为db_block_buffers / processes，在使用动态缓存时该算法会有一定的问题。该限制以_cursor_db_buffers_pinned参数发布。

　　缓冲pin的代价和效率可以通过两个统计查询：buffer is pinned count，该统计报告访问一个缓冲而不需要得到latch的次数；no buffer to keep pinned count，表示当希望pin一个缓冲的时候，或者超出了限制，或者在数组中找不到空闲的pin。

　　第一个统计是会话完成的工作的度量，第二个则表明processes相对于缓冲缓存太大，或者反之，db_block_buffers太小。

某些注意点

　　缓冲只能在调用期间被pin，在调用结束后必须被释放。

　　如果缓冲被pin住，它们将不能从内存中被刷新出去—即使出现在lru的尾端。

　　缓冲（缓冲头）可以在排斥模式被pin，也可以在共享模式。如果使用排斥模式pin（x$bh.mode_held），其他会话需要将它们的pin附属到缓冲头的'waiters list'上，然后进入'buffer busy waits'状态。

　　大多数缓冲get要求得到两个latch—一个用于定位和pin缓冲，另一个用于unpin缓冲；但是也有一些只需要一个latch（由consistent gets – examination报告）并在保持latch期间查看缓冲。主要包括：读取索引的根块，创建一致性读时读取撤销块，读取单表哈希中的单块（除非设置了'collision flag'标记）。