`
小嘴冰凉
  • 浏览: 455801 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

Oracle Buffer Cache原理总结(一)

阅读更多
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]
分享到:
评论

相关推荐

    Oracle Buffer和Cache的区别

    在Oracle数据库系统中,Buffer Cache是内存结构的一部分,它存储了最近访问过的数据块的副本,这些数据块通常来自数据库的表空间和索引。当数据库需要读取或修改数据时,它会尝试首先从Buffer Cache中查找,而不是...

    深入Buffer Cache 原理

    Buffer Cache作为System Global Area (SGA) 的一部分,在Oracle数据库中扮演着极其重要的角色。它的主要任务是缓存数据块以减少磁盘I/O操作,提高数据访问速度。通过优化Buffer Cache的管理机制,可以显著提升数据库...

    oracle性能调优之buffer cache

    Buffer Cache 是 Oracle 中的一种缓存机制,负责将磁盘上的数据 block 读取到内存中,以提高数据库的访问速度。在本文中,我们将详细介绍 Buffer Cache 的工作原理、状态、管理和优化方法。 Buffer Cache 的工作...

    oracle_buffer_cache深入分析

    而为了提高数据访问速度,Oracle 引入了一个重要的内存组件——Buffer Cache(数据高速缓存区)。Buffer Cache 的核心作用在于减少磁盘 I/O 操作,因为相较于磁盘访问,内存访问速度快得多。 **1.1 Buffer Cache ...

    Oracle buffer cache

    Oracle Buffer Cache 是 Oracle 数据库中的一种内存缓存机制,用于提高数据库的性能。Buffer Cache 通过将频繁访问的数据块缓存在内存中,减少了磁盘 I/O 操作,从而提高了数据库的响应速度。 Buffer Cache 的原理...

    Oracle 中 Buffer Cache 的研究.pdf

    总之,Oracle的Buffer Cache是数据库性能优化的重要环节,理解其内存结构、工作原理和参数设置对于提升数据库性能具有重要意义。通过对Buffer Cache的深入研究和合理配置,可以显著改善数据库系统的响应时间,提高...

    深入学习Buffer cache

    Buffer Cache是Oracle数据库管理系统中的一个重要组件,主要用于存储从数据文件中读取的数据块,以减少对磁盘的物理I/O操作,从而显著提升数据库的性能。在Oracle 10g中,Buffer Cache的设计和管理更加先进,实现了...

    Performance Analysis of the Linux Buffer Cache While Running an Oracle OLTP Workload

    本文档提供了一项针对 Linux 缓冲区缓存(Buffer Cache)在运行 Oracle OLTP(在线事务处理)工作负载时的性能分析研究。通过一系列测试收集了缓冲区缓存命中率及测试运行时间数据,为理解该系统复杂操作提供了宝贵...

    oracle在线备份原理

    4. Oracle的后台进程LGWR(Log Writer)将REDO LOG BUFFER的内容写入redo log files,这些文件是一组操作系统文件,通常设置为镜像以保证数据安全。 Oracle数据库有两种运行模式,非归档模式和归档模式,它们在处理...

    Oracle性能调优原理及具体手段

    ### Oracle性能调优原理及具体手段 #### 一、Oracle结构与组成部分 Oracle数据库系统主要由实例(Instance)和数据库文件组成。 ##### 1.1 Oracle实例(Instance) Oracle实例是指运行在计算机上的软件环境,它...

    oracle checkpoint工作原理

    这就意味着,在数据库崩溃或异常关闭的情况下,数据缓冲区(buffer cache)中未写入磁盘的脏数据(已修改但未持久化到数据文件的数据块)需要通过日志文件进行恢复,以保证数据的一致性。 Checkpoint机制正是用于标记...

    Oracle+RAC原理浅谈.ppt

    Oracle RAC 原理浅谈 Oracle RAC(Real Application Clusters)是一种高可用性、高性能、可扩展的集群解决方案,旨在提供高效、可靠的数据库服务。以下是 Oracle RAC 的一些关键知识点: RAC 部署技巧及维护注意...

    Oracle 数据缓冲区调优精选

    一、理解Oracle Buffer Cache 1. 缓冲区缓存结构:Oracle的数据缓冲区是由多个缓冲区组成的,每个缓冲区又包含一个或多个数据块。数据块是Oracle读写数据的基本单位,大小可配置。 2. 数据缓冲区的访问:当SQL查询...

    oracle RMAN 备份恢复总结

    Oracle Recovery Manager(RMAN)是Oracle数据库管理系统中的一个重要组件,专为数据库的备份、恢复和维护设计。RMAN 自从Oracle 8版本开始引入,并在后续版本中不断加强和完善,尤其在Oracle 9i中展现出更为强大的...

    Oracle RAC原理.pdf

    Oracle Real Application Clusters (RAC) 是Oracle数据库的一项高级特性,它允许多个实例同时访问同一个物理数据库,从而实现高可用性和高性能。Oracle RAC通过提供集群数据库解决方案,确保了在单点故障或系统维护...

    Oracle数据库中的Cache对象

    在Oracle数据库中,Cache对象是一个非常关键的组成部分,它涉及到数据库的性能优化和内存管理。Oracle数据库使用缓存来提高数据访问速度,减少磁盘I/O,从而提升系统整体性能。本文将深入探讨Oracle数据库中的Cache...

    Oracle-RAC原理浅谈.ppt

    Oracle RAC,全称为Real Application Clusters,是Oracle数据库系统的一种高级特性,旨在提供高性能、高可用性和高可扩展性的数据库解决方案。Oracle RAC允许多个数据库实例在同一物理数据库上同时运行,实现数据的...

    oracle数据库性能优化与内部原理解析

    通过优化内存分配,如合理配置共享池(Shared Pool)、数据库缓冲区(Database Buffer Cache)等,可以显著提高数据库的处理能力。 6. 并发和锁定优化:监控和调整数据库的并发机制,优化锁的使用策略和死锁的处理...

Global site tag (gtag.js) - Google Analytics