本节书摘来自华章计算机《Oracle数据库性能优化方法论和最佳实践》一书中的第1章，第1.6节，作者：柳遵梁 潘敏君 应以峰著，更多章节内容可以访问云栖社区“华章计算机”公众号查看
1.6 基线管理
1.6.1 基准点和基线
人们在谈论Oracle业务系统的性能时通常会说它运行得快或慢，但大家都知道快和慢没有一个绝对的标准，所有的快或慢都是基于比较而言的。比如我们在操场上15s跑完100m，没有人会觉得你跑得快，因为大家都有一个比较的基准，大部分人都可以在12～15s跑完。同样是100m，如果你是上楼梯，那大家可能会觉得你的速度太惊人了。所以，快慢好坏都是基于比较而言的，没有比较就没有性能的好和坏。因此，为了使性能优化工作更加科学，需要建立量化的性能基准点，而不能依赖于经验来建立，毕竟经验很难放之四海而皆准，每次衡量快或者慢的时候都可以与这个基准点进行比较，这个基准点即为基线。在Oracle数据库中，同样需要建立基准点或者基线，用来描述Oracle业务系统在某个特定的状态下，特定的输入响应和输出响应以及相应提供服务的各个资源和组件状况。当后续的业务运营和基线产生预料之外的偏离时，则表示业务系统发生了变化，不管是否会产生业务系统性能问题，都需要运维人员介入。
业务运行的状态可能在不同的时间点表现出完全不同的业务特征，在不同的业务特征之间进行比较是没有任何意义的。这时应该建立多个基准点来完整地描述业务系统的运行特征。比如电信计费系统在白天和晚上、月底和月初都会表现出不同的特征，因此就需要对不同时间点都建立相应的基准点或基线。
下面通过一个简单的例子来说明基线之于性能优化的重要性。
某业务系统的性能最近变得很差，需要进行性能优化。性能优化专家发现一个明显的现象——CPU利用率达到100%，几乎没有空闲时间。依据经验，该专家认为这个100%的CPU利用率是属于一个坏指标，并且认为这是其根本原因。通过艰苦的优化工作，CPU利用率有所下降，但是性能并没有提高，可以想象，应该是专家找错了方向。事实上，这个系统自上线以来其CPU一直工作在100%状态下，且运行良好。在这种情况下，如果有了CPU的利用率基线，专家就不会犯这个错误，可以正确地把握方向。而且，如果进一步测量指标可以发现，虽然CPU利用率为100%，但是其服务能力没有任何问题，并且没有在CPU上形成大规模冲突导致其单次服务能力下降。
基线的存在可以大大减轻性能优化者的负担，基线的存在可以使性能优化不再是高手的专利，普通的性能优化工作者甚至是缺乏任何数据库知识的人都可以轻松地发现导致业务系统性能变差的原因：只要把每个可测量的指标值和该指标的基线值进行比较，出现大规模偏差的一般就是性能问题的根源所在。
1.6.2 沟通基线
除了完全量化的基线以外，为了更好地描述业务系统的运行和性能，最好另外再建立一个相对感性的基线，即沟通基线。利用这个沟通基线与业务人员进行友好的沟通，可以更好地把握未来业务系统问题的实质。
感性沟通基线以吞吐量和响应时间为基础对目标系统进行业务性能上的描述。沟通基线最重要的目的是确定业务的变化，相当多的性能问题是由于业务变化及其他各种相关的变化引起的。沟通基线可以从三个方面进行描述：性能感受、运行用户、运行业务。
比如下面是一个沟通基线的简单描述。
性能感受：基本不会出现“客户在等、我也在等”的情况，1～2s响应，大部分情况下应该在1s左右，个别时候会有2s，因其偶尔出现，所以在可接受范围内。存盘时会产生打印凭单，由于凭单打印机的速度通常是比较慢的，所以对打印的快慢不会有太大的感觉。为了加快业务办理速度，往往是那边在打印凭单，这里就开始接受新的业务。存盘慢不要紧，但不能影响新工作的开始。
运行用户：早上8:00到位，8:15左右正式工作，有4500～5000个人在做同样的工作。若无特殊情况，一旦开始工作就要到中午吃饭才会退出系统，下午13:00又开始工作，17:30开始陆续下班，依据忙碌程度会延迟到20:00，但一般20:00之后就不会再做事情。
运行业务：主要是办理受理、变更、缴费等业务，都是面向客户交互的。
1.6.3 基线管理和动态基线
1.?基线更新和动态基线管理
随着时间的推移，业务系统会不断发生变化，甚至硬件系统资源也会发生变化，这时基线必须同样随之发生变化，否则就无法表述当前业务的运行状态，从而使性能优化走向歧途。任何一个Oracle业务系统性能优化体系，都应该具有通过很简单的方式来进行多基线管理和当前基线确定的能力。
同样，随着时间的推移，我们对性能优化的认知也在不断提高，可能需要增加新的基线指标来更好地管理性能，作为基线管理，自然也需要支持可以简单增加指标到基线指标管理数据库中。
为了降低基线更新成本，可以采用动态基线，也就是让运维管理系统自动建立基线。作为一个描述业务系统正常运行的基线数据，其重大的挑战是必须可以自动判断业务系统是否处在正常的运行范畴之内。不仅如此，当采用动态基线的时候，如果总是与最新创建的基线做比较，可能会出现温水煮青蛙的情况，从而使性能监视系统失去作用。动态基线最好采用滑动窗口的形式来管理。
假设表1-6给出了基线更新情况，3月4日建立了基线Ⅰ，3月11日建立了基线Ⅱ。若基线是采用静态基线确立的，则3月12日的基线比较会建立在3月11日的基线基础上，因为这个基线是运维管理人员确认的业务特征基线。但是，当3月11日的基线是由系统动态创建的，那可能会存在一定问题，此时若3月12日的业务系统仍以3月11日的作为比较对象，而大部分系统的业务是随着时间逐步增加的，这样一来，3月12日可能无法从与3月11日的基线比较中反馈出业务系统的变化，从而使业务系统的性能监视失去最佳干预点。
假设采用动态基线管理，也许更好的方式为不管是否具有当前的更新基线，总是与滑动窗口对应的基线比较，或者总是延后生成动态基线，也会更加有利于性能数据的测量和
监视。
2.?多版本基线之间的比较
随着时间的推移，会不断建立新的基线，这些不同版本的基线对于用户把握业务系统的运行发展具有重要意义。我们在回顾过去一段时间业务系统运行的状态时，基线之间的数据比较是最为便捷也是最具有价值的内容。
3.?基线数据的内容
从基线数据的性质来看，所有可测量的数据都可以成为基线数据。当然，为了让基线更加容易管理，需要对基线指标进行分类和分组，从而更好地支持业务性能监视和业务系统性能优化。
可从吞吐量和响应时间的关系曲线（见图1-1）来构建Oracle业务性能的可测量体系，并在这个基础上建立可比较的运行基线。本书的主要目的就是在于建立体系化的Oracle业务性能可测量体系，从而支撑Oracle业务系统性能优化方法论：基于流程、资源和组件分析的性能优化。
在建立了完整的可测量Oracle业务系统指标体系、为可测量的指标建立了基线数据库、确立了基于变化的性能优化诊断理论后，性能优化诊断操作就成为水到渠成的事情，而通过可测量指标的相关性分析就可以轻松地对性能进行改善，从而完成性能优化工作。
下面采用最简单的模型公式来进行基于变化的性能优化实践，公式如下：
吞吐量=（60/响应时间）×并发session数量
响应时间= 服务处理时间 + 服务排队（等待）时间
服务处理时间= 单元服务次数×单元服务时间
服务等待时间= 单元服务次数×单元服务等待时间
= I/O等待次数× I/O等待时间 + 并发性等待次数×并发性等待时间
+ 其他等待次数×其他等待时间
下面来看表1-7中的两组数据，查看导致性能异常的原因在哪里。
通过对以上可测量指标进行简单的比较可以发现：响应时间增加了，并发数增加了，吞吐量下降了。进一步比较可以发现，响应时间增加的主要原因为单元服务等待时间从220ms增加到了1516ms，变化幅度比较大，单元服务时间从410ms增加到了505ms，略有增加。而单元服务等待时间的增加主要是由单元I/O等待时间的变化引起的，它从2ms增加到了20ms。通过与基线指标数据的变化进行比较可以很简单地做出诊断：I/O子系统出现问题导致响应时间增加，如果了解I/O子系统的相关知识，那么可以知道，20ms的响应时间只有两种可能性：
I/O严重堵塞。
I/O子系统出现故障类事件（配置或其他）。
从I/O发生的次数可以知道，严重堵塞的可能性不大（并非绝对没有，比如数据库外的很多负载可能导致堵塞），因此优化调整的方向就可定为I/O子系统故障，进而检查其配置和状态，检查其I/O子系统的组成链路等。
这时还可以进一步检测磁盘系统的基线：
磁盘利用率= 98%
iops = 3600
服务响应时间= 2ms
从iops和2ms响应时间可以确定，当前20ms的响应时间是由I/O子系统故障引起的，可以寻求存储厂商的介入以最终解决在存储软硬件层面的问题。
在笔者团队的性能优化实践中，类似于上面的案例几乎每年都会发生好几起。各位读者可以想象一下，如果缺乏基线数据，可能就会有相当多的优化工作者（你是如何处理的呢？）通过调整SQL语句来降低I/O数量，从而达成本次优化，性能优化工作最终会大部分完全失败或部分失败。
