早上看到数据库一个节点的load比昨天翻倍，细查之下，发现主要是由新上线的一条sql引起的，查询语句如下

捕获的Sql语句结构如下

其中表a有800多万条记录，其上的字段sub_id和parent_id均有索引；而表b只有20条；

结果发现该sql执行计划的cost很低，只有6，但是buffer gets却很高，有6位数。
刚开始感觉是统计信息陈旧，查看后发现表A是昨天收集的，而表B也是最近收集的，因此排除这个可能。
仔细查看执行计划，发现其选择了parent_id上的索引，而非sub_id，这点比较可疑。
经查看parent_id=0的记录占了全表记录的80%，而且该列上没有直方图，导致CBO选择执行计划的时候误用了基于parent_id列的索引。

原因找到了，接下来是如何解决。
首先，重新收集表a的统计信息并收集parent_id上的直方图，考虑表a的访问十分繁忙，如果现在就让该游标失效会导致大量硬解析DB有可能因此而hang住，如果不让其失效load又一直居高不下，因此在调用
Dbms_stats.gather_table_stats的时候指定了no_invalidate为auto(也可以不标注，因为默认就是auto)，决定让oracle自动决定何时去invalidate该游标。

之后观察了一段时间，发现该sql还是使用原来的错误执行计划，load还是居高不下。
我们的系统是10.2.0.5的，而oracle好像是10.2以后就可以调用dbms_shared_pool.purge了。
Support.oracle.com查了一下，发现调用该功能之前还必须要设定事件 alter session set events '5614566 trace name context forever';
由于不能判定其造成的影响，决定暂不使用该功能。

此刻，既不能对表做grant select on a to dba操作，也不能使用dbms_shared_pool.purge，而bad sql仍在运行。

忽然，我们组长想到了一个方案，对表b做grant select on b to dba操作(表b访问热度相对就少了很多)。
执行过后，sql立即选择了sub_id上的索引，buffer gets下降到了两位数，数据库压力不到1分钟就下降到了正常状态。