对数据库系统而言，SQL语句的性能是每一个开发和运维DBA格外关注的细节点。前端应用性能中有很大部分是依赖数据库SQL，特别是Query的执行效率。所以，对于数据库调优而言，很大的功夫就在于进行SQL的调优。

SQL语句的执行是依赖优化器生成的执行计划。执行计划SQL Plan是真正获取到结果集合的步骤方法。为SQL生成一个更“好”的执行计划，是所有DBMS优化器的重要职责。

1、Oracle中的CBO和统计量困局

Oracle优化器Optimizer经过RBO到CBO时代的转化，应该说是向着智能化和灵活化实现了飞跃。从简单的规则序列生成执行计划，转而参考数据对象的统计信息。CBO通过统计信息来进行执行计划生成，依据成本cost对比来确定最优的执行计划。

伴随周期性的统计量收集，CBO的工作似乎无懈可击。但是，很多时候，即使在CBO时代，SQL的执行计划还是存在性能问题。注意，我们这里并不涉及CBO本身算法的缺陷。

最直接的症状，我们经常可以听到这样的抱怨：原本一条SQL或者SP一直或者大部分时间运行良好，但是“时不时”速度变慢。联系DBA进行Tuning后，常常是重新收集一次统计量（增加直方图或者提高采样率），SQL执行恢复正常。之后，在某一个时间点，问题照旧。

出现这种问题的根本原因在于：元数据中统计量信息同实际数据表的差异导致了错误执行计划的生成。导致不一致的原因很多，比如统计量收集（自动）时间点不合适、大批量数据操作后没有及时收集或者统计量异常。

简单的说，就是CBO对于统计量的变化过于“敏感”，而统计量收集又是和数据表数据不能做到完全同步。

对于周期性收集的统计量信息，SQL执行计划的偶然性蜕变似乎是不能解决的困局。因为我们不能做到每次执行SQL前都收集统计量。所以，我们需要做的就是避免异常SQL执行计划的生成，对执行计划生成进行控制。

从一些文献看，Oracle对于统计量收集频度问题是比较矛盾的。一种推荐的做法是设置假设，认为在一个时间段内，正常数据表的数据列分布是稳定的，不会有大的变化。在一次稳定的统计量收集之后，就将统计量固定“Freeze”住。这样就不会有一场SQL执行计划的生成。

另一种做法，是借助SQL BaseLine，保存一份“健康”时刻的关键SQL执行计划，作为一个留存。当出现紧急的SQL性能问题时，现将保存的执行计划baseline替换上去，支持系统运行。之后再分析出现问题的原因。

SQL执行计划异常的常见场景还包括系统升级。不同版本的Oracle优化器，特别是CBO的变化很大，一个在旧版本中工作良好的SQL可能新版本中生成一个很有问题的执行计划。所以，一些系统的移植升级过程中，现有执行计划的保留移植也是重要的考虑因素之一。

在11g中，Oracle开始尝试解决这种问题。11g推出了专门针对执行计划管理的组件内容SPM（SQL Plan Management）。在Baseline技术基础上提供了执行计划自动、手动优化进化的功能。

SQL> select * from v$version;

BANNER

--------------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

PL/SQL Release 11.2.0.1.0 - Production

CORE     11.2.0.1.0       Production

TNS for Linux: Version 11.2.0.1.0 - Production

NLSRTL Version 11.2.0.1.0 - Production

SQL> select parameter ,value from v$option where parameter like '%SQL%';

PARAMETER                      VALUE

------------------------------ ----------

SQL Plan Management            TRUE

2、SPM执行计划“三部曲”

我们说，SQL执行计划是和统计量紧密相关，偶然性的统计量错误或者不完全是造成执行计划Degrade的本质原因。SPM（SQL Plan Mangement）期望实现的在执行运行时能够保证SQL性能不会存在退化的情况，而且可以保证不断的推进执行计划性能。

简单的说：SPM保证只有那些被接受“Accepted”的可信执行计划才会被使用到，其他生成的执行计划都需要进行确认验证“Verified”。只有那些之后验证性能优化好的执行计划才会最终被接受为执行。

SPM主要包括三个关键组件，分别扮演不同的角色：

ü        SQL执行Baseline捕获

对所有相关的SQL，都生成专门的SQL Baseline，保存在数据库中。注意，Baseline是占用SYSAUX表空间的。

ü        SQL Baseline选择

在系统的运行时，Oracle要保证每次执行SQL的执行计划都是使用SQL Baseline中的确定执行计划。同时，跟踪所有该statement执行中使用的新执行计划，作为Plan Histroy信息保存下来。

Plan Histroy是有不同的状态的。执行计划中包括的状态有“Accepted”和“Unaccepted”两种。非接受的状态SQL可能是由于收集捕获之后没有进行验证“Unvertified”或者被拒绝“Rejected”。

ü        SQL执行计划Baseline进化

将Plan History中的未验证“Unvertified”状态的执行计划进行判断，判断为“Accepted”或者“Rejected”。

从上面的介绍看，SPM本质上就是进行执行计划不断进化upgrade的工具组件。从Oracle 10g开始，自动化和智能化就开始渗透到Oracle各个体系环节。自适应组件的频频推出，将过去一些难以确定、经验密集型的问题转为到Oracle自己解决。SPM就是Oracle在执行计划管理上的一个推进阶段。

下面，我们分别介绍三个组件的使用和功能。