1.5 测量和变化

1.5.1 测量和性能

没有测量就没有性能，任何科学都建立在可测量的基础之上。Oracle数据库和基于它的性能优化理所当然是一门科学，而不是一门艺术。科学的性能优化首先必须是可以建立测量的目标系统性能指标。一个无法测量的系统或者一个只能依赖于人的眼睛、耳朵等器官来进行感知的系统是无法进行性能优化的。为了完成性能优化，需要做大量的可测量性工作。幸运的是，Oracle对于可测量的性能付出了巨大的努力，使其性能相关的测量指标远远超出了其他数据库。

从性能优化的角度出发，可以从以下几方面来建立性能优化测量指标体系。

❑ 流程：指从发命令给数据库，到数据库返回我们需要的结果的整个业务处理流程。

❑ 资源：指在业务处理流程过程中需要使用的软硬件资源，比如CPU、内存等。

❑ 组件：在流程处理中涉及的处理单元，比如buffer cache等。

流程是业务用户可直接感受的性能指标，与人的感官感觉紧密相连，性能优化的根本目标就是使业务流程顺利运转。构建性能优化可测量体系的一个简便方法是从顶层目标出发，进行分解和推导，发现其测量因子之间的依赖性、相关性和影响性。在构建此体系的过程中，若把Oracle数据库及业务流程中涉及的所有组件和资源都作为一个设备或服务来看，则会有相当的便利，更具有真实性。

在业务流程中，当把资源和组件统一作为一个服务中心看待时，也可由此构造出统一的可测量指标体系，如下：

❑ 输入型指标；

❑ 输出型指标；

❑ 状态型指标。

通过上述测量指标一起作用构建出Oracle数据库的监控体系后，即可检测Oracle业务流程是否正常运转。除此之外，为了更快地完成性能优化，还应该力求在可测量指标之间建立关联，比如依赖性指标、相关性指标、影响性指标等。这样就可以通过指标相关性驱动最终发现真正导致性能变化的指标，并且采取措施纠正它。

再次查看吞吐量和响应时间的关系曲线，明显可以看到，响应时间是流程的输出结果，而吞吐量则是流程的输入元素。

下面来看一个简单的概念性示例。

假设系统业务为TPCC测试的订单业务，采用订单数量作为吞吐量输入指标。

吞吐量（输入型指标）=每分钟完成的订单数。

吞吐量（输入型指标）=（60/每个订单的响应时间）×并行处理会话

这里并不是在念绕口令，同一个指标采用不同的计算方式在性能优化分析中具有重大意义，它可以让你清晰地了解指标之间的关系，从而采取正确的优化方式。

根据上面变种的吞吐量公式，可以认为以下两个结论是正确的。

❑ 在并行处理会话确定的前提下，降低每个订单的响应时间可以提高吞吐量。

❑ 在每个订单的响应时间确定的情况下，增加并行处理会话可以提高吞吐量。

有足够经验的DBA都知道，上面的结论完全是理论推导。在实际的环境中，若遇到吞吐量下降的场景，且每个订单的响应时间延长，那么总是可以观察到并行会话的数量增加。甚至可以认为，在业务量变化不大的前提下，并行会话的增加必然意味着吞吐量的下降，而这正是订单的响应时间的延长导致并行处理会话增加而引起的。

在业务变化不大的前提下，从以上分析可以得出如下结论：

❑ 订单的响应时间延长会导致吞吐量下降。

❑ 订单的响应时间延长会导致并行处理会话增加。

❑ 并行处理会话的增加和吞吐量降低具有相关关系。

为什么要这样来描述？原因很简单，因为每个订单的响应时间是相对难以测量的指标，而并行处理会话极其容易被测量。

订单的响应时间=订单的处理时间+订单的等待时间

对于订单的处理时间和订单的等待时间，Oracle都在系统级别做出了很好的测量。

假设图1-8所示的曲线图中那两个圆点是响应时间和吞吐量的最佳平衡点，且在这个平衡点上有服务时间和排队时间，当具体的订单运行点落到平衡点的右边或者上边的时候就意味着出现了性能问题。每次订单处理都由一系列的众多过程组成，每次订单的处理时间和排队时间自然也由一系列众多过程的处理之和构成，可以用以下公式来表达：

订单的处理时间=处理次数1×每次处理时间1+处理次数2×每次处理时间2+……

订单的排队时间=排队次数1×每次排队时间1+排队次数2×每次排队时间2+……

在笔者看来，也许只有Oracle数据库才是性能优化就绪的数据库。