文章转自：http://www.jydba.net/cache-buffer-chain/
buffer cache的管理有两个重要的数据结构:
hash bucket和cache buffer chain
1. hash bucket和cache buffer chain
可以想象,如果所有的buffer cache中的所有buffer都通过同一个结构来进行管理,当需要确定某个
block在buffer中是否存在时,将需要遍历整个结构,性能会相当低下.
为了提高效率,oracle引入了bucket的数据结构,oracle把管理的所有buffer通过一个内部的hash算法
运算后,存放到不同的hash bucket中,这样通过hash bucket进行分割之后,众多的buffer被分布到一
定数量的bucket之中,当用户需要在buffer中定位数据是否存在时,只需要通过同样的算法来获得hash
值然后到相应的bucket中查找少理的buffer即可确定.每个buffer存放的bucket由buffer的数据块
地址(DBA,Data Block Address)运算决定.
bucket内部,通过cache buffer chain(cache buffer chain是一个双向链表)将所有的buffer通过
buffer header信息联系起来
buffer header存放的是对应数据块的概要信息,包括数据块的文件号,块地址,状态等.要判断数据块
在buffer中是否存在,通过检查buffer header即可确定.
如果多个会话同时对相同的cache buffer chain进行读取时就会产生cache buffer chain的竞争.
先来进行读取的会话持有这个cache buffer chain的latch
从oracle9i开始,对于cache buffer chain的只读访问,其latch可以被共享,也就是说,如果多个会话
都只是来查阅这个cache buffer chain那么大家可以同时进行查阅,但是如果有会话要对这个
cache buffer chian中的buffer header对应的数据块进行操作时那么就只能独享这个latch了.
这就是buffer cache 与latch的竞争
由于buffer根据buffer header进行散列,从而最终决定存入哪一个hash bucket,那么hash bucket的
数量在一定程度上就决定了每个bucket中buffer数量的多少,也就间接影响了搜索buffer header的
性能.
所以在不同版本中,oracle一直在修改算法,优化hash bucket的数量,可以想象,bucket的数量多一些
那么在同一时间就可以有更多的会话可以对不同的hash bucket进行读取.但是更多的hash bucket,
显然需要更多的存放空间,更多的管理成本,所以优化在什么时候都不是简单的一元方程.
hash bucket的设置受一个隐含参数_db_block_hash_buckets的影响.
1 SQL> select x.ksppinm name,y.ksppstvl value,x.ksppdesc describ 2 2 from sys.x$ksppi x,sys.x$ksppcv y 3 3 where 4 4 x.inst_id=userenv(‘Instance‘) and 5 5 y.inst_id=userenv(‘Instance‘) and 6 6 x.indx=y.indx and x.ksppinm like ‘%_db_block_hash_buckets%‘ 7 7 ; 8 9 NAME VALUE DESCRIB 10 ---------------------------- ---------------- ---------------------------------------- 11 _db_block_hash_buckets 4194304 Number of database block hash buckets
对于每个hash bucket，只会有一个cache buffer chain ,当用户试图搜索cache buffer chain时
必须先获得cache buffer chain latch.那么cache buffer chain latch的设置就同样值得研究
在oracle8i之前,对于每一个hash bucket,oracle使用一个独立的hash latch来维护,其缺省的
bucket数量为next_prime(db_block_buffers/4)
由于过于严重的热块竞争,从oracle8i开始,oracle改变了这个算法,先是bucket数量开始增加,
_db_block_hash_bucket增加到了2*db_block_buffers,而_db_block_hash_latchs的数量也发生
变化
当cache buffers少于2052个buffers时:
_db_block_hash_latches=power(2,trunc(log(2,db_block_buffers-4)-1))
当cache buffers多于131075个buffers时:
_db_block_hash_latches=power(2,trunc(log(2,db_block_buffers-4)-6))
当cache buffers在2052与131075个buffers之间时:
_db_block_hash_latches=1024
从oracle8i开始,_db_block_hash_buckets的数量较以前增加了8倍,而_db_block_hash_latchs的
数量增加比较有限,这意味着,每个latch需要管理多个bucket,但是由于bucket数量的成倍增加,
每个bucket中的block的数量得以减少,从而使用少量latch管理更多bucket成为可能
从oracle8i开始,bucket的数量比以前大大增加;通过增加bucket的数量来使得每个bucket上的
buffer的数量大大减少.
在oracle8i之前,_db_block_hash_latches的数量和hash bucket的数量是一致的,每一个latch管理
一个bucket,从oracle8i开始每个lath可以管理多个bucket,由于每个bucket中的buffer header数量
大大降低所以latch的性能反而得到提高
每个bucket存在一条cache buffer chain
buffer header上存在指向具体buffer的指针
下面是测试的一情景
db_cache_size为88MB,此时的_db_block_hash_buckets为32768
1 SQL> show parameter db_cache_size 2 3 NAME TYPE VALUE 4 ------------------------------------ ----------- ------------------------------ 5 db_cache_size big integer 88M 6 7 SQL> 8 SQL> select x.ksppinm name,y.ksppstvl value,x.ksppdesc describ 9 2 from sys.x$ksppi x,sys.x$ksppcv y 10 3 where 11 4 x.inst_id=userenv(‘Instance‘) and 12 5 y.inst_id=userenv(‘Instance‘) and 13 6 x.indx=y.indx and x.ksppinm like ‘%_db_block_hash_buckets%‘ 14 7 ; 15 16 NAME VALUE DESCRIB 17 -------------------------------- ------------------- -------------------------------------------- 18 _db_block_hash_buckets 32768 Number of database block hash buckets 19 20 21 SQL> show parameter db_block_size 22 23 NAME TYPE VALUE 24 ------------------------------------ ----------- ------------------------------ 25 db_block_size integer 8192
计算db_cache_size=88MB,有多少个db_block_buffer=11264
SQL> select 88*1024/8 from dual;
88*1024/8
----------
11264
查询一下_db_block_hash_latches=1024所以应证了
当cache buffers在2052与131075个buffers之间时:
_db_block_hash_latches=1024
1 SQL> select x.ksppinm name,y.ksppstvl value,x.ksppdesc describ 2 2 from sys.x$ksppi x,sys.x$ksppcv y 3 3 where 4 4 x.inst_id=userenv(‘Instance‘) and 5 5 y.inst_id=userenv(‘Instance‘) and 6 6 x.indx=y.indx and x.ksppinm like ‘%_db_block_hash_latches%‘ 7 7 ; 8 9 NAME VALUE DESCRIB 10 -------------------------------------- ------------------- ----------------------------------------- 11 _db_block_hash_latches 1024 Number of database block hash latches
计算一下每个bucket中有多少个buffer header
db_cache_size为88MB,此时的_db_block_hash_buckets为32768
db_block_size=8Kb
1 SQL> select 88*1024/8/32768 from dual; 2 3 88*1024/8/32768 4 --------------- 5 0.34375
那么说明有的bucket中没有buffer header
1 SQL> alter session set events ‘immediate trace name buffers level 10‘; 2 3 Session altered. 4 5 SQL> select 6 2 d.value||‘/‘||lower(rtrim(i.instance, 7 3 chr(0)))||‘_ora_‘||p.spid||‘.trc‘ trace_file_name 8 4 from ( select p.spid 9 5 from sys.v$mystat m, 10 6 sys.v$session s,sys.v$process p 11 7 where m.statistic# = 1 and s.sid = m.sid and p.addr = s.paddr) p, 12 8 ( select t.instance from sys.v$thread t,sys.v$parameter v 13 9 where v.name = ‘thread‘ and 14 10 (v.value = 0 or t.thread# = to_number(v.value))) i, 15 11 ( select value from sys.v$parameter 16 12 where name = ‘user_dump_dest‘) d 17 13 / 18 19 TRACE_FILE_NAME 20 -------------------------------------------------------------------------------- 21 /u01/app/oracle/admin/jingyong/udump/jingyong_ora_3341.trc
跟踪文件中的cache buffer chain的数量正好是
[[email protected] udump]$ grep CHAIN jingyong_ora_3341.trc | wc -l 32768
某些chain上可能没有buffer header信息(被标记为null),这些chain的数据类似如下:
[[email protected] udump]$ grep CHAIN jingyong_ora_3341.trc|head -20 CHAIN: 0 LOC: 0x290c0838 HEAD: [NULL] CHAIN: 1 LOC: 0x290c0840 HEAD: [NULL] CHAIN: 2 LOC: 0x290c0848 HEAD: [NULL] CHAIN: 3 LOC: 0x290c0850 HEAD: [NULL] CHAIN: 4 LOC: 0x290c0858 HEAD: [NULL] CHAIN: 5 LOC: 0x290c0860 HEAD: [NULL] CHAIN: 6 LOC: 0x290c0868 HEAD: [25feb12c,25feb12c] CHAIN: 7 LOC: 0x290c0870 HEAD: [NULL] CHAIN: 8 LOC: 0x290c0878 HEAD: [24fe6dcc,24fe6dcc] CHAIN: 9 LOC: 0x290c0880 HEAD: [NULL] CHAIN: 10 LOC: 0x290c0888 HEAD: [NULL] CHAIN: 11 LOC: 0x290c0890 HEAD: [NULL] CHAIN: 12 LOC: 0x290c0898 HEAD: [233f8c7c,233f8c7c] CHAIN: 13 LOC: 0x290c08a0 HEAD: [NULL] CHAIN: 14 LOC: 0x290c08a8 HEAD: [NULL] CHAIN: 15 LOC: 0x290c08b0 HEAD: [NULL] CHAIN: 16 LOC: 0x290c08b8 HEAD: [NULL] CHAIN: 17 LOC: 0x290c08c0 HEAD: [NULL] CHAIN: 18 LOC: 0x290c08c8 HEAD: [21fed2dc,21fee82c] CHAIN: 19 LOC: 0x290c08d0 HEAD: [NULL]
查看一下chain 6的数据
CHAIN: 6 LOC: 0x290c0868 HEAD: [25feb12c,25feb12c]
BH (0x25feb12c) file#: 1 rdba: 0x0040b894 (1/47252) class: 1 ba: 0x25cec000
set: 3 blksize: 8192 bsi: 0 set-flg: 0 pwbcnt: 75
dbwrid: 0 obj: 181 objn: 183 tsn: 0 afn: 1
hash: [290c0868,290c0868] lru: [25feb230,25feb0d0]
lru-flags:
ckptq: [NULL] fileq: [NULL] objq: [25feb124,25feb284]
st: XCURRENT md: NULL tch: 1
flags:
LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
buffer tsn: 0 rdba: 0x0040b894 (1/47252)
scn: 0x0000.00074869 seq: 0x01 flg: 0x04 tail: 0x48690601
frmt: 0x02 chkval: 0xa2b2 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x25CEC000 to 0x25CEE000
25CEC000 0000A206 0040B894 00074869 04010000 [[email protected]]
25CEC010 0000A2B2 00000001 000000B5 00074869 [............iH..]
25CEC020 1FE80000 00031F02 0040B88B 00140001 [[email protected]]
25CEC030 0000006D 00805685 0022002D 00008000 [m....V..-.".....]
25CEC040 00039FF0 0011000A 000000C7 00800A9E [................]
25CEC050 002600D7 00008000 0007481D 00050400 [..&......H......]
25CEC060 0028FFFF 1E791E70 00001E79 00010001 [..(.p.y.y.......]
25CEC070 00020001 00020000 1F790003 1E701F33 [..........y.3.p.]
25CEC080 1EA21ED5 00000000 00000000 00000000 [................]
25CEC090 00000000 00000000 00000000 00000000 [................]
Repeat 482 times
25CEDEC0 00000000 00000000 00000000 000D006C [............l...]
25CEDED0 02444902 001002C1 00000000 00000000 [.ID.............]
25CEDEE0 00000000 02190000 02FF02C1 C20303C1 [................]
25CEDEF0 C1023509 02C20302 FFFFFF1D 006C8001 [.5............l.]
25CEDF00 500B000D 41424F52 494C4942 C1025954 [...PROBABILITY..]
25CEDF10 00001004 00000000 00000000 00000000 [................]
25CEDF20 C1020F00 C102FF02 FFFFFF03 01FFFFFF [................]
25CEDF30 0D006C80 43530500 0245524F 001003C1 [.l....SCORE.....]
25CEDF40 00000000 00000000 00000000 020F0000 [................]
25CEDF50 02FF02C1 FFFF03C1 FFFFFFFF 006C8001 [..............l.]
25CEDF60 4902000D 02C10244 00000010 00000000 [...ID...........]
25CEDF70 00000000 00000000 02C10219 03C102FF [................]
25CEDF80 0202C102 C20302C1 FFFF1D02 6C8001FF [...............l]
25CEDF90 04001500 302E3824 5ECEFA10 4AAA6474 [....$8.0...^td.J]
25CEDFA0 5730E0F6 1016058C 02C20365 05C10209 [..0W....e.......]
25CEDFB0 0104C102 FFFFFF80 FFFFFFFF FFFFFFFF [................]
25CEDFC0 11FFFFFF F99F5921 C8031661 E625EF53 [....!Y..a...S.%.]
25CEDFD0 03CF388F 0200AC3D 00040004 94B84000 [[email protected]]
25CEDFE0 40000000 000094B8 5ECEFA10 4AAA6474 [[email protected]^td.J]
25CEDFF0 5730E0F6 1016058C 02C10265 48690601 [..0W....e.....iH]
Block header dump: 0x0040b894
Object id on Block? Y
seg/obj: 0xb5 csc: 0x00.74869 itc: 2 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x40b88b ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0001.014.0000006d 0x00805685.002d.22 C--- 0 scn 0x0000.00039ff0
0x02 0x000a.011.000000c7 0x00800a9e.00d7.26 C--- 0 scn 0x0000.0007481d
data_block_dump,data header at 0x25cec05c
===============
tsiz: 0x1fa0
hsiz: 0x28
pbl: 0x25cec05c
bdba: 0x0040b894
76543210
flag=--------
ntab=4
nrow=5
frre=-1
fsbo=0x28
fseo=0x1e70
avsp=0x1e79
tosp=0x1e79
0xe:pti[0] nrow=1 offs=0
0x12:pti[1] nrow=1 offs=1
0x16:pti[2] nrow=0 offs=2
0x1a:pti[3] nrow=3 offs=2
0x1e:pri[0] offs=0x1f79
0x20:pri[1] offs=0x1f33
0x22:pri[2] offs=0x1e70
0x24:pri[3] offs=0x1ed5
0x26:pri[4] offs=0x1ea2
block_row_dump:
tab 0, row 0, @0x1f79
tl: 39 fb: K-H-FL-- lb: 0x0 cc: 2
curc: 4 comc: 4 pk: 0x0040b894.0 nk: 0x0040b894.0
col 0: [16] fa ce 5e 74 64 aa 4a f6 e0 30 57 8c 05 16 10 65
col 1: [ 2] c1 02
tab 1, row 0, @0x1f33
tl: 70 fb: -CH-FL-- lb: 0x0 cc: 21 cki: 0
col 0: [ 4] 24 38 2e 30
col 1: [16] fa ce 5e 74 64 aa 4a f6 e0 30 57 8c 05 16 10 65
col 2: [ 3] c2 02 09
col 3: [ 2] c1 05
col 4: [ 2] c1 04
col 5: [ 1] 80
col 6: *NULL*
col 7: *NULL*
col 8: *NULL*
col 9: *NULL*
col 10: *NULL*
col 11: *NULL*
col 12: *NULL*
col 13: *NULL*
col 14: *NULL*
col 15: *NULL*
col 16: *NULL*
col 17: *NULL*
col 18: *NULL*
col 19: *NULL*
col 20: [17] 21 59 9f f9 61 16 03 c8 53 ef 25 e6 8f 38 cf 03 3d
tab 3, row 0, @0x1e70
tl: 50 fb: -CH-FL-- lb: 0x0 cc: 13 cki: 0
col 0: [ 2] 49 44
col 1: [ 2] c1 02
col 2: [16] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 19
col 3: [ 2] c1 02
col 4: *NULL*
col 5: [ 2] c1 03
col 6: [ 3] c2 09 35
col 7: [ 2] c1 02
col 8: [ 3] c2 02 1d
col 9: *NULL*
col 10: *NULL*
col 11: *NULL*
col 12: [ 1] 80
tab 3, row 1, @0x1ed5
tl: 45 fb: -CH-FL-- lb: 0x0 cc: 13 cki: 0
col 0: [ 5] 53 43 4f 52 45
col 1: [ 2] c1 03
col 2: [16] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0f
col 3: [ 2] c1 02
col 4: *NULL*
col 5: [ 2] c1 03
col 6: *NULL*
col 7: *NULL*
col 8: *NULL*
col 9: *NULL*
col 10: *NULL*
col 11: *NULL*
col 12: [ 1] 80
tab 3, row 2, @0x1ea2
tl: 51 fb: -CH-FL-- lb: 0x0 cc: 13 cki: 0
col 0: [11] 50 52 4f 42 41 42 49 4c 49 54 59
col 1: [ 2] c1 04
col 2: [16] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0f
col 3: [ 2] c1 02
col 4: *NULL*
col 5: [ 2] c1 03
col 6: *NULL*
col 7: *NULL*
col 8: *NULL*
col 9: *NULL*
col 10: *NULL*
col 11: *NULL*
col 12: [ 1] 80
end_of_block_dump
这个chain中存一个BH信息,其中包含”hash: [290c0868,290c0868] lru: [25feb230,25feb0d0]”
“hash: [290c0868,290c0868] “中的两个数据分别代表X$BH中的NXT_HASH和PRV_HASH,也就是指
同一个hash chain上的下一个BH地址和上一个buffer地址.如果某个chain只包含一个BH,
那么这两个值将同时指向该chain地址
“lru: [25feb230,25feb0d0]“中的两个数据分别代表X$BH中的NXT_REPL和PRV_REPL也就是LRU上的
下一个buffer和上一个buffer
【转】cache buffer chain 第一篇,布布扣,bubuko.com