Oracle 12c因bug导致ORA-04031问题处理过程 | 云和恩墨技术通讯精选
Oracle 12c因bug导致ORA-04031问题处理过程 | 云和恩墨技术通讯精选
各位亲爱的用户/读者朋友们：
为了及时共享行业案例，通告共性问题，达成知识共享和提前预防，我们整理和编辑了《云和恩墨技术通讯》（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 lkdebug3. 针对12.1版本，建议重启实例。