IT运维管理，创造商业价值！
网站地图 | RSS订阅 | 设为首页 | 加入收藏
中国IT运维网首页 | 资讯中心 | 运维管理 | 信息安全 | CIO视界 | 云计算 | 最佳案例 | 运维资源 | 专题策划 | 知识库 | 论坛
中国IT运维网 > 运维管理 > 数据管理 > 正文

Oracle数据库提高命中率及相关优化

2010年02月22日
网络/网络

关于Oracle中各个命中率的计算以及相关的调优

1)Library Cache的命中率:

.计算公式:Library Cache Hit Ratio = sum(pinhits) / sum(pins)

  1. SQL>SELECT SUM(pinhits)/sum(pins)    
  2. FROM V$LIBRARYCACHE; 

通常在98%以上，否则，需要要考虑加大共享池，绑定变量，修改cursor_sharing等参数。

2)计算共享池内存使用率:

  1. SQL>SELECT (1 - ROUND(BYTES / (&TSP_IN_M * 1024 * 1024), 2)) * 100 || '%' 
  2. FROM V$SGASTAT  
  3. WHERE NAME = 'free memory' AND POOL = 'shared pool'; 

其中: &TSP_IN_M是你的总的共享池的SIZE(M)

共享池内存使用率，应该稳定在75%-90%间，太小浪费内存，太大则内存不足。

查询空闲的共享池内存:

  1. SQL>SELECT * FROM V$SGASTAT  
  2. WHERE NAME = 'free memory' AND POOL = 'shared pool'; 

3)db buffer cache命中率:

计算公式:Hit ratio = 1 - [physical reads/(block gets + consistent gets)]

  1. SQL>SELECT NAME, PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS,  
  2. 1 - (PHYSICAL_READS / (DB_BLOCK_GETS + CONSISTENT_GETS)) "Hit Ratio" 
  3. FROM V$BUFFER_POOL_STATISTICS  
  4. WHERE NAME='DEFAULT'; 

通常应在90%以上，否则，需要调整,加大DB_CACHE_SIZE

另外一种计算命中率的方法(摘自ORACLE官方文档<<数据库性能优化>>):

命中率的计算公式为:

  1. Hit Ratio = 1 - ((physical reads - physical reads direct - physical reads direct (lob)) / (db block gets + 
  2. consistent gets - physical reads direct - physical reads direct (lob)) 

分别代入上一查询中的结果值,就得出了Buffer cache的命中率

  1. SQL>SELECT NAME, VALUE  
  2. FROM V$SYSSTAT  
  3. WHERE NAME IN('session logical reads',  
  4. 'physical reads',  
  5. 'physical reads direct',  
  6. 'physical reads direct (lob)',  
  7. 'db block gets', 'consistent gets'); 

4)数据缓冲区命中率：

  1. SQL> select value from v$sysstat where name ='physical reads';  
  2. SQL> select value from v$sysstat where name ='physical reads direct';  
  3. SQL> select value from v$sysstat where name ='physical reads direct (lob)';  
  4. SQL> select value from v$sysstat where name ='consistent gets';  
  5. SQL> select value from v$sysstat where name = 'db block gets'; 

这里命中率的计算应该是

令 x = physical reads direct + physical reads direct (lob)

命中率 =100 - ( physical reads - x) / (consistent gets + db block gets - x)*100

通常如果发现命中率低于90%,则应该调整应用可可以考虑是否增大数据缓冲区

5)共享池的命中率：

  1. SQL> select sum(pinhits-reloads)/sum(pins)*100 "hit radio" from v$librarycache; 

假如共享池的命中率低于95%,就要考虑调整应用（通常是没使用bind var ）或者增加内存

6)计算在内存中排序的比率:

  1. SQL>SELECT * FROM v$sysstat t WHERE NAME='sorts (memory)';—查询内存排序数  
  2. SQL>SELECT * FROM v$sysstat t WHERE NAME='sorts (disk)';—查询磁盘排序数  
  3. --caculate sort in memory ratio  
  4. SQL>SELECT round(&sort_in_memory/(&sort_in_memory+&sort_in_disk),4)*100||'%' FROM dual; 

此比率越大越好,太小整要考虑调整,加大PGA

7)PGA的命中率:

计算公式:BP x 100 / (BP + EBP)

BP: bytes processed

EBP: extra bytes read/written

  1. SQL>SELECT * FROM V$PGASTAT  WHERE NAME='cache hit percentage'; 

或者从OEM的图形界面中查看

我们可以查看一个视图以获取Oracle的建议值:

  1. SQL>SELECT round(PGA_TARGET_FOR_ESTIMATE/1024/1024) target_mb,  
  2. ESTD_PGA_CACHE_HIT_PERCENTAGE cache_hit_perc,  
  3. ESTD_OVERALLOC_COUNT  
  4. FROM V$PGA_TARGET_ADVICE;  
  5. The output of this query might look like the following:  
  6. TARGET_MB  CACHE_HIT_PERC  ESTD_OVERALLOC_COUNT  
  7. ----------           --------------        --------------------  
  8.    63              23                   367  
  9.   125              24                    30  
  10.   250              30                     3  
  11.   375              39                     0  
  12.   500              58                     0  
  13.   600              59                     0  
  14.   700              59                     0  
  15.   800              60                     0  
  16.   900              60                     0 

在此例中:PGA至少要分配375M

我个人认为PGA命中率不应该低于50%

以下的SQL统计sql语句执行在三种模式的次数: optimal memory size, one-pass memory size, multi-pass memory size:

  1. SQL>SELECT name profile, cnt, decode(total, 0, 0, round(cnt*100/total,4)) percentage  
  2. FROM (SELECT name, value cnt, (sum(value) over ()) total FROM V$SYSSTAT WHERE name like 'workarea exec%'); 

8)共享区字典缓存区命中率

计算公式：SUM(gets - getmisses - usage -fixed) / SUM(gets)

命中率应大于0.85

  1. SQL>select sum(gets-getmisses-usage-fixed)/sum(gets)  
  2. from v$rowcache; 

9)数据高速缓存区命中率

计算公式：1-(physical reads / (db block gets + consistent gets))

命中率应大于0.90最好

  1. SQL>select name,value  
  2. from v$sysstat  
  3. where name in ('physical reads','db block gets','consistent gets'); 

10)共享区库缓存区命中率

计算公式：SUM(pins - reloads) / SUM(pins)

命中率应大于0.99

  1. SQL>select sum(pins-reloads)/sum(pins)  
  2. from v$librarycache; 

11)检测回滚段的争用

SUM(waits)值应小于SUM(gets)值的1%

  1. SQL>select sum(gets),sum(waits),sum(waits)/sum(gets)  
  2. from v$rollstat; 

12)检测回滚段收缩次数

  1. SQL>select name,shrinks  
  2. from v$rollstat, v$rollname  
  3. where v$rollstat.usn = v$rollname.usn;  
  4. ----------------------------------------------------------------------------- 

几个常用的检查语句

1. 查找排序最多的SQL:

  1. SQL>SELECT HASH_VALUE, SQL_TEXT, SORTS, EXECUTIONS  
  2. FROM V$SQLAREA  
  3. ORDER BY SORTS DESC; 

2.查找磁盘读写最多的SQL:

  1. SQL>SELECT * FROM 
  2. (SELECT sql_text,disk_reads "total disk" , executions "total exec",disk_reads/executions "disk/exec" FROM v$sql 
  3. WHERE executions>0 and is_obsolete='N' ORDER BY  4 desc)  
  4. WHERE ROWNUM<11 ; 

3.查找工作量最大的SQL(实际上也是按磁盘读写来排序的):

  1. SQL>select substr(to_char(s.pct, '99.00'), 2) || '%' load,s.executions executes,p.sql_text  
  2. from(select address,disk_reads,executions,pct,rank() over (order by disk_reads desc) ranking from 
  3. (select address,disk_reads,executions,100 * ratio_to_report(disk_reads) over () pct  
  4. from sys.v_$sql  
  5.  where command_type != 47)  
  6. where disk_reads > 50 * executions) s,sys.v_$sqltext p  
  7.  where s.ranking <= 5 and p.address = s.address  
  8. order by 1, s.address, p.piece; 

4. 用下列SQL工具找出低效SQL:

  1. SQL>select executions,disk_reads,buffer_gets,round((buffer_gets-disk_reads)/buffer_gets,2) Hit_radio,round(disk_reads/executions,2) reads_per_run,sql_text  
  2. From v$sqlarea  
  3. Where executions>0 and buffer_gets >0 and (buffer_gets-disk_reads)/buffer_gets<0.8  
  4. Order by 4 desc; 

5、根据sid查看对应连接正在运行的sql

  1. SQL>select /*+ push_subq */command_type,sql_text,sharable_mem,persistent_mem,
  2. runtime_mem,sorts,version_count,loaded_versions,open_versions,users_opening,executions,
  3. users_executing,loads,first_load_time,invalidations,parse_calls,disk_reads,buffer_gets,
  4. rows_processed,sysdate start_time,sysdate finish_time,’>’||address sql_address,’N’status  
  5. From v$sqlarea  
  6. Where address=(select sql_address from v$session where sid=&sid);  
  7. ***************Oracle 缓冲区命中率低的分析及解决办法****************** 

首先确定下面的查询结果:

1,缓冲区命中率的查询(是否低于90%):

  1. select round((1 - sum(decode(name,'physical reads',value,0)) /  
  2. (sum(decode(name,'db block gets',value,0)) + sum(decode(name,'consistent gets',value,0))) ),4) *100 || '%' chitrati  
  3. from v$sysstat; 

2,使用率的查询(有无free状态的数据快.):

  1. select count(*), status from v$bh group by status ; 

3,相关等待事件的查询(是否有相关等待事件)

  1. select event,total_waits from v$system_event where event in ('free buffer waits'); 

4,当前大小(是否已经很大)

  1. select value/1024/1024 cache_size from v$parameter where name='db_cache_size' 

5,top等待事件分析(Db file scatered read的比率是否大)

  1. select event ,total_waits,suml  
  2. from 
  3. (select event,total_waits,round(total_waits/sumt*100,2)||'%' suml  
  4. from 
  5. (select event,total_waits from v$system_event ),  
  6. (select sum(total_waits) sumt from v$system_event)  
  7. order by total_waits desc)  
  8. where rownum<6  
  9. and event not like 'rdbms%' 
  10. and event not like 'pmon%' 
  11. and event not like 'SQL*Net%' 
  12. and event not like 'smon%'; 

6,db_cache_advice建议值（9i后的新特性,可以根据他更好的调整cache_size）

  1. select block_size,size_for_estimate,size_factor,estd_physical_reads from v$db_cache_advice; 

说明分析:

缓冲区命中率(低于90的命中率就算比较低的).

没有free不一定说明需要增加,还要结合当前cache_size的大小(我们是否还可以再增大,是否有需要增加硬件,增加开销),


空闲缓冲区等待说明进程找不到空闲缓冲区，并通过写出灰缓冲区，来加速数据库写入器生成空闲缓冲区，当DBWn将块写入磁盘后，灰数据缓冲区将被释放，以 便重新使用.产生这种原因主要是:

1，DBWn可能跟不上写入灰缓冲区：i/0系统较慢，尽量将文件均匀的分布于所有设备，

2，缓冲区过小或过大。

3，可以增加db_writer_processes数量。

4,可能有很大的一个事物，或者连续的大事物

我们需要长期观察这个事件是否长期存在并数值一直在增大,如果一直在增大,则说明需要增大db_cache大小.或优化sql.


数据分散读等待,通常表现存在着与全表扫描相关的等待，逻辑读时，在内存中进行的全表扫描一般是零散地，而并非连续的被分散到缓冲区的各个部分，可能有索 引丢失，或被仰制索引的存在。该等待时间在数据库会话等待多块io读取结束的时候产生，并把指定的块数离散的分布在数据缓冲区。这意味这全表扫描过多，或 者io不足或争用，

存在这个事件,多数都是问题的,这说明大量的全部扫描而未采用索引.

db_cache_advice对我们调整db_cache_size大小有一定的帮助,但这只是一个参考，不一定很精确。

通过上面6种情况的综合分析,判断是否需要增加大cache_size. 或者把常用的（小）表放到keep区。

但多数的时候做这些不会解决质的问题,

而真正的问题主要是对sql语句的优化(如:是否存在大量的全表扫描等)

索引是在不需要改变程序的情况下,对数据库性能，sql语句提高的最实用的方法.

我在生产中遇到过类似的问题,200M的cache_size,命中率很低21%,但通过对sql语句的优化(添加索引,避免全表扫描),命中率增 加到96%,程序运行时间由原来的2小时减少到不到10分钟.

这就提到了怎么定位高消耗的sql问题.全表扫描的问题,在这里不做细致的解说,这里只说明方法,我会在相关的章节专门介绍怎么使用这些工具

1,sql_trace跟踪session.用tkprof 分别输出磁盘读,逻辑读,运行时间长的sql进行优化.这些高消耗的sql一般都伴随着全表扫描.

2,statspack分析.在系统繁忙时期进行时间点的统计分析,产看TOP事件是否有Db file scatered read.并查看TOP sql语句是否存在问题等.

注：电脑学习网首发。

还要说一句：当然在硬件允许的情况下，尽量增大db_cache_size 减少磁盘读，但并不是越大越好，一定要根据自己的库数据量的程度来调节，因为大的db_cache_size同样会增大数据库管理的开销，当然可能开销并 不会明显的影响数据库的性能，硬件价格也越来越低，这就需要我们具体问题具体分析了，在我看来物尽其用就最好了，尽量不要浪费，找到问题的本质。调优是一 件很艺术的事。

***********************Oracle数据库缓冲区命中率***************** 


1、查看Oracle数据库缓冲区命中率

  1. select a.value + b.value "logical_reads", c.value "phys_reads",  
  2.     round(100 * ((a.value+b.value)-c.value) / (a.value+b.value)) "BUFFER HIT RATIO" 
  3.     from v$sysstat a, v$sysstat b, v$sysstat c  
  4.     where a.statistic# = 40 and b.statistic# = 41  
  5.     and c.statistic# = 42; 

2、Tags: oracle 

数据库缓冲区命中率：

  1. sql>select value from v$sysstat where name ='physical reads';  
  2. value  
  3. 3714179  
  4. sql>select value from v$sysstat where name ='physical reads direct';  
  5. value  
  6. 0  
  7. sql>select value from v$sysstat where name ='physical reads direct(lob)';  
  8. value  
  9. 0  
  10. sql>select value from v$sysstat where name ='consistent gets';  
  11. value  
  12. 856309623  
  13. sql>select value from v$sysstat where name ='db block gets';  
  14. value  
  15. 19847790 

这里命中率的计算应该是

令x＝physical reads direct + physical reads direct(lob)

命中率＝100－(physical reads -x)/(consistent gets +db block gets -x)*100

通常如果发现命中率低于90%，则应该调整应用可以考虑是否增大数据加

共享池的命中率

  1. sql> select sum(pinhits)/sum(pins)*100 "hit radio" from v$librarycache; 

如果共享池的命中率低于95％就要考虑调整应用（通常是没应用bind var)或者增加内存。

关于排序部分

  1. sql> select name,value from v$sysstat where name like '%sort%'; 

如果我们发现sorts(disk)/(sorts(memory)+sorts(disk))的比例过高，则通常意味着 sort_area_size部分内存教较小，可考虑调整相应的参数。

关于log_buffer

  1. sql>select name,value from v$sysstat where name in ('redo entries','redo buffer allocation retries'); 

假如redo buffer allocation retries/redo entries的比例超过1%我们就可以考虑增加log_buffer.

上一篇：MySQL数据库灾备必备基础知识经验

下一篇：中小企业部署iSCSI SAN六大注事项

声明：中国IT运维网登载此文出于传递更多信息之目的，并不意味着本站赞同其观点或证实其描述。其原创性以及文中陈述 文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或 承诺，请网友及读者仅作参考，并请自行核实相关内容。如原作者不同意在本网站刊登内容，请及时通知本站予以删除。凡本网站注明"来源：中国IT运维网"的作品，在授权范围内使用时，请保留注明"来源：中国IT运维网"。
发表评论请到：http://bbs.cnitom.com

相关阅读

图文热点

哪些企业真正需要系统具备横向扩展能力
哪些企业真正需要系统具备横向扩展能力在此之前，你可能没有考虑过你的IT部门需要一个横向扩展(也称向外扩展)系统。在如...
DB2 10新功能：从Oracle迁移更容易
DB2 10新功能：从Oracle迁移更容易这里就有一些： 局部类型 此功能允许PL/SQL和SQL PL块在BEGINEND块中定义局部类型...

本类热点

关于我们 | 欢迎投稿 | 服务条款 | 免责声明 | 隐私保护 | 友情链接

CopyRight © 2009-2012 [中国IT运维网 www.cnitom.com] All Rights Reserved.

IT运维管理，创造商业价值！

京ICP备10047140号

联系邮箱：；QQ联络：1360095750。