zoukankan      html  css  js  c++  java
  • 【转】cache buffer chain 第一篇

    文章转自: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的数量正好是

    [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

  • 相关阅读:
    windows10使用记录
    DevOps理论与实践总结
    工资调整
    Node程序debug小记
    基于游标的分页接口实现
    util.promisify 的那些事儿
    如何编写 Typescript 声明文件
    async语法升级踩坑小记
    使用TS+Sequelize实现更简洁的CRUD
    使用 TypeScript 改造构建工具及测试用例
  • 原文地址:https://www.cnblogs.com/david-zhang-index/p/3871823.html
Copyright © 2011-2022 走看看