1.2 性能优化目标的确定和衡量
性能优化，顾名思义就是一个改善的过程，通过这个过程实现从当前A到B的目标，其中A和B必须可以被描述和衡量。其中，A为当前状态的描述和测量。B为需要达到目标状态的描述和测量。
很遗憾的是，在现实的Oracle性能优化实践中，很多情况下A和B不可描述或未被准确描述，只知道我要变快，而且是尽可能的快，最终使性能优化变成一锅乱炖。
大家都知道，性能优化的常规目标是使响应速度变快，但快和慢是相对而言的，如果两者没有一致的描述基准，那么就会产生问题。比如，如果觉得现在的系统速度慢，那就必须先弄清楚是如何衡量速度慢的，为什么这种状况就认为它速度慢了呢？以一个电信受理业务为例，客户反馈受理很慢，需要进行优化，要变快。客户只会告诉你受理慢，不会告诉你更多，其他的东西需要性能优化工作者去挖掘，比如和客户进行沟通，也许你会郁闷地发现，和你沟通的客户根本就无法说明白为什么慢，以及慢在哪里。
1.2.1 性能优化的范畴或优化对象确定
性能优化既然是改善工作，那我们首先必须知道现在在哪里，将来应该到哪里去，在改善之前这些因素必须要被确定下来。依然以电信受理业务为例，首先需要确定慢的范畴，范畴又可以分为两个层次：业务范围层和影响区域范围层。
业务范围层要确定的因素如下：
仅仅是开户受理慢，还是所有受理业务都慢？
仅仅是保存慢，还是所有步骤都慢？
仅仅是人工受理慢，还是所有受理都慢？
影响区域范围层要确定的因素如下：
是个别终端或个别区域慢，还是全局都慢？
是个别受理通道慢，还是所有的受理通道都慢？
通过这些因素最终确定业务性能优化的目标范畴，如表1-1所示。
1.2.2 性能优化目标的用户期望管理
作为一个性能优化者，必须知道“慢”是一个相对的概念，快或慢取决于期望值。笔者经常与同事介绍，作为一个开发人员或DBA，必须懂得用户的期望管理，并且应该清楚如何通过降低客户的期望来提高客户的满意度。依然以电信受理业务为例，假设其实际完成时间大约是2秒，我们请两个不同的人来描述这2秒里他们是如何管理期望值的。
第一个人对营业员说：电信受理业务非常复杂，中间要经过N个流程，每个流程都要花费一定的时间，我付出很大努力达到了业务逻辑优化，缩减了很大一部分不需要的流程，现在的性能预期良好，大约2秒钟左右可以完成受理。此时营业员脑海中就会出现一个画面，一个按钮下去，业务系统在跑N个流程，想想头都晕了。而这么多步骤2秒钟就完成了，开发商做得真到位。
轮到第二个人了，他对于自己的产品如此有信心，于是他信心满满地告诉营业员，不要担心性能问题，经过我们的优化，效果非常理想，速度很快。于是营业员满心期望着眼睛一眨结果就出来，可是等呀等，2秒钟才做完一笔受理业务。于是纷纷抱怨速度太慢，不可操作，需要进行优化。
除了快慢的期望相对性以外，不同人员的操作频率也会对快慢的期望产生重大影响，对于操作较少的业务往往可以忍受比较慢的速度，而对于频繁操作的业务则很难忍受较慢的
速度。
1.2.3 性能优化的目标衡量
对于用户来说，优化目标很容易确定，回到原来的响应速度甚至比原来的响应速度更快即可。但对于性能优化者来说，这个描述是无法定性或定量衡量优化目标的。因此需要与客户沟通，进一步把这个目标分解细化，并且是要可测量的。
对于非交互式的批处理应用，优化目标相对容易确定，一般可以用每分钟处理业务量或每个业务单元所耗费的时间来进行衡量。比如电信实时计费系统，可以用每分钟处理多少条话单来衡量优化目标指标。大部分非交互式批处理系统都具有处理业务日志系统，所以可准确衡量每分钟处理业务量；对于少量不具备日志的批处理系统，则可以采用类似作业的处理响应时间来衡量；若有无法采用以上方式衡量的情况，也可以简单通过结果比较甚至业务特征比较来完成，比如简单统计话单数量或者简单统计insert into cdr_detail values ( )语句的执行次数，或者通过统计这些批处理会话的事务数量来完成。
对于局部终端的交互式应用，由于性能影响受众有限，直接的定性描述或实际衡量的响应是一种可以接受的简单优化目标衡量方式。
对于广泛受众影响的交互式应用，其性能表现往往与吞吐量的大小有关。可以采用定性和定量结合的方式来完成优化目标衡量，如下：
吞吐量的确定。用户一般难以理解吞吐量的概念，所以可以简单采用技术性指标来描述，比如采用事务数量或特征语句的执行次数来确定吞吐量。
响应时间。响应时间又可以从定性和定量两个方面来确定，包括与部分终端使用人员交流，获得感性的响应时间来进行定性的认知以及通过特征语句的每次执行时间来进行定量的描述。除了以最终业务响应性能评价作为优化目标之外，很多优化场景仅仅是降低资源的使用，比如降低CPU消耗和I/O消耗等，这种性能优化是纯技术性操作，简单采用技术指标确定即可。
表1-2～表1-5可以用来帮助大家针对不同的业务应用类型来衡量优化目标。