我们都希望对于所有在Oracle数据库中执行的SQL，CBO都能产生出正确的执行计划，但实际情况却并非如此，由于各种各样的原因(比如目标SQL所涉及的对象的统计信息的不准确，或者CBO内部一些成本计算公式的先天缺陷等)，导致有时CBO产生效率不高、甚至是错误的执行计划。特别是CBO对目标SQL所产生的初始执行计划是正确的，后来由于某种原因(比如统计信息的变更等)而导致CBO重新对其产生了错误的执行计划，这种执行计划的改变往往会导致目标SQL执行时间呈数量级的递增，而且常常会让我们很困惑：这个SQL原先跑得好好的，为什么突然就慢得让人无法接受？其实这种SQL执行效率突然衰减往往是因为目标SQL执行计划的改变。
我们当然希望这样的改变永远不要发生，即在Oracle数据库中跑的所有SQL都能有正确的、稳定的执行计划，但实际上在Oracle 11g的SPM(SQL Plan Management)出现之前，这一点是很难做到的。那么现在退而求其次，如果已经出现了执行坟墓的变更，即CBO已经产生了错误的执行计划，我们应该怎么纠正呢？
我种情况下，我们通常会重新收集一下统计信息或者修改目标SQL(比如在目标SQL中加入Hint等)以纠正错误的执行计划。但有时候重新收集统计信息并不能解决问题，更糟糕的是，很多情况下是没有办法修改目标SQL的SQL文本的(比如第三方开发的系统，修改不了源码，或者目标SQL是前台框架动态生成的等等)，那么这种情况下我们该怎么办呢？
在Oracle 10g/11g及其以后的版本中，我们可以使用SQL Profile或SPM(SQL Plan Management)来解决上述执行计划变更的问题，用它们来调整、稳定目标SQL的执行计划。
本文介绍使用SQL Profile来稳定执行计划：
Oracle 10g中的SQL Profile(直译为“SQL概要”)可以说是Oracle 9i中的Stored Outline(直译为“存储概要”)的进化。Stored Outline能够实现的功能SQL Profile也完全能够实现。
与Stored Outline相比，SQL Profile具备如下优点：
更容易生成、更改和控制
在SQL语句的支持上做得更好，也就是说适用范围更广。
使用SQL Profile可以很容易实现如下两个目的：
锁定或者说稳定执行计划
在不能修改目标SQL的SQL文本的情况下使目标SQL语句按指定的执行计划运行。
SQL Profile有两种类型：一种是Automatic类型，另一种是Manual类型。下面分别介绍这两种类型：
1. Automatic类型的SQL Profile
Automatic类型的SQL Profile其实就是针对目标SQL的一些额外的调整信息，这些信息存储在数据字典里。当有了Automatic类型的SQL Profile后，Oracle在产生执行计划时就会根据它对目标SQL所涉及的统计信息等内容做相应的调整，因而能够在一定程度上避免产生错误的执行计划。你不用担心Automatic类型的SQL Profile的准确性，因为Oracle会使用类型于动态采用技术那样的手段来保证这些额外调整信息相对准确。
Automatic类型的SQL Profile不会像Stored Outline那样锁定目标SQL的执行计划，因为Automatic类型的SQL Profile的本质就是针对目标SQL的一些额外的调整信息，这些额外的调整信息需要与原目标SQL的相关统计信息等内容一起作用才能得到新的执行计划，即原始SQL的统计信息等内容一旦发生变化，即使原有Automatic类型的SQL Profile并没有改变，该SQL的执行也可能会发生变化。从这个意义上讲，Automatic类型的SQL Profile并不能完全起到稳定目标SQL的执行计划的作用，虽然它确实可以用来调整执行计划。
看一个在不更改目标SQL的SQL文本的情况下使用Automatic类型的SQL Profile来调整执行计划的实例：
创建测试表及相关操作：
从上述显示内容可以看出，目标SQL走的是对表T1的全表扫描(Table Access Full)，这个执行计划显然是错误，这里正确的执行坟墓应该是走索引IDX_T1的索引范围扫描(Index Range Scan)。下面使用SQL Tuning Advisor对这条SQL生成Automatic类型的SQL Profile。
a.先创建一个名为my_sql_tuning_task_2的自动调整任务：
注：创建任务时可以使用SQL来创建，可以适用于SQL文本长的情况。详情参考官方文档。
b.执行上述自动调整任务
c.查看上述自动任务的调整结果
从上述调整结果可以看到，Oracle现在告诉我们：它已经为目标SQL找到了更好的执行计划，并且已经创建了针对该SQL的Automatic类型的SQL Profile。如果我们使用accecp_sql_profile接受了这个SQL Profile，则目标SQL的响应时间将会有86.24%的提升，逻辑读将会有95%的提升，并且接受了该SQL Profile后目标SQL的执行计划将会由原来的全表扫描变为索引范围扫描。
上面Automatic类型的SQL Profile所产生的调整结果就是我们想要的，所以现在只需按Oracle的提示接受这个SQL Profile即可：
接受此SQL Profile后我们来看一下效果，再次执行目标SQL:
注意到Note部分有这样的内容“SQL profile SYS_SQLPROF_015a82b353490000 used for this statement”这说明我们刚才接受的SQL Profile已经起了作用，该SQL Profile的名字为SYS_SQLPROF_015a82b353490000。从执行计划中也可以看到，执行计划确实已经改变了。
另外，DBMS_SQLTUNE.ACCEPT_SQL_PROFILE的输入参数force_match的默认值为FALSE，表示只有在SQL文本完全匹配的情况下才会应用SQL Profile，这种情况下只要目标SQL的SQL文本发生一点变动，原有的SQL Profile将会失去作用，如果设置为TRUE，即使SQL有变动SQL Profile也会强制生效。
删除SQL Profile
2. Manual类型的SQL Profile
Manual类型的SQL Profile本质上就是一堆Hint的组合，这一堆Hint的组合实际上来源于执行计划中的Outline Data部分的Hint组合。Manual类型的SQL Profile同样可以在不更改目标SQL的SQL文本的情况下，调整其执行计划，而且更为重要的是，Manual类型的SQL Profile可以起到很好稳定目标SQL的执行计划的作用，这一点是Automatic类型的SQL Profile所不具备的。
看一个使用Manual类型的SQL Profile实例固定执行计划的实例，使用上面的t1表，删除上面的SQL Profile，再次执行SQL
从上述输出可以看出执行计划仍然走全表扫描。
现在来创建Manual类型的SQL Profile。这里使用了MOS上的一个脚本coe_xfr_sql_profile.sql。这个脚本用于从Shared Pool、AWR Repository中指定SQL的指定执行计划的Outline Data部分的Hint组合，来创建Manual类型的SQL Profile。
使用coe_xfr_sql_profile.sql脚本的步骤为
针对目标SQL使用coe_xfr_sql_profile.sql产生能生成其Manual类型的SQL Profile的脚本A。
改写目标SQL的文本，在其中使用合适的Hint，直到加入Hint后的SQL能走出我们想要的执行计划。然后对加入合适Hint后的SQL使用脚本coe_xfr_sql_profile.sql，产生能生成其Manual类型的SQL Profile的脚本B。
用脚本B中的Outline Data部分的Hint组合替换掉脚本A的Outline Data部分的Hint组合。
执行脚本A生成针对原目标SQL的Manual类型的SQL Profile。
现在改写上面的SQL，强制走索引：
从执行计划中可以看出SQL Id和对应的Plan hash value。
全表扫描的SQL Id：6chcc0pvvhqqm Plan hash value：3617692013
索引扫描的SQL Id：2ufquy7xs5nm5 Plan hash value：1369807930
a. 先使用coe_xfr_sql_profile.sql生成全表扫描SQL对应的脚本
从输出可以看出，生成一个名为coe_xfr_sql_profile_6chcc0pvvhqqm_3617692013.sql的脚本。
b. 用coe_xfr_sql_profile.sql生成索引扫描SQL对应的脚本
从输出可以看出，生成一个名为coe_xfr_sql_profile_2ufquy7xs5nm5_1369807930.sql的脚本。
c. 把后生成的脚本里的Outline Data部分的Hint组合替换到先生成的脚本里，即下图红框部分内容
d. 执行coe_xfr_sql_profile_6chcc0pvvhqqm_3617692013.sql脚本
e. 执行完成后再次查看目标SQL的执行计划
从执行计划中可以看出已经走了INDEX RANGE SCAN，而且note部分提示SQL profile coe_6chcc0pvvhqqm_3617692013 used for this statement，说明执行sql时使用了该SQL Profile。
如果想在目标SQL的SQL文本发生变动时SQL Profile依然生效，则需要修改生成的脚本里的force_match=>true。
