设为首页 收藏本站
查看: 752|回复: 0

[经验分享] Oracle Buffer Cache原理总结(一)

[复制链接]

尚未签到

发表于 2016-7-28 06:58:28 | 显示全部楼层 |阅读模式
http://space.itpub.net/?uid-12361284-action-viewspace-itemid-112266
Buffer cache是Oracle SGA中的重要组成部分,在自己先前的blog中对于这一块也有过一些讨论,这里在给出一份更详细的总结.通常数据的访问和修改都是需要通过buffer cache来完成的,当一个server process访问数据的时候,首先需要确定的是,我们所需要的数据在buffer cache中是否存在,如果数据在buffer中存在呢,我们还需要根据data buffer的状态,来判断是否进行db block gets还是consistent gets,如果数据在buffer中不存在,则我们需要在buffer cache中寻找足够的空间来加载我们所需要的数据,如果在buffer cache中我们找不到足够的空间,那么我们就需要触发DBWn进程,去写出脏数据,用来释放我们的buffer空间.

     Oracle通过几个list来对buffer进行管理.其中最为突出的就是LRU List还有Dirty List,这些list上面存放的就是具体指向buffer的指针.
     
      LRU List主要就是用来维护内存中的buffer,按照我们LRU(Least Recently Used)的方式来进行管理.那么针对不同的Oracle版本呢,管理的方式也不同.但是有一点需要了解的是,当数据库初始化的时候,所有的buffer都被捕HASH到LRU List上进行管理.当我们从数据文件中读取数据的时候我们现在要在LRU List上面寻找free的buffer,然后将数据读取到我们所找到的这个free buffer中.只要数据被修改了,那么这个buffer的状态就变为了dirty,那么Oracle就会把这个buffer从LRU List移到Dirty List(Checkpoint Queue)中去.在Dirty List上的buffer都是一些候选的稍后会被DBWn写出到数据文件的buffer,那么这里还有一点需要注意的是:一个buffer要么存在于LRU List上面,要么存在于Dirty List上面,不可能同时存在于两个List上面.

  下面的 一些概念还是需要理解的细化的:

  1.当Server process试图通过扫描LRU List来寻找Free的Buffer的时候,扫描过程中会把已发现的所有Dirty buffer从LRU List移动到Dirty List(Checkpoint Queue)中去.这些buffer是我刚才说的可以候选的被DBWn进程写出到数据文件中的buffer.
   (Server process主动将Dirty buffer从LRU List移动到Dirty List)

  2.当Dirty List(Checkpoing Queue)中的Dirty Buffer量超过了一顶的阀值,那么Server process就会通知DBWn进程写出脏数据
  (Checkpoint Queue阀值到达,导致Server Proceess通知DBWn写赃数据)
    这个阀值是25%,当然这也是触发我们DBWn进程的一个条件

    SQL> select kvittag,kvitval,kvitdsc from x$kvit
         where kvittag='kcbldq';

    KVITTAG                                                             KVITVAL
    ---------------------------------------------------------------- ----------
    KVITDSC
    ----------------------------------------------------------------
    kcbldq                                                                   25
    large dirty queue if kcbclw reaches this

  3.如果Server process扫描了LRU超过一个阀值也没有找到足够的Free的buffer,这个时候也将会停止搜索free buffer的任务然后直接通知DBWn写脏数据来释放内存空间,当然这个Server process会处于free busy wait的等待事件.这个阀值是40%,同时这还是触发我们DBWn进程的一个条件
     (LRU扫描40%没有找到Free buffer,Server process通知DBWn写脏数据)  
    SQL> select kvittag,kvitval,kvitdsc from x$kvit
         where kvittag='kcbfsp';

    KVITTAG                                                             KVITVAL
    ---------------------------------------------------------------- ----------
    KVITDSC
    ----------------------------------------------------------------
    kcbfsp                                                                   40
    Max percentage of LRU list foreground can scan for free

  
  4.同时,因为Checkpoint Queue的引入,DBWn还会主动的扫描LRU List,将我们发现的Dirty Buffer从LRU List移动到checkpoing queue,扫描LRU List的范围是25%.
   (DBWn主动扫描LRU的25%,依照结果从LRU中移动Dirty Buffer到Dirty List中,)
    SQL> select kvittag,kvitval,kvitdsc from x$kvit
         where kvittag='kcbdsp';

    KVITTAG                                                             KVITVAL
    ---------------------------------------------------------------- ----------
    KVITDSC
    ----------------------------------------------------------------
    kcbdsp                                                                   25
    Max percentage of LRU list dbwriter can scan for dirty
   
   
  5.从Oracle 8i开始呢LRU List和Dirty List分别又引入了Auxiliary List,目的是为了提高管理的效率.那么这个List的是怎么工作的呢?当我们的数据库初始化的时候,BUffer首先会被HASH到LRU的Auxiliary List(Auxiliary RPL_LST)上面,那么当buffer被使用后(注意:是使用而不是修改),会被从LRU的Auxililary List移动到LRU的Main List(MAIN RPL_LST)上面,这个时候当用户搜索Free buffer的时候,就可以从Auxiliary RPL_LST中开始,而DBWn主动搜索LRU List寻找Dirty buffer的时候就会从MAIN RPL_LST开始.这样一来就提高了我们数据库的搜索效率和性能
  
  现在呢,我们可以转储一下我们的buffer cache来看看具体的内容:
  一般我们不建议在生产环境中呢进行转储,因为文件会比较大,最好我们将max_dump_file_size设置成unlimited

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

我们可以来看看其中部分的信息,包括MAIN RPL_LST,AUXILIARY RPL_LST等等,同时还有一些队列信息

  *** 2008-01-07 16:45:24.375
*** SESSION ID:(9.38) 2008-01-07 16:45:24.359
Dump of buffer cache at level 4
  (WS) size: 0 wsid:  1 state: 0
    (WS_REPL_LIST) main_prev: 68ab0740 main_next: 68ab0740 aux_prev: 68ab0748 aux_next: 68ab0748curnum: 0 auxnum: 0
cold: 68ab0740 hbmax: 0 hbufs: 0
    (WS_WRITE_LIST) main_prev: 68ab075c main_next: 68ab075c aux_prev: 68ab0764 aux_next: 68ab0764curnum: 0 auxnum: 0
    (WS_XOBJ_LIST) main_prev: 68ab0778 main_next: 68ab0778 aux_prev: 68ab0780 aux_next: 68ab0780curnum: 0 auxnum: 0
    (WS_XRNG_LIST) main_prev: 68ab0794 main_next: 68ab0794 aux_prev: 68ab079c aux_next: 68ab079ccurnum: 0 auxnum: 0
  (WS) fbwanted: 0
  (WS) bgotten: 0 sumwrt:  0 sumscan: 0
  (WS) numscan: 0 hotscan:  0 dmoves: 0
MAIN RPL_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN RPL_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY RPL_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY RPL_LST Queue header (PREV_DIRECTION)[NULL]
MAIN WRT_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN WRT_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY WRT_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY WRT_LST Queue header (PREV_DIRECTION)[NULL]
MAIN XOBJ_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN XOBJ_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY XOBJ_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY XOBJ_LST Queue header (PREV_DIRECTION)[NULL]
MAIN XRNG_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN XRNG_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY XRNG_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY XRNG_LST Queue header (PREV_DIRECTION)[NULL]
  (WS) size: 0 wsid:  2 state: 0
    (WS_REPL_LIST) main_prev: 68ab0c0c main_next: 68ab0c0c aux_prev: 68ab0c14 aux_next: 68ab0c14curnum: 0 auxnum: 0
cold: 68ab0c0c hbmax: 0 hbufs: 0
    (WS_WRITE_LIST) main_prev: 68ab0c28 main_next: 68ab0c28 aux_prev: 68ab0c30 aux_next: 68ab0c30curnum: 0 auxnum: 0
    (WS_XOBJ_LIST) main_prev: 68ab0c44 main_next: 68ab0c44 aux_prev: 68ab0c4c aux_next: 68ab0c4ccurnum: 0 auxnum: 0
    (WS_XRNG_LIST) main_prev: 68ab0c60 main_next: 68ab0c60 aux_prev: 68ab0c68 aux_next: 68ab0c68curnum: 0 auxnum: 0
  (WS) fbwanted: 0
  (WS) bgotten: 0 sumwrt:  0 sumscan: 0
  (WS) numscan: 0 hotscan:  0 dmoves: 0
MAIN RPL_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN RPL_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY RPL_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY RPL_LST Queue header (PREV_DIRECTION)[NULL]
MAIN WRT_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN WRT_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY WRT_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY WRT_LST Queue header (PREV_DIRECTION)[NULL]
MAIN XOBJ_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN XOBJ_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY XOBJ_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY XOBJ_LST Queue header (PREV_DIRECTION)[NULL]
MAIN XRNG_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN XRNG_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY XRNG_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY XRNG_LST Queue header (PREV_DIRECTION)[NULL]

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-250313-1-1.html 上篇帖子: oracle优化内存,提高查询性能 下篇帖子: oracle数据块(block)结构详解
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表