ITPub博客

首页 > Linux操作系统 > Linux操作系统 > oracle温故知新--buffer cache(三)决定Buffer cache的几个指标

oracle温故知新--buffer cache(三)决定Buffer cache的几个指标

原创 Linux操作系统 作者:bbs159 时间:2011-06-16 18:40:30 0 删除 编辑

一、buffer cache的几个重要指标数:

 SELECT NAME, VALUE
   FROM V$SYSSTAT
  WHERE NAME IN ('session logical reads',                
                 'physical reads',                
                 'physical reads direct',                
                 'physical reads direct (lob) ',                
                 'consistent gets',                
                 'db block gets',                
                 'free buffer inspected',                
                 'free buffer requested',                
                 'dirty buffers inspected',                
                 'pinned buffers inspected');

Session Logical Reads:所有的逻辑读的数据块的数量。

       

        Free Buffer Inspected指标:

            为寻找空闲buffer之前所检查块的总数量,即跳过块的数量。如果该值接近脏数据块的数量,则表明空闲块很少,该值应尽可能小

            于脏块的数量。

           

        Free Buffer Waits:

            sessionLRU list上没有寻找到空闲可用数据块或者搜寻可用的内存数据块被暂停的时候,该发生该事件,此为等待DBWn将脏

            块写入到数据文件的等待数。除此之外,会话在做一致性读时,需要构造数据块在某个时刻的前映像(image),此时需要申请内

            存来存放这些新构造的数据块,如果内存中无法找到这样的内存块,也会发生这个等待事件。

           

        Buffer Busy Waits:

            用户服务器进程已找到所需的数据块,但该块正被其它进程使用或多个进程同时要修改该块,此时需要等待的时间。

            当一个会话需要读取一个数据块,但这个数据块正在被另一个会话读取到内存中时,此时同样发生Buffer Busy Waits事件。

Buffer busy waits产生原因

产生Buffer busy waits的几种情形

            DATA BLOCK,数据块的竞争,该情形通常是基于表段和索引段上的竞争,下面的处理办法

                尽可能缩小SQL语句的查询字段,查询范围,如不使用select * 查询,将like子句改为直接赋值等

                检查索引的合理性。如使用了sequence生成的索引,其索引键通常位于相同的块,因此可以使用反向索引避免此问题

                使用自动段空间管理或增加空闲列表,以避免多个进程同时插入相同的块

                查询视图v$session_wait来获得热点块的文件ID,块ID,通过这些信息来获得对象ID,进一步对该对象进行调整

            UNDO Header

                基于UNDO段头部的竞争,如果未使用自动撤销段管理模式,则需要增加更多的回滚段

            UNDO BLOCK

                基于UNDO段块的竞争,如果未使用自动撤销段管理模式,则需为回滚段分配更大的尺寸

 

产生Free Buffer waits的几种情形    

            DBWn进程来不及将数据写入到数据文件,导致需要等待被释放的空间

            I/O系统速度过于缓慢

                确保数据库文件是否分布在不同的磁盘上,或增加更高性能的磁盘

            资源等待造成I/O系统过慢,如latch等待

                确保数据库文件是否分布在不同的磁盘上,或增加更高性能的磁盘

            Buffer cache太小,导致DBWn来不及将脏数据写入到数据文件

                需要增大buffer cache的尺寸

            Buffer cache太大,而单一的DBWn进程需要多次才能将数据写入到文件

                减少buffer cache的尺寸,或增加更多的DBWn进程

 

三 命中率

计算命中率的思想

            1-(物理读的次数-总的请求次数)

 

physical reads

            Oracle级别来理解,从磁盘读数据块的次数,一次可以读多块,由参数db_file_multiblock_read_count来控制。此种读方式使用

            db cache.

            形象示意:db_file ==> db_cache ==> pga

 

        physical reads direct

            有些数据块不会先从硬盘读入内存再从内存读入PGA再传给用户,而是绕过SGA直接从硬盘读入PGA。比如并行查询以及从临时表空

            间读取数据。这部分数据块由于不缓存使得hit ratio不会被提高。其在计算hit ratio时应当被扣除。

            形象示意:db_file  ==> pga

                通常,disk sort / hash , exp direct=Y ,都会有physical reads direct

         

 

physical reads direct (lob)

            对于大值对象,如LOB数据类型以及LOB段,Oracle可以绕过buffer cache而直接使用PGA,其原理等同于physical reads direct

           

        使用physical reads directphysical reads direct (lob)的优点:

            对于一个大操作,需要请求大量数据块,假设又使用并行执行,且执行次数就那么一次,这个时候就适合使用direct方式,

            如果还是走buffer cache则需要把buffer cache里已缓存的数据库都清空

            注意physical write /direct 同理

 

        session logical reads

            发出的总的请求次数,此处是指从database buffer cache中请求块。对于一致性读,则这些缓冲包含来自回滚段的数据

 

 

下面是另一种不同的计算命中率的方法,通常用在10g11g之中

SELECT NAME,

                   physical_reads,

                   db_block_gets,

                   consistent_gets,

                   ROUND((1 - (physical_reads / (db_block_gets + consistent_gets))) * 100) || '%' ratio

            FROM   V$BUFFER_POOL_STATISTICS

            WHERE  NAME = 'DEFAULT';

 

            SELECT (1 - (SUM(decode(NAME, 'physical reads', VALUE, 0)) /

                   (SUM(DECODE(NAME, 'db block gets', VALUE, 0)) +

                   SUM(DECODE(NAME, 'consistent gets', VALUE, 0))))) * 100 "Hit Ratio"

            FROM   v$sysstat;

consistent gets from cache

                在回滚段Buffer中的数据构造一致性读数据块的总次数。其产生原因是由于其他会话对当前数据块进行操作,如update操作,

                但是由于我们的查询是在这些修改之前调用的,所以需要使用回滚段中的数据块的前映像进行查询,来保证数据的一致性。

                这样就产生了一致性读。

               

            db block gets     

                在操作中提取的块数目,而不是在一致性读的情况下而产生的块数。

                当前块(current,相对于cosistent读而言,current总是最新的块),从buffer cache中请求的次数。当前块意思就是在操作

                中正好提取的块数目,而不是在一致性读的情况下而产生的块数。通常的情况下,一个查询提取的块是在查询开始的那个时

                间点上存在的数据块,当前块是在这个时刻存在的数据块,而不是在这个时间点之前或者之后的数据块数目。

 

            physical reads cache   

                从磁盘读入到buffer cache中的总次数。

                产生的主要原因是:在数据库高速缓存中不存在这些块, 全表扫描, 磁盘排序等

 

                db_block_gets + consistent_gets两者之和作为总的请求次数,在与physical_reads相比进而得到命中率

 

            此方法与前面命中率计算的方法不一样,更简单直观。

 

影响命中率的因素

        全表扫描(小标尚可,对于大表而言I/O性能更差。而且全表扫描总是被置于LRU的最尾端,随时被aged out)

        不同数据定义和应用程序设计影响命中率

        大表的随机访问(非顺序)

        不均衡的cache hit

       

        命中率需要考虑的问题

            a.对相同的大表和索引的重复扫描容易造成命中率很高的假象。定期检查频繁使用且返回结果集很大的SQL语句,确保这些SQL

                句使用了最优的执行计划。

            b.避免返回查询相同的数据,尽可能将获得的结果集缓存的客户端程序或中间件。

            c.大表的全表扫描问题,直接将其放置到LRU的尾端,容易aged out

                (小表通常指全表扫描时占用buffer cache 20%或拥有个数据块)

            d.对较大OLTP系统而言,表中的很多行仅仅被访问次或很少的次数,基于此,这些块不易长时间占住buffer cache

            f.对于并行查询或排序等,持续增加buffer cache的大小并无实际意义,优化效果并明显。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/13824386/viewspace-700082/,如需转载,请注明出处,否则将追究法律责任。

上一篇: DBMS_PROFILER 使用
请登录后发表评论 登录
全部评论

注册时间:2011-05-11

  • 博文量
    26
  • 访问量
    40745