简单案例描述: 某市工商局的综合业务处理系统长期以来在业务忙碌的时候业务运行缓慢,指导生成AWR报告,发现Cache Hit Ratio只有72%,Top 5 wait主要为db file sequence read和db file scattered read。检查SGA Buffer Cache配置,只有375m。简单增加Buffer Cache到2GB,所有性能问题都消失。
在现在大内存时代,一个性能优化工作者遇到上述案例的性能优化,就和中彩票类似,一般只有在菜鸟安装的数据库中才会存在。
基于命中率的分析方法是一个古老的性能优化方法论,不仅仅是在Oracle数据库,在Sybase,DB2等数据库,甚至在任何IT设备中都存在基于命中率的分析方法。对于Oracle数据库而言,基于局部命中率的分析方法基于以下朴素的观点:如果构成系统的每个零件都表现优异,那么整个系统的表现也是优异。当然任何具有流程知识的人员都知道以上观点是不可靠的。
命中率的分析方法作用于性能优化具有以下致命的缺陷:
(1)、命中率分析仅仅关注作用于自身,不关心外部信息。我们这里以马路收费站处作为例子,命中率分析方法仅仅关心通过我收费站的吞吐量是否正常,而看不到为了等待穿过收费站的长长的队伍。从命中率的观点出发,只要我收费站操作顺利,不出故障,即使队伍排成10KM的长龙也是性能优异的。
(2)、命中率分析方法通过全局平均化模糊了个体,而大部分性能问题都是基于个体的。比如某个心外科手术医生对于心脏搭桥手术的成功率为98%,每年做500例手术,但是对于那个10个落在2%的病人来说就不是2%,而是100%的丢了性命。
尽管命中率分析方法具有明显的不可靠,但由于其获取数据成本低廉以及易于理解,也确实具备描述目标基本性能的能力,事实上成为了IT设备甚至生活中工作性能优异的标准性能描述方法。对于命中率分析方法,我们可以这样来描述看待它:命中率分析结果优秀不能保证业务系统或者数据库具有优异的性能,但命中率分析结果不好基本可以确认业务系统或者数据库不具备优异的性能。在Oracle性能优化中,命中率分析方法不足以成为独立工作的方法论,但必须成为辅助分析的一部分,确保Oracle每一个部件自身工作表现优异才可以使业务性能表现优异,Oracle的某个部件工作表现不正常,几乎可以断定业务性能不会反应良好。
命中率可以体现不同颗粒度上,系统全局层,会话层,对象层和SQL层。我们以Buffer Cache命中率来说明命中率分析的不同层次。
计算公司:Buffer Cache Hit Ratio:= logical reads/(logical reads+physical reads)
系统全局层:v$sysstat或者V$BUFFER_POOL_STATISTICS
会话层:v$sesstat或者v$sessio
对象层:v$segstat或者v$segment_statistics
SQL层: v$sqlarea
具体到某Session的一条SQL或者某一时间段的命中率还可以通过SQL Trace或者10046跟踪得到。
all count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 19 0.72 0.75 0 0 0 0
Execute 19 0.17 0.13 0 0 0 0
Fetch 19 0.65 0.64 0 83049 12369 114
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 57 1.54 1.52 0 83049 12369 114
在本章不对各种命中率指标进行计算和分析,计算和分析的工作在涉及到具体构件时候来进行阐述。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/25462274/viewspace-1966476/
,如需转载,请注明出处,否则将追究法律责任。