ITPUB论坛-中国最专业的IT技术社区

 找回密码
 注册
查看: 4593|回复: 6

[原创] Oracle游标泄露(open_cursor耗尽)

[复制链接]
认证徽章
论坛徽章:
0
发表于 2017-7-26 14:12 | 显示全部楼层 |阅读模式
前言

编者注,本文的知识点较多,请补充足够正能量后阅读,看完会让你质疑你的DBA生涯,作者的水平代表着国内Oracle TroubleShooting最高水平。


很早就想把ORA-1000的问题,总结成一个话题。机缘巧合,最近恰好遇上几个此类问题,特分享分析过程出来供大家参考。

首先,ORA-1000报错是什么意思呢?我们来看看官方的解释:

1.png


非常简单,单个进程打开的游标数超过了最大值,也就是超过了数据库设置的open_cursos参数的值;面对这样的情况,不同的DBA会有不同的解决方案:调整open_cursors参数?还是直接把问题抛给开发人员?

今天老猫就来给大家分享一个处理ORA-1000的经典案例,看看大家的处理方式和我们的处理方式有什么不一样?在处理过程中老猫又用到了什么不一样的处理技巧?处理完能收获什么样的心得体会?

2
来活啦

客户来电求助,系统周期性地报ORA-1000的错误,之前客户已经多次调整open_cursors参数,目前已经调整到了2000了,难道还是接着一直往上调?open_cursors是针对一个单个进程打开cursor数的限制,对于一般应用来说,如果能及时关闭cursor,2000个已经足够使用,那么这里是客户没有正确关闭游标还是其本身就需要同时打开大量游标抑或是其他原因呢,这已经极大地勾起了我的兴趣!找出根因,并提供解决方案,是我们在服务客户过程中的一贯态度。


3
捕捉信息



面对ORA-1000这种应用级的错误,我们一般可以通过设置errorstack时收集报错进程的process dump来进行分析;而如果报错没那么容易出现,我们就会选择在之前抛错业务频繁执行的时段做个systemstate dump,主要目的是可以看看这类业务执行时server process中都open了哪些cursor,然后根据现象进行进一步的分析,判断问题的原因;

这里客户系统是周期性的报ORA-1000错误,于是建议客户开errorstack,收集trace文件进行分析。



4
开始分析


首先是设置1000的errorstack;


2.jpg

ORA-1000错误发生时,会生成一个trace,通过观察trace发现在,确实打开了2000个cursor,在trace中搜索cursor#可以看到,发现cursor都是打开的同一个SQL:SELECT activityno,ruleno FROM T_RM_COUPONINF;


3.jpg

那么问题来了,为什么对同一个SQL会打开这么多cursor呢?仔细观察一下我们就会发现这个SQL的特别之处,Excutioncount=0&LoadCount=299&InvalidationCount=300,还记得老猫分享的第十二期的故事么,这是典型的解析错误的问题!


4.jpg

不过这里我们就不用设置10035事件去确认了,我们试图来解析SQL:SELECT activityno,ruleno FROM T_RM_COUPONINF;很快我们就发现了问题,T_RM_COUPONINF这个对象根本就不存在!



到这里,看起来我们发现了两个问题:
1.       进程中打开了一条错误SQL的cursor;
2.       在遇到编译错误后,进程没有及时关闭cursor,似乎对这段代码的处理过程没有加catchexecption或者finally的过程;

那么是谁发起了这条SQL,在没有编译成功的情况下,没有关闭cursor呢?模拟这样的代码一点都不难,脑子里闪过无数个草泥马…骂谁还不好说,先冷静,由于这个问题可以在测试环境重现。



5
定位来源



通常来说,数据库中运行的SQL可以分为两种,普通SQL和递归SQL;由于这里,sql本身存在错误,所以我们无法直接定位SQL到底是来自外部(普通SQL)还是数据库(递归SQL);这时,我们就可以使用10046事件来帮忙了;


5.jpg

可以看到10046的trace中有如上一条解析错误的记录,err=942即抛错ORA-942,意味着表或视图不存在;同时还有另一关键的点:dep=0,即SQL的递归深度为0,也就是非递归SQL!所以,只能找开发来确认了,开发给出明确的答复却让人沮丧:这条SQL不是应用发出来的!



不是应用写的,也不是数据库自己产生的,那么这SQL来自于哪里呢?我再仔细捋了捋思路,发现我们在日常处理问题的过程中,经常忽略的一个环节,那就是JDBC包;一般认为,JDBC主要是为了维护应用与数据库的连接的,但实际上,JDBC在这个过程中也是有可能执行一些SQL的,甚至可以通过一些配置重新封装应用程序发到数据库服务器的SQL语句,在这个过程中,出现一些问题也是可能的。

至此,我们暂时将问题定位到JDBC上;查看JDBC版本,是12.1.0.2数据库自带的。OK,范围缩小到JDBC。下一步debug JDBC。



6
不一样的trace



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

6.jpg

观察结果JDBC trace文件:

7.jpg

没错,我们看到了那条SQL的身影,看来错误SQL确实是来自于JDBC;



7
原因确认

原来,应用持久化框架里为了取得SQL的绑定变量信息,调用Oracle JDBC的PreparedStatement.getParameterMetaData()函数, 在这个方法里,JDBC取得parameter metadata的方法是:生成一条SQL:SELECT activityno, ruleno FROM T_RM_COUPONINFO,通过编译这条SQL,取得activityno, ruleno两个列的metadata信息,然后返回给客户应用。



不幸的是:在生成这条SQL时,出现了错误----丢掉了一个字母O,导致ORA-942的错误。错就错了吧,你至少要关掉cursor呀。JDBC的开发疏忽了。
正确sql:
SELECT activityno, ruleno FROM T_RM_COUPONINFO
目前解析成的sql:
SELECT activityno, ruleno FROM T_RM_COUPONINF

这是JDBC递归SQL引发的一个问题,其实是JDBC12.1.0.2的一个BUG。


8
解决问题



将收集的errorstack和JDBC trace提交到oracle support;GCS还是蛮给力的,不长时间就提供了一个patch。


9
老猫小提示



大家可能会疑惑,为什么老猫开的SR反馈这么快,我开的SR却迟迟没有进展呢?
其实,老猫作为从原厂出来的老司机,就这个CASE而言,你要了解下面两点:


1. JDBC在Oracle内部是个很跨界的产品,它的support其实是负责中间件的工程师,而不是Oracle Database工程师。当你开一个ORA-1000的问题给Database工程师时,你实在不能指望他会java;当你开给中间件工程师,又不能指望他对Database有多深的了解,势必扯皮。老猫在原厂时,遇上这类问题,通常是在五楼阳台抽烟时,互相沟通一小会儿的。大家工作压力都很大,还没到自己手里的问题,没人真的上心。
2. 能重现的问题,尽量作一个test case给Oracle support,把能提供的信息提供好。在这个案例中,我们把现象,问题发生的函数,trace证据全都提供给support,减少了交互,减少了扯皮。所以,问题解决得很快。


总而言之,对于每个自己的SR,我们尽量提供自己所了解的所有信息,SR的进展就会更顺利。


10
问题总结



这个问题,我们看到,作为一个好的DBA,绝对不能只是改改参数,或者是将看起来与数据库无关的问题一手推给开发人员;我们可以做的是,把问题定位到最小范围内,至于确确实实涉及到数据库内层不公开的部分,只要提供足够的信息,我们相信SR也能帮助我们定位到数据库底层的问题。

论坛徽章:
4
优秀写手
日期:2015-02-12 06:00:15优秀写手
日期:2015-02-01 06:00:14喜羊羊
日期:2015-03-04 14:52:462015年新春福章
日期:2015-03-06 11:58:18
发表于 2017-7-26 16:28 | 显示全部楼层
学习了,高手

使用道具 举报

回复
认证徽章
论坛徽章:
6
奥运纪念徽章
日期:2013-07-18 13:55:122014年新春福章
日期:2014-02-18 16:49:31马上有钱
日期:2014-02-18 16:49:31火眼金睛
日期:2017-01-03 01:13:18目光如炬
日期:2016-12-12 01:27:58目光如炬
日期:2016-12-25 22:00:00
发表于 2017-7-26 17:28 | 显示全部楼层
本帖最后由 kunlunzhiying 于 2017-7-26 17:34 编辑

赞老猫。
我们前几天同样遇到了游标泄漏问题,Open_curosrs 还设置的是10000.


后来定位到是一oracle bug 解决的。p10324576_R12.FND.B_R12_LINUX

使用道具 举报

回复
论坛徽章:
20
双黄蛋
日期:2013-05-02 16:23:37法拉利
日期:2013-12-09 09:34:16马上有房
日期:2014-07-22 17:26:492014年新春福章
日期:2014-02-18 16:44:08马上有对象
日期:2014-02-18 16:44:08沸羊羊
日期:2015-02-25 10:40:302015年新春福章
日期:2015-03-04 14:53:162015年新春福章
日期:2015-03-06 11:58:39喜羊羊
日期:2015-03-09 12:20:50夏利
日期:2013-08-26 15:11:26
发表于 2017-7-27 14:33 | 显示全部楼层
不懂开发的DBA 不是合格的DBA

使用道具 举报

回复
论坛徽章:
0
发表于 2017-8-11 11:20 | 显示全部楼层
牛逼的对吧

使用道具 举报

回复
论坛徽章:
3
ITPUB 11周年纪念徽章
日期:2012-10-09 18:14:482013年新春福章
日期:2013-02-25 14:51:24射手座
日期:2015-12-17 12:42:07
发表于 2017-9-29 18:19 | 显示全部楼层
赞,

使用道具 举报

回复
论坛徽章:
3
秀才
日期:2017-08-18 11:04:35秀才
日期:2017-08-18 11:06:45秀才
日期:2017-09-18 17:03:09
发表于 2017-10-9 17:07 | 显示全部楼层
NB  UPUPUPUP

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则

TOP技术积分榜 社区积分榜 徽章 电子杂志 团队 统计 虎吧 老博客 知识索引树 读书频道 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档 | IT博客
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛 | SAP ERP系统
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 网站律师 隐私政策 知识产权声明
京ICP备16024965号 北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表