要让Oracle性能优化从艺术变成科学，首先必须建立目标系统性能指标的可以测量。一个无法测量的系统或者说一个只能依赖于人的眼睛，耳朵等器官来进行感知的系统是无法进行性能优化的，这个时候就只能依赖于直觉，性能优化就变成了艺术或者所谓的超能力了。
      为了完成性能优化，我们需要完成大量的可测量性工作。幸运的是，Oracle对于可测量的性能一直付出了艰辛的努力，使其性能相关的测量指标远远的超出了其他数据库。
      可测量的性能优化目标：吞吐量和响应时间。
      我们可以从以下几个方面来建立基于Oracle的测量体系：
     （1）、基于终极目标性能的测量
     （2）、基于Oracle构成部件运行是否良好的测量
     （3）、基于物理资源供应运行是否良好的测量
     （4）、基于并发性资源运行是否良好的测量
     （5）、基于流程分解的响应时间的测量
     
      从另一个角度考虑，我们建立起终极目标性能指标：吞吐量和响应时间的因果分析测量体系和相关性分析测量体系。基于因果关系确认的艰难性，我们更多的基于相关性进行分析测量。
     我们来看下面的简单例子：
     我们这里从简单业务出发来考虑问题，比如全部业务为tpcc测试的订单业务。

    吞吐量： 每分钟完成的订单数。

    吞吐量：= ( 60/每个订单处理的响应时间 ) * 并行的处理会话
   
    可以认为以下两个结论是正确的： 在并行处理会话确定的前提下，降低每个订单处理的响应时间可以提高吞吐量。
                                                                 在每个订单处理的响应时间确定的情况，增加并行的处理会话可以提高吞吐量。
    具有足够经验的DBA都知道，上面的结论完全是理论推导，在实际的环境中，所谓的吞吐量下降的场景，每个订单处理的响应时间延长，几乎总是可以观察并行的处理会话数量增加。我们甚至可以如此认为，在业务量变化不大的前提下，并行的处理会话增加几乎必然意味着吞吐量的下跌，每个订单处理的响应时间延长导致并行的处理会话增加。
    从以上分析，我们可以具有以下结论，在业务变化不大的前提下：
    订单处理的响应时间延长导致吞吐量的下跌。
    订单处理的响应时间延长导致并行的处理会话增加。
    并行的处理会话增加和吞吐量降低具有相关关系。
  
    我们为什么需要这样来描述？原因很简单，每个订单处理的响应时间是相对难以被测量的指标，而并行的处理会话极其容易被测量。
   
    订单的响应处理时间：=  订单的处理时间  + 订单的等待时间
    订单的处理时间和订单的等待时间，Oracle都在系统级别做出了很好的测量。我们再次来看吞吐量曲线：
         
 


    假设吞吐量曲线图中蓝点和黄点是响应时间和吞吐量的最佳平衡点，在这个平衡点具有服务时间和排队时间。当我们测量的排队时间超过这里的排队时间，以为着响应时间出现问题。
   
    订单的处理时间：=  处理次数 * 每次处理时间+处理次数*每次处理时间+.....
    订单的排队时间：= 排队次数*每次排队时间 + 排队次数*每次排队时间+.....

    这里可以注意一下：当处理次数发生明显变化，意味着业务特征或者访问特征发生了变化。对于任何性能优化DBA来说，这都是一个性能的直接要素。每次处理时间，在Oracle数据库的描述，服务处理是由CPU来执行，正常情况下应该保持稳定，一旦其发生明显变化，意味着CPU无法提供足够的能力。
    排队次数同处理次数一样，排队次数同样表示着业务特征或者访问特征，排队时间表示访问能力。
    作为Oracle数据库系统的性能优化工作者极其幸运，响应时间的分解几乎都可以直接或者间接通过测量获得，从而使Oracle数据库系统完全是一个优化就绪的数据库系统。