Oracle的SQL BASELINE和SQL PROFILE

有个客户前阵子一条SQL因为统计信息问题走错执行计划，导致CPU资源耗尽，系统出现严重故障，必须下线部分功能才临时解决了问题，后来在开发商的尝试下通过SQL PROFILE解决了错误执行计划的问题，恢复了系统。事后远程健康服务中心、Oracle原厂都参与了故障总结，都认为是因为统计信息不准导致了执行计划错误。当时我也提出了一个更为彻底的解决方案，就是合并USERID和日期的两个索引为复合索引，不过因为该表太大，开发商不太愿意重建索引，所以就没有执行。

这个问题一般比较多的出在月底月初，只要产生了硬解析就容易出问题。自从加了SQL PROFILE也消停了一阵子。不过昨天又出问题了。

早上突然CPU飙升到100%，因为出过类似问题，所以很快就怀疑到了这条SQL上了。做个AWRSQRPT发现确实存在两个执行计划，又有SQL用错索引了，似乎SQL PROFILE没有去作用了。

故障报到我们的远程健康服务中心的时候，我们的支撑人员建议他们用SQL BASELINE固化执行计划，很快就恢复了系统。虽然问题解决的很快，不过用户还是有些疑问，为什么上回出问题时候，研发部门采取的通过SQL PROFILE优化执行计划的策略失效了。

实际上用户是把SQL PROFILE当成绑定执行计划了，其实从原理上讲，SQL PROFILE并不是强行绑定执行计划，而是通过SPM分析发现统计信息与实际运行情况不符，因此通过SQL PROFILE设置了一些TABLE_STATS hint，