当前位置: 首页 >> 技术文章 >> Oracle 12c因bug导致ORA-04031问题处理过程 | 云和恩墨技术通讯精选
Oracle 12c因bug导致ORA-04031问题处理过程 | 云和恩墨技术通讯精选
发布时间:2019-08-23 发布人:盖国强 151


各位亲爱的用户/读者朋友们:

为了及时共享行业案例,通告共性问题,达成知识共享和提前预防,我们整理和编辑了《云和恩墨技术通讯》(8月刊),通过对过去一段时间的知识回顾和故障归纳,以期提供有价值的信息供大家参考。

同时,我们也希望能够将热点事件、新的产品特性及其他有价值的信息聚集起来,为您提供具有前瞻性的支持信息,保持对于当前最新的数据库新闻和事件的了解,其中包括重要数据库产品发布、警报、更新、新版本、补丁等。


本期目录:

新闻:2019年8月数据库流行度排行
警示:12.1.2.0与11.2.0.4通过DB Link查询触发BUG 17890099
警示:Oracle 12c因bug导致ORA-04031
警示:ORA-00600 2252 错误正在SCN问题下不断爆发
经验:12c多租户实例意外宕机处理
经验:记一次tuxedo crash的故障处理
问题:故障排除之enq:TX - index contention等待事件
公告:墨天轮DBASK技术专家邀请函

抢先下载:https://www.modb.pro/doc/572 


部分精选-Oracle 12c因bug导致ORA-04031(姜劲松)

ORA-04031这个错误,几乎每一个专业的DBA都遇到过。这是一个相当严重的错误,Oracle进程在向SGA申请内存时,如果申请失败,则会抛出这个错误,大部分情况下是在向SGA中的shared pool申请内存时失败。在Oracle 12.1.0.2及以后版本中,有可能是因为触发了bug 26405036  Large Allocation Of "ges enqueues" and "ges resource dynamic" In The Shared Pool导致数据库shared pool内存爆满引发ORA-04031报错,这个bug在19.1版本上已经修复,针对12.2的版本需打上相应的补丁进行修复。

问题描述

在7月17日上午11时10左右,某客户收到告警短信,提示数据库(12.2的三节点RAC环境)的2号节点宕机,当即登陆该节点进行查看,发现数据库状态正常,但日志里出现大量的ORA-04031报错,提示无法分配shared_pool,手动执行shared pool刷新脚本进行刷新,刷新后shared pool使用率仍然为70%左右。此时有业务反馈数据库节点3无法连接,客户决定对节点3进行重启,重启后恢复正常,经过后续观察,节点2 的ORA-04031报错也再没有出现。

问题分析

查看当时节点二的告警日志,发现日志中抛出ORA-04031报错信息
 

问题分析

节点三10:49就开始报ORA-04031,直到11:51被手动停止实例
 

问题分析

所以故障原因最早是节点三实例导致的,查看4031 的dump trace文件,在heapdump发现ges resource dynamic/ges enqueues异常高:
 

问题分析

问题分析

查看这2个pool的变化趋势,发现ges resource dynamic/ges enqueues一直在持续增长:
1. 故障前ges enqueues达到17GB,重启后恢复为3.8GB,但后续还是会增长;
2. 故障前ges resource dynamic高达22GB(2个子池),重启后4.8GB,后续0718 06:00新增1个1.2GB子池并持续增长。
 

问题分析


问题解决

根据该故障现象,查询MOS发现:Bug 26405036  Large Allocation Of "ges enqueues" and "ges resource dynamic" In The Shared Pool。
 

问题解决

且该bug出现的数据库版本和本库匹配(本库版本Linux 12.2.0.1,fix在19.1.0才包含),现象也匹配。《》

建议解决措施:
1. 针对12.2版本,通过应用补丁Patch 26405036: VERY HIGH "GES ENQUEUES" ON THE SHARED POOL得到解决。
2. 针对12.2版本,workaround可以在出现问题时临时使用如下命令清理内存(后续还是会增长):
SQL> oradebug setmypid
SQL> oradebug lkdebug -m reconfig lkdebug

3. 针对12.1版本,建议重启实例。