1. 执行计划管理的工作原理
1.1控制执行计划的稳定性
- 11g之前，可以使用存储大纲（stored outline）和SQL Profile来固定某条SQL语句的执行计划，防止由于执行计划发生变化而导致的性能下降.
- 11g开始，oracle引入了SQL执行计划管理，从而可以让系统自动的来控制SQL语句执行计划的稳定性，进而防止由于执行计划发生变化而导致的性能下降
1.2 11g执行计划管理
- 优化器会为所有执行次数超过一次的SQL语句维护该SQL语句的每个执行计划的历史列表（plan history）。
- 优化器通过维护一个语句执行的日志条目（statement log）来识别该SQL语句是否为第二次执行。一旦优化器认出某条SQL语句为第二次执行，则优化器将该语句所生成的所有不同的执行计划插入到plan history的相关表里。
- 准线（plan baseline）是plan history的一个子集，plan baseline里面的执行计划是用来比较性能好坏的一个依据。
凭什么来判断是否可以使用一个新产生的执行计划呢？就是把该新的执行计划与plan baseline里的计划进行比较来判断。 某个SQL语句的执行计划可以属于plan history，但是不一定属于plan baseline。
2.有两种方法可以将SQL语句的执行计划纳入到执行计划管理体系中去
2.1 OPTIMIZER_CAPTURE_PLAN_BASELINES
OPTIMIZER_CAPTURE_PLAN_BASELINES=true，则会自动的捕获SQL的执行计划，但该参数缺省为false。
当某条SQL语句第一次执行时，该SQL语句的plan history是空的，显然该SQL语句的plan baseline也是空的。 那么当该SQL第二次再次执行时，优化器会自动将该SQL语句以及相关的执行计划放入plan history，同时也会放入到plan baseline里。
当你做了某些修改（比如添加了一个索引等），然后第三次执行该同样的SQL语句，则会产生另外一个不同的执行计划。这时新的执行计划会自动进入plan history，但是不会自动进入plan baseline。 是否使用该新的执行计划，则要把该新的执行计划与plan baseline里现存的第二次执行SQL时的执行计划进行比较， 如果新的执行计划成本更低，则会使用新的执行计划，否则使用plan baseline里的执行计划。
2.2 DBMS_SPM
使用该包，可以直接将SQL的执行计划从shared pool里加载到plan baseline里，也可以使用dbms_spm包将已经存在的SQL Tuning Set加载到plan baseline里。
同时，dbms_spm可以让你把plan history里的执行计划加入到plan baseline里。反之，也可以使用该包将plan baseline里的执行计划移出去。
注意，某条SQL语句的plan baseline里的第一个执行计划可以像上面说的通过设置初始化参数来自动加入，但是如果你希望在plan baseline里添加该SQL语句的其他新的执行计划时，则必须使用dbms_spm包手动完成。
3.plan baseline里的执行计划是如何被使用的
OPTIMIZER_USE_PLAN_BASELINES参数缺省为true，表示要求优化器考虑使用plan baseline里的执行计划，如果设置为false，则不使用执行计划管理的特性，而又回到了11g之前的状况。
场景：以下描述基于的前提是plan baseline里已经存在了一个SQL的执行计划.
每次优化器解析SQL语句的时候，首先仍然使用11g之前的传统方式产生一个成本最低的执行计划，然后看初始化参数：OPTIMIZER_USE_PLAN_BASELINES.
- 如果为false，则直接返回所生成的执行计划。
- 如果为ture， 则去plan history里找是否存在相同的执行计划：
-
- 如果找到了，则去plan baseline里找相同sql的执行计划做对比，看哪个执行计划的成本低就取哪个执行计划
- 如果没找到，则将产生的执行计划加入到plan history里，然后将执行计划与plan baseline里已经存在的执行计划进行比较，看哪个执行计划的成本低就取哪个执行计划。
整理自网络：http://tech.it168.com/db/2007-07-23/200707231104640.shtml