为了解决上述问题，Oracle在11g中推出了SPM(SQL Plan Management)。SPM是一种主动的稳定执行计划的手段，能够保证只有被验证过的执行计划才会被启用，当由于种种原因(如统计信息的变更)而导致目标SQL产生了新的执行计划后，这个新的执行计划并不会被马上启用，直到它已经被我们验证过其执行效率会比原先执行计划高才会被启用。

随着Oracle数据库版本的不段推进，其CBO的算法、功能也在一直不断进化和增加，所以同样的SQL有可能在新版本的Oralce数据库中执行效率更高，如果我们使用了SQL Profile(特别是使用了Manual类型的SQL Profile)来稳定目标SQL的执行计划，那就意味着可能失去了继续优化上述SQL的执行效率的机会。而SPM的推出可以说彻底解决了执行计划稳定性的问题，它既能主动地稳定执行计划，又保留了继续使用新的执行效率可能更高的执行计划的机会。

当启用了SPM后，每一个SQL都会存在对应的SQL Plan Baseline，这个SQL Plan Baseline里存储的就是该SQL的执行计划，如果一个SQL有多个执行计划，那么该SQL就可能会有多个SQL Plan Baseline，可以从DBA_SQL_PLAN_BASELINES中查看目标SQL所有的SQL Plan Baseline。

DBA_SQL_PLAN_BASELINES中的列ENABLED和ACCEPTED用来描述一个SQL Plan Baseline所对应的执行计划是否能被Oracle启用，只有ENABLED和ACCEPTED的值均为“YES”的SQL Plan Baseline所对应的执行计划才会被Oracle启用，如果一具SQL有超过1个以上的SQL Plan Baseline的ENABLED和ACCEPTED的值均为YES，则Oracle会从中选择成本值最小的一个所对应的执行坟墓来作为该SQL的执行计划。

在Oracle 11g及其以上的版本中，有如下两种方法可以产生目标SQL的SQL Plan Baseline。

下面分别介绍如何自动捕获和手工的方式来产生SQL Plan Baseline。

1 自动捕获SQL Plan Baseline

参数OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES用于控制是否开启自动捕获SQL Plan Baseline，其默认值为FALSE，表示在默认情况下，Oracle并不会自动捕获SQL Plan Baseline。这个参数可以在session或系统级别动态修改。当修改为TRUE后，则Oracle会对上述参数影响范围内所有重复执行的SQL自动捕获其SQL Plan Baseline，并且针对目标SQL第一次捕获的SQL Plan Baseline的ENABLED和ACCEPTED的值均为“YES”。随后如果该SQL的执行计划发生了变更，则再次捕获到的SQL Plan Baseline的ENABLED的值依然为YES，但ACCEPTED的值变为了NO，这表示后续变更的执行计划虽然被捕获了，但Oracle不会将其作为该SQL的执行计划来执行，即此时Oracle会永远沿用该SQL第一次被捕获的SQL Plan Baseline所对应的执行计划(除非后续做了手工调整)。

参数OPTIMIZER_USE_SQL_PLAN_BASELINES用于控制是否启用SQL Plan Baseline，其默认值为TRUE，表示在默认情况下，Oracle在生成执行计划时就会启用SPM，使用已有的SQL Plan Baseline，这个参数也可以在session或系统级别动态修改。

下面看一下实例：

查看上述两个参数的默认值

在当前session中禁掉SPM并同时开启自动捕获SQL Plan Baseline：

创建测试表T2

从执行计划上看，走的是索引IDX_T2上的索引范围扫描，因为SQL只执行了一次，所以Oracle不会自动捕获SQL Plan Baseline，DBA_SQL_PLAN_BASELINES中没有记录

再次执行上述SQL，因为重复执行该SQL，Oracle自动捕获了这个SQL的SQL Plan Baseline?

从执行计划中可以看出该SQL的执行计划已经变为全表扫描。因为目标SQL已经重复执行且同时又产生了一个新的执行计划，所以现在Oracle就会自动捕获并创建这个新的执行计划所对应的SQL Plan Baseline了。从如下查询可以看出Oracle对新的执行计划产生了一个新的SQL Plan Baseline，其ENABLED的值依然为YES，但ACCEPTED的值变为了NO：

从上面的显示内容可以看出，现在目标SQL的执行又从全表扫描恢复为了索引范围扫描，并且执行计划中的Note部分有“SQL plan baseline SQL_PLAN_asnmb3t5yfk4024c6dbb6 used for this statement”内容，说明SPM开启的情况下，即便目标SQL产生了新的执行计划，Oracle依然只会应用该SQL的ENABLED和ACCEPTED的值均为YES的SQL Plan Baselline。

如果想启用目标SQL新的执行计划(即全表扫描)，应该如何做呢？

针对不同的Oracle版本，会有不同的处理方法。比如这里想启用目标SQL的新的执行计划，如果是11gR1的环境，则只需要将目标SQL所采用的名为SQL_PLAN_asnmb3t5yfk4024c6dbb6的SQL Plan Baseline(即索引范围扫描)的ACCEPTED的值设为NO就可以了。但对于11gR2环境，上述方法会报错，因为在11gR2中，所有已经被ACCEPTED的SQL Plan Baseline的ACCEPTED的值将不再能够被设为NO：

在11gR2中，我们可以联合使用DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE和DBMS_SPM.ALTER_SQL_PLAN_BASELINE达到启用目标SQL新的执行计划的目的。

先用DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE将新的执行计划(全表扫描)所对应的SQL Plan Baseline的ACCEPTED值设为“YES”：

从上面显示的内容看到如下信息：“Plan: SQL_PLAN_asnmb3t5yfk40b860bcf2----Plan was changed to an accepted plan.”，这表明已经将新的执行计划(全表扫描)所对应的SQL Plan Baseline的ACCEPTED值设为YES

从下面的查询结果也可以证明：

然后再使用DBMS_SPM.ALTER_SQL_PLAN_BASELINE将原先的执行计划(索引范围扫描)对应的SQL Plan Baseline的ENABLED的值设为NO：

再次执行目标SQL

从上述显示可以看出，现在SQL的执行计划已经变为了全表扫描，我们要启用新的执行计划(全表扫描)的目的已经实现，Note部分也有了提示。

从上述测试结果可以看出，实际上我们可以轻易地在目标SQL的多个执行计划中切换，所以SPM确实是既能够主动地稳定执行计划，又保留了继续使用新的执行计划的机会，并且我们很容易就能启用新的执行计划。

下面介绍手工生成SQL Plan Baseline：