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日的基线比较中反馈出业务系统的变化，从而使业务系统的性能监视失去最佳干预点。
表1-6 基线更新情况
假设采用动态基线管理，也许更好的方式为不管是否具有当前的更新基线，总是与滑动窗口对应的基线比较，或者总是延后生成动态基线，也会更加有利于性能数据的测量和监视。
2. 多版本基线之间的比较
随着时间的推移，会不断建立新的基线，这些不同版本的基线对于用户把握业务系统的运行发展具有重要意义。我们在回顾过去一段时间业务系统运行的状态时，基线之间的数据比较是最为便捷也是最具有价值的内容。
3. 基线数据的内容
从基线数据的性质来看，所有可测量的数据都可以成为基线数据。当然，为了让基线更加容易管理，需要对基线指标进行分类和分组，从而更好地支持业务性能监视和业务系统性能优化。
可从吞吐量和响应时间的关系曲线（见图1-1）来构建Oracle业务性能的可测量体系，并在这个基础上建立可比较的运行基线。本书的主要目的就是在于建立体系化的Oracle业务性能可测量体系，从而支撑Oracle业务系统性能优化方法论：基于流程、资源和组件分析的性能优化。
在建立了完整的可测量Oracle业务系统指标体系、为可测量的指标建立了基线数据库、确立了基于变化的性能优化诊断理论后，性能优化诊断操作就成为水到渠成的事情，而通过可测量指标的相关性分析就可以轻松地对性能进行改善，从而完成性能优化工作。
下面采用最简单的模型公式来进行基于变化的性能优化实践，公式如下：
下面来看表1-7中的两组数据，查看导致性能异常的原因在哪里。
表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子系统的组成链路等。
这时还可以进一步检测磁盘系统的基线：
从iops和2ms响应时间可以确定，当前20ms的响应时间是由I/O子系统故障引起的，可以寻求存储厂商的介入以最终解决在存储软硬件层面的问题。
在笔者团队的性能优化实践中，类似于上面的案例几乎每年都会发生好几起。各位读者可以想象一下，如果缺乏基线数据，可能就会有相当多的优化工作者（你是如何处理的呢？）通过调整SQL语句来降低I/O数量，从而达成本次优化，性能优化工作最终会大部分完全失败或部分失败。