Oracle数据库性能优化方法论和最佳实践
上QQ阅读APP看书,第一时间看更新

2.4 基于工作单元的响应时间分析优化方法论

2.4.1 UOWTBA优化方法论的导入

在RTA工作方法论的基础上,Craig Shallahamer结合吞吐量和响应时间关系曲线图提出了基于工作单元的响应时间分析方法论(Unit of Work Time Based Analyze,UOWTBA或者Unit of Response Time Analyze,UOWRTA)。UOWTBA方法论相较于RTA方法论而言,在强调响应时间时,同等强调了吞吐量的重要性,它通过衡量操作单元的响应时间而不是绝对时间来完成性能优化。

工作单元的最简单说法就是某个特定操作粒度之上的操作,比如一次逻辑读、一次物理读、一次latch gets、一次mutex gets、一次parse call等。工作单元的粒度根据需要分析的场景而定,相对来说,由于工作单元的时间响应需要作为顶层业务作业的可比较单元,所以需要选择相对基础的细粒度工作。

再次来看吞吐量和响应时间关系曲线。

吞吐量和响应时间关系曲线极为明确地揭示了一个本质现象:任何输出响应时间都是在特定的输入吞吐量下才会表现出其业务价值的。UOWTBA优化方法论强调了输入吞吐量单元,其响应时间总是标记为单个输入吞吐量单元的响应时间。

性能优化的目标就是延长曲线突变点,从而使其可以获得更高的吞吐量。TBA关键的问题在于缺乏衡量吞吐量的基础标准,或者对于每个业务系统都具有其特定吞吐量描述,这样就给TBA分析带来巨大的困难。比如CRM业务系统,其标准吞吐量为:每小时5000个受理、20000个开通等描述,但会发现你无法把这些描述和数据库的监控关联起来。

Oracle数据库有很多标记吞吐量的指标变量,比如executes、user calls、transactions等,事实上,Oracle 11gR2的RTA方法论中也涉及了衡量基于executes、user calls、transactions等输入吞吐量的输出响应时间。大家可以很明显地看到,虽然从业务输入层面上transactions、executes都是可以感知的输入吞吐量的,但是execute和execute、transactions和transaction之间的个体差异太大,使其输入吞吐量缺乏一致性比较的基础。比如执行10万次的SQL语句“select * from dual”自然无法和执行10万次的SQL语句“select * from dba_objects”相比较。transactions也是同样的道理,除了一些业务极为均匀的系统外,无法作为吞吐量输入衡量的基础。

为了获得一个通用的业务特征和吞吐量的描述,笔者在TBA的基础之上进行了进一步的研究,希望获得更好的描述访问特征和访问能力的监控指标,以更有效地完成TBA分析。Craig A. Shallahamer的研究成果正好和我所寻求的方向一致,基于工作单元的TBA分析方法可以很好地弥补TBA方法的不足。Craig A. Shallahamer的具体成果可以参考他的网站:http://www.orapub.com