在之前的文章《latch free:cache buffer handles造成的SQL性能问题》中我介绍了cache buffer handle latch的一些知识，在这里我们复习一下：
"当会话需要pin住buffer header时它首先要获去buffer handle，得到buffer handle的过程中首先要抢占cache buffer handles栓，为了避免对于cache buffer handles栓的过度争用，每个会话被允许cache一小撮buffer handles,也叫保留集(reserved set)。该保留集的上限由隐式参数_db_handles_cached(默认为5)所控制，在此基础上会话在执行不是十分复杂的SQL时不必反复申请栓。
同时存在一些十分复杂的语句，需要同时pin住大量的缓存，此时若存在空闲的handle，会话被允许索要手头5个cached buffer handles以外的handle。也为了限制单个会话的资源占用量，Oracle通过内部算法总是尽量让每个进程能够pin住”合理份额“的buffer，由此单个会话同一时间所能持有的总handle数等于db_block_buffers/processes，隐式参数_cursor_db_buffers_pinned指出了该值。另cache buffer handles并没有子栓，仅有父栓本身，所以如果系统中有大量复杂SQL，会话所能cache的buffer handles远不足以满足需求时，该栓就成为整个系统性能的瓶颈，甚至可能出现潜在的死锁/饿死问题。"
应网友在T.ASKMACLEAN.COM上的提问，我们介绍更多cache Buffer handle相关的知识：
cache buffer handle 结构:
------------------------------ | Buffer state object | ------------------------------ | Place to hang the buffer | ------------------------------ | Consistent Get? | ------------------------------ | Proc Owning SO | ------------------------------ | Flags(RIR) | ------------------------------来看一个 cache buffer handle SO: 70000046fdfe530, type: 24, owner: 70000041b018630, flag: INIT/-/-/0x00 (buffer) (CR) PR: 70000048e92d148 FLG: 0x500000 lock rls: 0, class bit: 0 kcbbfbp: [BH: 7000001c7f069b0, LINK: 70000046fdfe570] where: kdswh02: kdsgrp, why: 0 BH (7000001c7f069b0) file#: 12 rdba: 0x03061612 (12/398866) class: 1 ba: 7000001c70ee000 set: 75 blksize: 8192 bsi: 0 set-flg: 0 pwbcnt: 0 dbwrid: 2 obj: 66209 objn: 48710 tsn: 6 afn: 12 hash: [700000485f12138,700000485f12138] lru: [70000025af67790,700000132f69ee0] lru-flags: hot_buffer ckptq: [NULL] fileq: [NULL] objq: [700000114f5dd10,70000028bf5d620] use: [70000046fdfe570,70000046fdfe570] wait: [NULL] st: SCURRENT md: SHR tch: 0 flags: affinity_lock LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [65535] where: kdswh02: kdsgrp, why: 0 # Example: #
