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的影響.

SQL> select x.ksppinm name,y.ksppstvl value,x.ksppdesc describ

2 from sys.x$ksppi x,sys.x$ksppcv y

3 where

4 x.inst_id=userenv('Instance') and

5 y.inst_id=userenv('Instance') and

6 x.indx=y.indx and x.ksppinm like '%_db_block_hash_buckets%'

7 ;

NAME VALUE DESCRIB

---------------------------- ---------------- ----------------------------------------

_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

SQL> show parameter db_cache_size

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

db_cache_size big integer 88M

SQL>

SQL> select x.ksppinm name,y.ksppstvl value,x.ksppdesc describ

2 from sys.x$ksppi x,sys.x$ksppcv y

3 where

4 x.inst_id=userenv('Instance') and

5 y.inst_id=userenv('Instance') and

6 x.indx=y.indx and x.ksppinm like '%_db_block_hash_buckets%'

7 ;

NAME VALUE DESCRIB

-------------------------------- ------------------- --------------------------------------------

_db_block_hash_buckets 32768 Number of database block hash buckets

SQL> show parameter db_block_size

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

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

SQL> select x.ksppinm name,y.ksppstvl value,x.ksppdesc describ

2 from sys.x$ksppi x,sys.x$ksppcv y

3 where

4 x.inst_id=userenv('Instance') and

5 y.inst_id=userenv('Instance') and

6 x.indx=y.indx and x.ksppinm like '%_db_block_hash_latches%'

7 ;

NAME VALUE DESCRIB

-------------------------------------- ------------------- -----------------------------------------

_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

SQL> select 88*1024/8/32768 from dual;

88*1024/8/32768

---------------

0.34375

那麼說明有的bucket中沒有buffer header

SQL> alter session set events 'immediate trace name buffers level 10';

Session altered.

SQL> select

2 d.value||'/'||lower(rtrim(i.instance,

3 chr(0)))||'_ora_'||p.spid||'.trc' trace_file_name

4 from ( select p.spid

5 from sys.v$mystat m,

6 sys.v$session s,sys.v$process p

7 where m.statistic# = 1 and s.sid = m.sid and p.addr = s.paddr) p,

8 ( select t.instance from sys.v$thread t,sys.v$parameter v

9 where v.name = 'thread' and

10 (v.value = 0 or t.thread# = to_number(v.value))) i,

11 ( select value from sys.v$parameter

12 where name = 'user_dump_dest') d

13 /

TRACE_FILE_NAME

--------------------------------------------------------------------------------

/u01/app/oracle/admin/jingyong/udump/jingyong_ora_3341.trc

跟蹤檔案中的cache buffer chain的數量正好是

[oracle@jingyong udump]$ grep CHAIN jingyong_ora_3341.trc | wc -l

32768

某些chain上可能沒有buffer header資訊(被標記為null),這些chain的資料類似如下:

[oracle@jingyong 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 [......@.iH......]

25CEC010 0000A2B2 00000001 000000B5 00074869 [............iH..]

25CEC020 1FE80000 00031F02 0040B88B 00140001 [..........@.....]

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 [.8..=........@..]

25CEDFE0 40000000 000094B8 5ECEFA10 4AAA6474 [...@.......^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

相關文章