摘要：Oracle数据库11gR1新的SQL计划管理工具给每个Oracle DBA都有能力捕获并保存最有效的SQL语句执行计划。本文—该系列文章的第二篇—解释在升级一个现存的Oracle10gR2数据库到Oracle11g时如何使用SQL计划管理，与部署新应用程序代码一样，有效地限制SQL语句性能异常回退。

　　本系列的前一篇提供了Oracle数据库11g新的SQL计划管理（SPM）特色的入门介绍，包括一些如何使用SPM工具帮助过滤执行计划以识别并隔离最佳的计划以提升SQL语句性能的简单例子。

　　因为我已经解释并说明了SQL计划管理的基本架构，现在我将注意力集中到讨论两种每个Oracle DBA都会遇到的情况：升级现有的Oracle数据库到一个更新的版本，部署新的应用程序代码到现有的数据库。前面的文章已经说明了如何使用Oracle11g的新DBMS_SPM包捕获新的SQL计划基线，我将利用这两种情况来说明Oracle11g企业管理器数据库控制的SQL计划控制规则来捕获新的SQL计划基线候选者，以及管理现有的SQL计划基线。

　　SPM情景#1：升级一个现有的数据库

　　在我看来，升级一个现有的数据库有新的版本即使对一个经验丰富的Oracle DBA而言也是相当痛苦的事情，因为很难精确地判断升级后哪个语句性能降低了。在Oracle11g之前的环境中，我已经找到了限制这个不确定性最好的方法，就是在我的QA服务器上构造一个与生产环境完全一致的副本，捕获充足的应用程序最关键的SQL语句工作负载，并捕获这些语句的执行计划。一旦我启动升级开关升级QA数据库和环境到新的数据库版本，我要为这些语句重新生成执行计划并比较结果以发现性能倒退的语句。

　　通过这种野兽般的测试方法我得以相当顺利的从旧版本升级到Oracle11g，我也希望有更可靠的方法精确地判断升级对现有SQL语句性能的影响，我已经在早先的关于SQL性能分析器的文章中论述过了，因此现在隔离任何性能倒退的SQL语句非常简单，甚至对内部相对较小的升级也很简单（如从11.1.0.5.0升级到11.1.0.6.0）。一旦使用SQL性能分析器识别出所有性能倒退的SQL语句，在我执行升级操作之前，我将拿起SQL计划管理的强大工具捕获那些语句到SQL调整集（STS）中。

　　从STS捕获语句的SQL文本、绑定变量、执行计划和执行统计后，我将保留它们直到数据库版本升级完毕，到那时我将转换这些语句执行计划成为SQL计划基线，当这些语句对于升级后的数据库第一次执行时，无论如何，基于成本的优化器（CBO）都将检测SQL计划基线是否仍然可用，如果CBO判断SQL计划基线提供了一个更有效的执行计划，它将用该基线计划替换原有的计划，最终结果是一个可能很严重的SQL计划倒退是可以完全避免的。

　　收集SQL工作负载

　　要说明这个概念，我将首先在Oracle10gR2上创建一个SQL工作负载。我将在销售历史方案（SH）的多个表中使用5个查询，查询SQL（SPM_2_1.SQL），用来模拟一个在数据仓库应用程序中的SQL工作负载，在我开始工作负载前，我将初始化列表2.1中的代码，它使用DBMS_SQLTUNE.CAPTURE_CURSOR_CACHE_SQLSET来捕获工作负载的SQL语句到一个名叫STS_SPM_200的SQL调整集中。

　　打包并导出SQL调整集
　　
　　一旦我将SQL工作负载捕获到一个SQL调整集中，我准备将它转移到Oracle11gR1数据库中，列表2.2展示了如何做：

　　◆创建中间表作为SQL调整集STS_SPM_200的容器
　　◆通过存储过程DBMS_SQLTUNE.PACK_STGTAB_SQLSET转移SQL调整集到中间表
　　◆通过数据泵导出工具导出中间表数据到一个名叫DumpStagingTable.dmp的导出文件

　　转移SQL调整集

　　在我拷贝了数据泵导出文件到我的Oracle11g数据库的默认数据泵目录后，我将使用Oracle数据泵导入工具和适当的参数导入中间表到目标Oracle11gR1数据库，然后，我会使用存储过程DBMS_SQLTUNE.UNPACK_STGTAB_SQLSET打开存储在中间表中的SQL工作负载。列表2.3展示了转移过程的详细情况。