共计 2011 个字符，预计需要花费 6 分钟才能阅读完成。
| 导读 | 对于 SQL PROFILE 和 SQL PLAN BASELINE，如果选择错误，就很容易引发不可预知的隐患，因此需要十分谨慎的选择。Oracle 建议通过 SPM 的建议来选择，而不要依靠 DBA 的自己判断来选择，从而避免错误使用。不过我觉得遇到类似问题，往往都和索引设计比较混乱有关，优化索引设计可以从更上游去解决此类问题。 |
有个客户前阵子一条 SQL 因为统计信息问题走错执行计划，导致 CPU 资源耗尽，系统出现严重故障，必须下线部分功能才临时解决了问题，后来在开发商的尝试下通过 SQL PROFILE 解决了错误执行计划的问题，恢复了系统。事后远程健康服务中心、Oracle 原厂都参与了故障总结，都认为是因为统计信息不准导致了执行计划错误。当时我也提出了一个更为彻底的解决方案，就是合并 USERID 和日期的两个索引为复合索引，不过因为该表太大，开发商不太愿意重建索引，所以就没有执行。
这个问题一般比较多的出在月底月初，只要产生了硬解析就容易出问题。自从加了 SQL PROFILE 也消停了一阵子。不过昨天又出问题了。
早上突然 CPU 飙升到 100%，因为出过类似问题，所以很快就怀疑到了这条 SQL 上了。做个 AWRSQRPT 发现确实存在两个执行计划，又有 SQL 用错索引了，似乎 SQL PROFILE 没起作用了。
故障报到远程健康服务中心的时候，我们的支撑人员建议他们用 SQL PLAN BASELINE 固化执行计划，很快就恢复了系统。虽然问题解决的很快，不过用户还是有些疑问，为什么上回出问题时候，研发部门采取的通过 SQL PROFILE 优化执行计划的策略失效了。
实际上用户是把 SQL PROFILE 当成绑定执行计划了，其实从原理上讲，SQL PROFILE 并不是强行绑定执行计划，而是通过 SPM 分析发现统计信息与实际运行情况不符，因此通过 SQL PROFILE 设置了一些 TABLE_STATS hint，从而让优化器可以使用更为精准的生成执行计划。下面这张图来自于 Oracle 的官方文档，可以很好的解释 SQL PROFILE 发挥作用的机理。
在 SQL PROFILE 提供的 HINT 中，并没有指定执行计划的内容，而只是设定了一些统计信息的纠正提示。因此设置了 SQL PROFILE 的 SQL 语句，SQL 解析的时候，会使用 PROFILE 中的对象的统计信息来纠正执行计划。这样做的好处是灵活，比如某张表上的索引修改了。这条 SQL 解析的时候会考虑这些因素，选择较好的执行计划。不过也有不好的地方，那就是某些时候，执行计划还是会错误。
SQL PROFILE 是 Oracle 10g 引入的新功能，从 11g 开始，Oracle 也看到了 SQL PROFILE 存在的不足，因此引入了一个新的功，SQL PLAN BASELINE。SQL PLAN BASE LINE 的作用与 SQL PROFILE 类似，不过采取的方法完全不同。按照 ORACLE 官方文档上的说法，SQL PLAN BASELINE 是用于避免存在问题的执行计划的。SQL PLAN BASELINE 采取的是强行绑定执行计划的方式。
上面这张图也来自于 Oracle 的官方文档，这张图十分清晰，从上面我们可以看出，SQL PROFILE 是用于纠正过去错误的执行计划的，但是并不限定今后不会再次使用这个错误的执行计划。而 SQL PLAN BASELINE 是用于确保以后不会使用错误的执行计划的。
SQL PLAN BASELINE 是一组可接受的计划。每个计划都使用一组 Outline hint 来实现，这些 hint 指定了特定的计划。而与之不同的是，SQL PROFILE 也使用 hint 实现，但这些 hint 没有指定任何特定的计划，仅仅纠正了优化器估算成本时产生的错误统计信息。
因为 SQL PROFILE 不会将优化器约束到任何一个计划，所以 SQL PROFILE 比 SQL PLAN BASELINE 更灵活。初始化参数和优化器统计信息的更改使优化器能够选择更好的计划。而 SQL PLAN BASELINE 一旦设定，那么今后这条 SQL 就只能使用一个固定的执行计划了。当某条 SQL 根据绑定变量的不同会有多个不同的最优执行计划的时候，SQL PROFILE 可以充分发挥其灵活性。但是 SQL PROFILE 会有一定的出错的可能性。
SQL PLAN BASELINE 就简单粗暴的多了，它是强制指定执行计划。这对于某条 SQL 只有一个唯一的最优执行计划的时候是最为有效的。不过它的缺陷是缺乏灵活性。
对于 SQL PROFILE 和 SQL PLAN BASELINE，如果选择错误，就很容易引发不可预知的隐患，因此需要十分谨慎的选择。Oracle 建议通过 SPM 的建议来选择，而不要依靠 DBA 的自己判断来选择，从而避免错误使用。不过我觉得遇到类似问题，往往都和索引设计比较混乱有关，优化索引设计可以从更上游去解决此类问题。
