今天开发因为连接数不够 强烈要求加大processes值,突然想到了processes对_cursor_db_buffers_pinned的影响,,小记之:

当会话需要pin住buffer header时它首先要获去buffer handle,实例所存在的buffer handle总数由(each process can cache buffer handles*processes决定),也就是说在10g中可以认为 total buffer handle (_db_handles)=5*processes(默认_db_handles_cached为5）,而在11g中这个值发生了变化(in 11g _db_handles_cached =8) 而一个process在同一时间内所能pin住的最大handle数由(_cursor_db_buffers_pinned)所决定,我们可以演示一下 _cursor_db_buffers_pinned是怎么算出来的：

SQL> select * from v$version;

BANNER
——————————————————————————–
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
PL/SQL Release 11.2.0.3.0 – Production
CORE 11.2.0.3.0 Production
TNS for Linux: Version 11.2.0.3.0 – Production
NLSRTL Version 11.2.0.3.0 – Production

SQL>

COMPONENT CURRENT_SIZE
————————————————– ———————–
shared pool 8791261184
large pool 16777216
java pool 16777216
streams pool 33554432
DEFAULT buffer cache 59827552256

SQL> show parameter process;

NAME TYPE VALUE
———————————— ———– ——————————
aq_tm_processes integer 0
db_writer_processes integer 6
gcs_server_processes integer 12
job_queue_processes integer 10
log_archive_max_processes integer 2
processes integer 2100

59827552256/8192/2100=3477.699047619048

NAME VALUE DESCRIPTION
——————————————— ——————– ———————————————————————-
_cursor_db_buffers_pinned 3505 additional number of buffers a cursor can pin at once

可以看到 3478-2 ≈ 3505

_db_handles_cached – default 5
_db_handles – derived: possibly processes * _db_handles_cached
_cursor_db_buffers_pinned – derived: possibly (db_block_buffers / processes) – 2
_session_kept_cursor_pins – may do for cursors what _db_handles does for buffer headers (10g only)

关于这几个参数
_db_handles_cached in 11g -default 8
_session_kept_cursor_pins 在11gR2已经没有了这个参数
11g:
[oracle@testdb ~]$ ora params _session_kept_cursor_pins

no rows selected

10g:
[oracle@testdb2 ~]$ ora params _session_kept_cursor_pins

NAME VALUE DESCRIPTION
——————————————— ——————– ———————————————————————-
_session_kept_cursor_pins 0 Number of cursors pins to keep in a session

关于这块内容刘兄已经解释的很清楚：
—

“当会话需要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远不足以满足需求时，该栓就成为整个系统性能的瓶颈，甚至可能出现潜在的死锁/饿死问题。”

可以参见这篇文章:Know more about Cache Buffer Handle