【IT168技术文档】摘要：本文描述了11g的新特性之一：执行计划管理，介绍了引入该新特性的原因，以及该新特性的相关特点、工作原理等。最后通过引入一个测试案例来介绍如何使用该新特性。

1. 执行计划管理的工作原理

    我们知道，SQL语句的性能很大程度上依赖于SQL语句的执行计划。如果SQL语句的执行计划发生改变，则SQL的性能很有可能发生大的变化。而SQL执行计划发生变化的原因有很多种，包括优化器版本的变化、统计信息的变化、优化器相关的各种参数的变化、添加或删除了索引、添加或删除了物化视图、修改了系统设置、以及是否应用了10g引入的SQL profile等。

    在11g之前，我们可以使用存储大纲（stored outline）和SQL Profile来帮助我们固定某条SQL语句的执行计划，防止由于执行计划发生变化而导致的性能下降。不过这些技术需要DBA人为的处理，比如存储大纲，需要DBA手工创建，而SQL Profile来说，则要DBA手工应用才能生效。

    从11g开始，oracle引入了SQL执行计划管理（SQL Plan Management）这个新特性，从而可以让系统自动的来控制SQL语句执行计划的稳定性，进而防止由于执行计划发生变化而导致的性能下降。

    通过启用该特性，某条语句如果产生了一个新的执行计划，只有在它的性能比原来的执行计划好的情况下，才会被使用。

为了实现执行计划管理，优化器会为所有执行次数超过一次的SQL语句维护该SQL语句的每个执行计划的历史列表（plan history）。优化器通过维护一个语句执行的日志条目（statement log）来识别该SQL语句是否为第二次执行。一旦优化器认出某条SQL语句为第二次执行，则优化器将该语句所生成的所有不同的执行计划插入到plan history的相关表里，而plan history里包含了优化器能够用于重新生成执行计划的所有信息，这些信息包括SQL文本、存储大纲、绑定变量以及解析环境（比如optimizer_mode之类影响优化器解析SQL语句的参数）等。

    当然，11g也支持手工维护SQL语句的plan history，作为对自动维护plan history的功能补充。

但是并不是说plan history里任何的执行计划都可以拿来使用。这里需要先介绍一下所谓的执行计划基准线（plan baseline）这个概念。plan baseline是plan history的一个子集，plan baseline里面的执行计划是用来比较性能好坏的一个依据。也就是说，凭什么来判断是否可以使用一个新产生的执行计划呢？就是把该新的执行计划与plan baseline里的计划进行比较来判断。某个SQL语句的执行计划可以属于plan history，但是不一定属于plan baseline。

注意：每个SQL语句都会有它自己的执行计划历史以及执行计划基准线。