第2章 Oracle性能优化方法论的发展
Oracle数据库在开发和使用过程中对数据库的性能优化极为重视，几乎在每个版本的更新中都会对可优化的数据库做出改善。不仅如此，Oracle数据库还会使用优化方法来指导性能优化，会不断推出新的性能优化方法论，并依据优化方法论持续完善其可观察的性能优化体系。
从Oracle 6到现在的Oracle 12c，经历了Oracle 7、Oracle 8、Oracle 8i、Oracle 9i & R2、Oracle 10gR1 & R2、Oracle 11gR1 & R2和Oracle 12c等版本的更新。从Oracle 7开始奠定Oracle的江湖地位，Oracle 8开始超越，到Oracle 8i的大红大紫，以及Oracle 9i以来的持续保持和发展，每个版本都有其特色和定位。在Oracle的主要发展版本中可以看到Oracle性能优化方法论的持续发展。Oracle 7中成熟的命中率分析方法，Oracle 8开始出现OWI（Oracle Wait Interface）的影子，到Oracle 8i，OWI开始走向前台并快速成熟起来。由于OWI方法的简单实用，目前它是Oracle性能优化方法论中的主流。Oracle 8i能大红大紫应该有OWI方法的贡献。从Oracle 8i开始，Oracle的性能优化方法论远远超过了其他同类的数据库，Oracle真正成为性能优化就绪的数据库。Oracle 9i开始出现TBA（Time Based Analyze）和基线管理，并在Oracle 10g版本中成熟，在Oracle 11g版本中持续完善。从Oracle 10g开始，Oracle认识到平均化的负面影响，使性能检测数据的粒度越来越细致，已经可以快速发现平均化可能面临的问题。
Oracle 11gR2中的TBA性能分析方法论还不太成熟，但是TBA方法已经在一些复杂的性能优化案例中体现出了威力。除TBA之外，Craig Shallahamer提出了UOWTBA（Unit of Work Time Based Analyze）方法论，笔者认为UOWTBA是TBA方法的重大改善，可使TBA方法被真正有效地使用。本书将以UOWTBA方法为基础，提出了基于流程、资源和组件的综合性能优化方法论，构建了全新的Oracle数据库性能优化的可测量体系。
2.1 基于局部命中率分析的优化方法论
案例描述：某市工商局的综合业务处理系统报告长期以来在业务忙碌的时候运行缓慢。笔者指导客户生成AWR报告，发现Cache Hit Ratio只有72%，Top 5 wait主要为db f?ile sequence read和db f?ile scattered read。检查SGA buffer cache配置，只有375MB。简单增加buffer cache到2GB，所有性能问题都消失。
在目前，一个性能优化工作者遇到上述案例的性能优化需求，与中彩票类似，一般只有在菜鸟安装的数据库中才会存在。
基于命中率的分析方法是一个古老的性能优化方法论，不仅是在Oracle数据库中，在Sybase、DB2等数据库，甚至在任何IT设备中都存在基于命中率的分析方法。对于Oracle数据库而言，局部命中率的分析方法基于以下朴素的观点：如果构成系统的每个零件都表现优异，那么整个系统的表现也是优异的。当然，任何具有流程知识的人员都知道以上观点是不可靠的。
如图2-1所示，以我们的经验来看，其中B路段会成为高吞吐量场景中的瓶颈，会导致整条马路的车流不畅（那是因为有全局观点了）。但是，如果站在B路段内部来看问题，即使在业务最高峰的时候，B路段也表现出运行非常流畅，吞吐量表现极好，也许会成为表现最好的路段（如臭名昭著的新岭隧道，有兴趣的读者可以上网搜索一下）。基于命中率的分析方法与B路段的观察者和管理者一样，它只关心内部的表现或者自己的表现。
命中率的分析方法作用于性能优化，具有以下致命的缺陷。
命中率分析仅关注和作用于自身，不关心外部信息。
这里以马路收费站作为例子，命中率分析方法仅关心通过收费站的吞吐量是否正常，而看不到等待穿过收费站的长长的队伍。从命中率的观点出发，只要收费站操作顺利，不出现故障，即使队伍排成10km的长龙也是性能优异的。
命中率分析方法通过全局平均化模糊了个体，而大部分性能问题都是基于个体的。
比如某个心外科手术医生对于心脏搭桥手术的成功率为98%，每年做500例手术，但是对于那10个落在2%的病人来说成功率就不是98%，而是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跟踪得到，如下：