Oracle官方文档的错误解释如下：

Cause: A host language program call referenced a cursor with no associated parsed SQL statement. A SQL call (for example, OSQL3) must be used to pass a SQL statement to Oracle and to associate the statement with an open cursor. A cursor must already have an associated SQL statement if referenced in any of the following calls: DESCRIBE, NAME, DEFINE, BIND, EXECUTE, and FETCH.

Action: Do the SQL call, for example, OSQL, to pass the required SQL statement before referencing the cursor.

但既然只是重新编译了一下，肯定不会是存储过程的语法有问题。greenflute认为这个问题与Weblogic无关，像Package, Procedure, Prepared statement之类的东西通过jdbc调用的时候，Oracle会把预编译之后的结果保存在自身的Cache之中，当你重新编译了存储过程以后，这些Cache中的东西变成无效，导致Oracle抛出ORA-01003错误。只有重新建立新的Oracle会话（即重新建立数据库连接）或者dba通过命令强制清除Cache才能解决这个问题。

对于Weblogic来说，由于采用了数据库连接池来访问数据库，连接将被保持，因而Cache不会被清除。最直接的解决方法：重启Weblogic应用服务器。如果不想重启Weblogic的话，似乎只能在Oracle管理后台里面强制drop所有来自Weblogic服务器的数据库会话--确切地说都不算是很好的解决方案。但对于已经上线的应用来说，类似存储过程之类的东西也不应该是频繁进行改动的；如果是开发环境，那么不用想太多，重启Weblogic吧。

这是目前为止对这个问题的调查结论。期待以后能找到更明确的解释。让我感到奇怪的是我以前自己写的独立的应用程序也用过各种各样的连接池，也用了很多的存储过程，也曾经在运行的过程中重新编译过，但好像还没有碰到过这个问题，只在Weblogic中碰到了。

Update: 托technorati的福，在和本文相关的Tags里面偶然看到一篇日志Improving JDBC performance with Statement caching，突然想到Weblogic的Connection Pool确实是可以对常规的数据库连接做些手脚的。这个 StatementCacheSize 参数就是设置来对所有通过Pool产生的PreparedStatement/CallableStatement 进行Cache。对于存储过程的调用当然也就在其Cache之列了。赶紧让WangWei去做对这个猜测进行测试。

解决办法：要么禁用Weblogic Connection Pool的Statement caching功能，要么不要对在线的存储过程进行修改。