数据库游标个数超出限制报错

系统周期性报ORA-1000的错误，之前已经多次调整open_cursors参数，目前已经调整到了2000了，难道还是接着一直往上调？

open_cursors是针对一个单个进程打开cursor数的限制

对于一般应用来说，如果能及时关闭cursor，2000个已经足够使用

那么这里是客户没有正确关闭游标，还是其本身就需要同时打开大量游标，或是其他原因呢

 

首先是设置ORA-1000的报错级别，目的是为了当该错误出现，会生成一个trace文件

 

通过观察trace发现，确实打开了2000个cursor，在trace中搜索cursor可以看到，发现cursor都是打开的同一个SQL：

SELECT activityno,ruleno FROM T_RM_COUPONINF;

我们试图来解析SQL：

SELECT activityno,ruleno FROM T_RM_COUPONINF；

很快我们就发现了问题，T_RM_COUPONINF这个表根本就不存在！

到这里，我们发现了两个问题：

1进程中打开了一条错误SQL

2在遇到编译错误后，进程没有及时关闭cursor

那么是谁发起了这条SQL，在没有编译成功的情况下，没有关闭cursor呢？

 

不是应用写的，那么这SQL来自于哪里呢？

在日常处理问题的过程中，经常忽略的一个环节，那就是JDBC包；一般认为，JDBC主要是为了维护应用与数据库的连接的，但实际上，JDBC在这个过程中也是有可能执行一些SQL的，甚至可以通过一些配置重新封装应用程序发到数据库服务器的SQL语句，在这个过程中，出现一些问题也是可能的。至此，我们暂时将问题定位到JDBC上。

 

前面初步怀疑到了JDBC上，接下来需要做的就是通过在应用代码中打开JDBC的trace即可。

观察结果JDBC trace文件：

看到了那条SQL的身影，看来错误SQL确实是来自于JDBC。

 

原来应用持久化框架里为了取得SQL的绑定变量信息，调用Oracle JDBC的函数， 在这个方法里，JDBC会生成一条SQL:SELECT activityno, ruleno FROM T_RM_COUPONINFO，然后返回给客户应用。

不幸的是：

在生成这条SQL时，出现了错误，丢掉了一个字母O。