如何保持执行计划的稳定性

1. 规划好优化统计信息的收集策略。对于 Oracle 10g来说，默认的策略能够满足大部分需求，但是默认的收集策略会过多地收集列上的直方图。由于绑定变量与直方图固有的矛盾，为保持性能稳定，对使用绑定变量的列，不收集列上的直方图；对的确需要收集直方图的列，在SQL中该列上的条件就不要用绑定变量。统计信息收集策略，可以考虑对大部分表，使用系统默认的收集策略，而对于有问题的，可以用DBMS_STATS.LOCK_STATS锁定表的统计信息，避免系统自动收集该表的统计信息，然后编写脚本来定制地收集表的统计信息。脚本中类似如下：

1 exec dbms_stats.unlock_table_stats…

2 exec dbms_stats.gather_table_stats…

3 exec dbms_stats.lock_table_stats…

      2. 修改SQL语句，使用HINT，使SQL语句按HINT指定的执行计划进行执行。这需要修改应用，同时需要逐条 SQL 语句进行，加上测试和发布，时间较长，成本较高，风险也较大。

　　3. 修改隐含参数” _optim_peek_user_binds”为FALSE，修改这个参数可能会引起性能问题（这里讨论的是稳定性问题）。

　　4. 使用OUTLINE。对于曾经出现过执行计划突然变差的SQL语句，可以使用OUTLINE来加固其执行计划。在10g中DBMS_OUTLN.CREATE_OUTLINE可以根据已有的执行正常的SQL游标来创建OUTLINE。如果事先对所有频繁执行的核心SQL使用OUTLINE加固执行计划，将最大可能地避免SQL语句性能突然变差。

　　注：DBMS_OUTLN可以通过$ORACLE_HOME/rdbms/admin/dbmsol.sql脚本来安装。

　　5. 使用SQL Profile。SQL Profile是Oracle 10g之后的新功能，此处不再介绍，请参考相应的文档。

　　除此之外，可以调整一些参数避免潜在的问题，比如将”_btree_bitmap_plans”参数设置为FALSE。

而在实际工作中，通过使用定制的统计信息收集策略，以及在部分系统上使用OUTLINE，系统基本上不会出现已有的SQL性能突然变差的情况。当然也有维护人员操作不当引起的 SQL 性能突然变差，比如建了某个索引而没有收集统计信息，导致SQL使用了新建的索引，而该索引并不适合于那条SQL；维护人员意外删除了表个索引的统计信息。