关于Know more about Cache Buffer Handle的疑问

gdpr-dba

里面提到“每个会话被允许cache一小撮buffer handles”，但我看下面的测试，之前session B根本就没有访问test_cbc_handle这张表，怎么会有test_cbc_handle的handle cache呢？

接下来 我们实际体验一下 cache buffer handles latch 和 buffer pin的影响：

SESSION A :

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production

SQL> create table test_cbc_handle(t1 int);

Table created.

SQL> insert into test_cbc_handle values(1);

1 row created.

SQL> commit;

Commit complete.

SQL> select rowid from test_cbc_handle;

ROWID
------------------
AAANO6AABAAAQZSAAA

select * from test_cbc_handle where rowid='AAANO6AABAAAQZSAAA';

SQL> select addr,name from v$latch_parent where name='cache buffer handles';

ADDR             NAME
---------------- --------------------------------------------------
00000000600140A8 cache buffer handles

SQL> select to_number('00000000600140A8','xxxxxxxxxxxxxxxxxxxx') from dual;

TO_NUMBER('00000000600140A8','XXXXXXXXXXXXXXXXXXXX')
----------------------------------------------------
                                          1610694824

注意cache buffer handles只有一个parent latch 而没有 child latch

我们让SESSION A hold 住唯一的一个        cache buffer handles parent latch

SQL> oradebug setmypid;
Statement processed.
SQL> oradebug call kslgetl 1610694824 1;
Function returned 1

另外开一个  SESSION B 来观察：

SQL> select * from v$latchholder;

       PID        SID LADDR            NAME                                                                   GETS
---------- ---------- ---------------- ---------------------------------------------------------------- ----------
        15        141 00000000600140A8 cache buffer handles                                                    119

cache buffer handles   latch 确实被hold住了

SQL> select * from test_cbc_handle where rowid='AAANO6AABAAAQZSAAA';

        T1
----------
         1

单此时 其他 Server Process还是可以正常 read buffer， 这是因为 _db_handles_cached ， 默认process会cache 5个handle

gdpr-dba

谢谢刘大。

1.如果不考虑buffer handles cache的话，正常的访问buffer cache的流程是：
获取cache buffer chain latch->获取cache buffer handle latch->获取cache buffer handle>释放cache buffer handle latch->pin buffer cache->释放cache buffer chain latch->使用完后释放buffer cache pin->释放cache buffer handle
这个流程对吗？

2.说这么久好像也没提到cache buffer handle的作用是什么？也就是说为什么pin之前需要获得cache buffer handle呢？

[ 本帖最后由 gdpr-dba 于 2012-5-12 22:49 编辑 ]

Maclean Liu(刘相兵

As Maclean Said:

FOR Question 1:

Of course if   it called kcbgetcr() consistent read  or kcbgtcur() current read

FOR Question 2:

ODM DATA:


SQL> set linesize 200 pagesize 1400
SQL> l
  1  SELECT t1.ksllasnam "parent_name",
  2         t2.ksllwnam  "location"
  3    FROM x$ksllw t2, x$kslwsc t1
  4   WHERE t2.indx = t1.indx
  5* and ksllasnam ='cache buffer handles'
SQL> /

parent_name                                                      location
---------------------------------------------------------------- --------------------------------------------------------------------------------
cache buffer handles                                             kcbzgs
cache buffer handles                                             kcbzfs
cache buffer handles                                             kcbzrgs


From trace file, next state object seems to relate the problem.
SO:c00000020244cd18 equals to 2nd argument of ORA-600.

----------------------------------------
SO: c00000020244cd18, type: 24, owner: c0000001fdf79c38,
        flag: INIT/-/-/0x00
(buffer) (CR) PR: 0xc00000020007ec80 FLG: 0x100401
lock rls: 0x0000000000000000, class bit: 0x0000000000000000
kcbbfbp: [BH: 0x0000000000000000, LINK: 0xc00000020244cd58]
where: kdiwh100: kdircys, why: 0
-----------------------------------

stack call


qergsFetch=> qerjoFetch =>qerixFetchFastFullScan  => kdirfrs  => kcbrls  => kcbzfs


kcbrls is function what release buffer pin , it would call kcbzfs to free buffer handle .

gdpr-dba

“当会话需要pin住buffer header时它首先要获去buffer handle，得到buffer handle的过程中首先要抢占cache buffer handles栓，为了避免对于cache buffer handles栓的过度争用，每个会话被允许cache一小撮buffer handles,也叫保留集(reserved set)。该保留集的上限由隐式参数_db_handles_cached(默认为5)所控制，在此基础上会话在执行不是十分复杂的SQL时不必反复申请栓。

1.当进程有cached buffer handles时不需要抢占cache buffer handles栓，那此时需不需要抢占cache buffer chain latch来查找buffer header呢？

2.“当会话需要pin住buffer header时它首先要获去buffer handle” 那请问buffer handle获取后什么时候被释放？是pin住buffer header之后就释放吗？还是在释放pin之后才会释放buffer handle?

[ 本帖最后由 gdpr-dba 于 2012-5-12 22:13 编辑 ]

Maclean Liu(刘相兵

你可以理解为 _db_handles_cached  指定的cache   buffer  handle  是预分配给process的， process 怎么用是他自己的事 不需要 hold cache   buffer  handle latch ， 当process 需求超过 _db_handles_cached  时 则需要  hold cache   buffer  handle latch  以便allocate 新的 handle .


Question:
为什么 要通过 cache   buffer  handle latch 限制 handle 的分配？  


Answer:


因为 cache   buffer  handle是 共享资源 ，存放在shared pool中，

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production

SQL> select * from v$sgastat where name='buffer handles';

POOL         NAME                            BYTES
------------ -------------------------- ----------
shared pool  buffer handles                 216008


SQL> alter system set "_db_handles"=999999 scope=spfile;

System altered.

SQL> startup force;
ORACLE instance started.

Total System Global Area 3154116608 bytes
Fixed Size                  2099584 bytes
Variable Size             687867520 bytes
Database Buffers         2449473536 bytes
Redo Buffers               14675968 bytes
Database mounted.
Database opened.


SQL> select * from v$sgastat where name='buffer handles';   

POOL         NAME                            BYTES
------------ -------------------------- ----------
shared pool  buffer handles              287999720

gdpr-dba

对cache buffer handle有很多疑问，是否跟tom的书里提到的句柄是一回事：
“所以数据库说：“如果通过索引 COLOCATED_PK 从头到尾地读取 COLOCATED 表中的每一行，就
要执行 11.190 次 I/O。不过，如果我们对 DISORGANIZED 表做同样的事情，则会对这个表执行 99,932
次 I/O。“之所以存在这么大的区别，原因在于，当 Oracle 对索引结构执行区间扫描时，如果它发现索引
中的下一行于前一行在同一个数据库块上，就不会再执行另一个 I/O 从缓冲区缓存中获得表块。它已经有
表块的一个句柄，只需直接使用就可以了。不过，如果下一行不在同一个块上，就会释放当前的这个块，
而执行另一个  I/O  从缓冲区缓存获取要处理的下一个块。”

gdpr-dba

顶一下，刘大帮忙看看，谢谢。