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 + ……
当处理次数发生明显变化时，意味着业务特征或访问特征发生了变化。对于任何性能优化DBA来说，这都是一个与性能相关的直接要素。而对于每次处理时间，从Oracle数据库的描述中可以看到，服务处理是由CPU来执行的，正常情况下应该保持稳定，一旦其发生明显变化，就意味着CPU无法提供足够的能力。
排队次数同处理次数一样代表着业务特征或访问特征，排队时间则表示访问能力。应该说，Oracle数据库系统的性能优化工作者是极其幸运的，响应时间的分解几乎都可以直接或间接通过测量获得，这就使得Oracle数据库系统成为一个优化就绪的数据库系统。Oracle数据库不仅具有大量的状态型指标，还具有丰富的输入和输出指标。Oracle数据库不仅关系自身的零部件是否运行正常，而且关心业务操作和流程运行是否正常，也正因为如此，它使得所有这些东西都可以被直接或者间接测量。
在笔者看来，也许只有Oracle数据库才是性能优化就绪的数据库。
1.5.2 变化检测和性能优化
1.4节中有介绍，除了从来未达到性能期望的业务系统的优化工作未涉及变化以外，其他都会涉及变化。可以这么说，没有无缘无故的性能问题，任何性能问题都是由变化引起的，包括业务量的变化、访问量的变化、并发量的变化、数据量的变化、数据结构的变化、代码的变化等，任何交易都是建立在一定的上下文环境中的，当上下文环境发生变化的时候，其交易性能必然也发生变化。相信大部分人都明白，虽然知道性能问题是由于变化引起的，但关键是我们不知道哪些发生了变化，不能在性能出现问题的时候大声地质问：导致性能变异的变化给我站出来。大家知道，即使在现实生活中，某个人做了一些事情导致了严重的事件发生，他在多数情况下也会躲起来，甚至会故意混淆视听，告诉你是某某人做的，这也是我们这个世界需要警察的原因之一。
性能异常是由于某种或多种变化引起的，这个观点再怎么强调都不过分，甚至可以说本书就是围绕这个观点展开的。一旦确定了这个观点，性能优化的工作难度将大幅度下降，我们的任务也就变成了确定影响性能的因子。当性能异常的时候，只要检测这些性能因子的变化，就可以找到性能异常的原因，知道了原因就可以采取措施进行改善。幸运的是，Oracle数据库在这方面表现得如此出色，它提供了大量的性能检测因子，并且提供了不同时间度量的检测手段，使Oracle数据库的性能优化工作显得比较轻松。在后续的章节中，将陆续涉及这些性能检测因子，本书主要围绕这些性能检测因子来进行性能问题的诊断和优化。
1.5.3 量变和质变
在这个世界，只有变化是永恒的。在强调变化引起性能异常的观点时，我们也必须认识到，并不是任何变化都会引起性能异常，量变引起质变是一个朴素的变化观点，也完全适用于性能优化，只有变化积累到一定程度之后才会引起性能异常。
回头看看图1-1会发现，响应时间只有在达到一定的压力突变点之后才会发生变异。
任何人和设备、任何资源都有其处理能力的上限，当然也包括数据库，某些设备或某些资源还有一些突变点，当达到或即将达到处理能力的上限（或突变点）时，就会发生性能异常。
列举两个例子来看看个体的变化会引起什么样的局部变化，如下：
表格的数据增加，会使得全表扫描的响应时间随之线性增加。
索引的数据持续增加，使得唯一索引分类的层数增加，进而提高访问成本。比如从2层索引树增加为3层索引树，那么唯一索引访问的成本将增加50%，响应时间将增加50%。
再来看看个体变化给全局带来的影响，以表格数据增加10%的全表扫描为例。
变化之前业务访问时间为1s，可以接受的访问时间为2s，完全在服务质量保证范围之内。变化之后的业务访问时间为1 + 1×10% = 1.1s，仍然在服务质量保障范围之内。也就是从个体来说，完全没有问题，但是从全局来说，可能就会带来全局业务的性能急剧恶化。假设在变化之前有4个相同业务在部分时间会交叠执行，大致会消耗大约400Mb/s的I/O吞吐量带宽，基本使I/O子系统处于临界状态。当每个业务的访问时间从1s延迟到1.1s时，就有可能会导致5个甚至6个相同的业务在部分时段交叠执行，而这又会导致超过I/O子系统的服务能力，从而使其响应时间大幅度增加。这时，业务访问最终得到的也许并不是可以接受的1.1s，而是完全不可接受的5s甚至10s的响应时间。