最近碰到的两个ORACLE的case

最近碰到了两个oracle的case,很有意思。让我对cursor跟SQL的执行有了更深的了解。

[case 1]
问题现象：app team再作一个load test,然后某一个SQL的响应时间会从突然从7秒增长到30几秒。

identify cause: 通过分析，发现这个SQL每次变慢总是从晚上1点以后开始的。而且当SQL很慢的时候,用SQLPLUS登陆,使用相同的用户执行相同的SQL有时却是很快而有时却又很慢.
所以我猜测SQL的执行计划发生了改变,并不总是使用同一种执行计划.后来发现每天晚上1点以后我们的数据库会做一个全库备份(exp)---这说明在做数据库备份的时候,SQL的执行计划发生了改变.CBO优化器在选择执行计划的时候被备份干扰,使得它错误地评估各个执行计划的cost;从而选择了错误的

解决方法: 很简单,在SQL语句中使用hint /*+ ordered */来固定表连接的方式来固定执行计划

[case 2]
问题现象：有一个 app [部署在weblogic里面的ear] 在log中打出了cursor不够用的错误(ora-1000:maximum open cursors exceeded).
开始疯狂测试cursor的东西.
经过沛三指点确认,只有显式的declare cursor的sql语句才会发生cursor不释放的情况.隐式的cursor在sql执行完之后就会被释放掉--经过我的初步测试verify了上句话.

后来经过对涉及到的plsql代码的测试,初步估计plsql没有问题. 所以猜测问题应该出现在调用plsql的weblogic workshop的API里面.因为问题现在没法子重现(需要客户的另外的一些vendor协调测试),所以不能最终确定原因.