ITPub博客

首页 > Linux操作系统 > Linux操作系统 > performance tunning --buffer cache01

performance tunning --buffer cache01

原创 Linux操作系统 作者:oracle_db 时间:2012-06-04 13:06:01 0 删除 编辑
BUFFER CACHE调整指标一般有那些?
FREE BUFFER INSPECTED:当在内存中找一个块来用时,发现找不到这个块,这个时候需要进行物理读把块从磁盘中读取到内存中,在读进来之前要找一个FREE BUFFER,但是这个FREE BUFFER可能一次找不到要找很多次才能找到,找到这个FREE BUFFER前检查了多少个BUFFER可以由这个指标反应出来。性能稍微差
FREE BUFFER WAITS:当在找寻一个块时,找不到可用块,这个时候就要等待DBWN把脏数据写回到磁盘,这样BUFFER CACHE中才有可用的块,如果DBWN没写完,在这样的情况下申请新块就会出现等待。性能最差
BUFFER BUSY WAITS:当在内存中寻找某一块,但是发现这个块已经被别的东西在使用,那当前申请这个块的操作就只有运行等待。性能差
如果查看这几个指标的值?
SQL> select * from v$sysstat where name like '%buffer%';

STATISTIC# NAME                                CLASS      VALUE    STAT_ID
---------- ------------------------------ ---------- ---------- ----------
        69 DBWR checkpoint buffers writte          8          0 1208600358
           n

        70 DBWR thread checkpoint buffers          8          0 3905787588
            written

        71 DBWR tablespace checkpoint buf          8          0 2649259263
           fers written

        72 DBWR parallel query checkpoint          8          0 1768645316
            buffers written

STATISTIC# NAME                                CLASS      VALUE    STAT_ID
---------- ------------------------------ ---------- ---------- ----------

        73 DBWR object drop buffers writt          8          0  658143835
           en

        76 DBWR revisited being-written b          8          0 2773697723
           uffer

        93 free buffer requested                   8       5557 3411924934
        94 dirty buffers inspected                 8          0 1344569897
        95 pinned buffers inspected                8          0  833456521
        96 hot buffers moved to head of L          8          0 2030212224

STATISTIC# NAME                                CLASS      VALUE    STAT_ID
---------- ------------------------------ ---------- ---------- ----------
           RU

        97 free buffer inspected                   8          0  941676439
       102 commit cleanout failures: buff          8          0 1626141486
           er being written

       110 switch current to new buffer            8         36 1312802324
       135 redo buffer allocation retries          2          0 1446958922
       320 buffer is pinned count                 72     113962 1300470380
       321 buffer is not pinned count             72      24932 2670431739
       322 no buffer to keep pinned count         72          1 3528454686

17 rows selected.

SQL> 
SQL> select event,total_waits
  2  from v$system_event
  3  where event like '%buffer%';

EVENT                                                            TOTAL_WAITS
---------------------------------------------------------------- -----------
latch: cache buffers chains                                                1
buffer busy waits                                                          1
latch: cache buffers lru chain                                             1

SQL> 

这里查询出BUFFER BUSY WAITS出现了一次,如何查询这一次在在争用那一个块呢?
SQL> col parameter1 format a10
SQL> col parameter2 format a10
SQL> col parameter3 format a10
SQL> select name,parameter1,parameter2,parameter3 from v$event_name
  2  where name ='buffer busy waits';

NAME                           PARAMETER1 PARAMETER2 PARAMETER3
------------------------------ ---------- ---------- ----------
buffer busy waits              file#      block#     class#

SQL> 
根据文件号和块号就可以查到那个块在被争用。
导致BUFFER BUSY WAITS出现的原因有那些?
DATA BLOCK:如果因为一个对象竞争对象中的同一块,检查查询语句是否有选择性。访问的对象不同但是都在同一块中也会导致
UNDO HEADER:这种情况应该采用自动UNDO管理表空间
UNDO BLOCK:这种情况应该增加块大小

FREE BUFFER WAITS出现原因?
DBWN工作效率低,或者说IO效率低下,这时候需要确保文件分布在不同磁盘上,换快磁盘。还有一种可能是BUFFER CACHE空间太小,这就要调整BUFFER CACHE大小。还有一种就是如果说BUFFER CACHE空间够大,增加DBWN的数量来避免出现FREE BUFFER WAITS.

如何衡量CATCH 的命中率?
一个方法是从SYSSTAT中看
SQL> select 1-(phy.value-lob.value-dir.value)
  2  /ses.value "cache hit ratio"
  3  from v$sysstat ses,v$sysstat lob,
  4       v$sysstat dir,v$sysstat phy
  5  where ses.name='session logical reads'
  6  and dir.name='physical reads direct'
  7  and lob.name='physical reads direct (lob)'
  8  and phy.name='physical reads';

cache hit ratio
---------------
     .890503408

SQL> 

在11G中算法又不一样。。。计算命中率要看数据库版本。
另一个是从STATSPACK中读取

总的计算方法是:(1-物理读的次数)/总的申请块的次数=命中率

物理读:实际发生IO的次数,从磁盘读取文件到内存的次数
SESSION LOGIC READS:简单的说叫发出的总的请求次数
PHYSIC READ DIRECTOR:它是直接读,不会用到CACHE
PHYSIC READ DIRECTOR(LOB):这个操作也不会用到CACHE 所以要除开

数据访问方式影响命中率?
全表扫描
数据或者应用的设置不合理

命中率不是全部?
并不是说命中率越高越好,只是调优的一个指标。减少ORACLE的负荷是关键,因为都知道,他不干活的时候效率最高!在决定增加或减少BUFFER CACHE SIZE的时候需要想很多东西,查看V$DB_CACHE_ADVISE.增大了也不一定会提升性能,避免重复扫描,避免反复查询同样的SQL,ORACLE在对大表操作的时候,这些块被放到LRU末尾。排序的表的SIZE要考虑等等。也不要一贯去增加BUFFER CACHE大小

在增加BUFFER CACHE大小前应该做的工作?

系统中等待事件已经调节好了
SQL语句已经调节好了
SGA固定在内存,防止操作系统把它PAGE OUT写到交换区
确保上一次增加BUFFER CACHE是有效的
在看CATCH命中率是否低下




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

下一篇: ORA-16038
请登录后发表评论 登录
全部评论

注册时间:2008-11-13

  • 博文量
    158
  • 访问量
    306174