rac 某节点dml、dql出现大量gc等待时间的排查和处理

rac 某节点dml、dql出现大量gc等待时间的排查和处理

作者简介：王旭，在数据库管理方面拥有10多年经验。精通主流数据库系统，在企业数据库管理、性能优化、架构设计和高可用性能解决方案方面拥有丰富得实践经验。目前拥有（ORACLE ACE、MYSQL OCP、PG ACE、PGCA、PGCE、PGCM）等数据库认证。

背景

过节期间，有朋友找到我，说一个大库，现在业务经常出现故障，导致卡死，问题具体情况，他说是升级了某个业务后出现的。 故障现象为某个接口半夜只要一运行就卡死。

通过直接运行一样的情况：

运行环境

redhat 6.x + oracle 11.2.0.4 rac双节点 内存：256g cpu：144

排查和处理（部分未截图）

我通过查询活动会话等分析，发现有大量的sql都在1节点卡住，并且他们产生了大量的gc等待事件：

卡住的sql有insert、update等语句，看到部分锁和阻塞源，将其kill还是如此，不管怎么杀，过一会又出来；

然后我拿到其中一个insert语句来分析，该语句写法如下： insert ... select ...

然后将select部分拿出来，执行卡住了...

看sql执行计划没有任何问题，全部走索引，awr和cursor等查看都正常，但为啥执行不出来呢？接着改写sql，改到最后单表查询还是卡死，改成了如下： select count(*) from tab where time >=(当天) and time <=(当天)；

看到这里我就怀疑和rac有关了，而不是他升级导致的；很明显一个单表的select不可能查询卡住啊；

继续10046 trace，在2节点运行正常，1节点执行卡几分钟，第一步parse一直卡住，然后再是等待gc cr request\gc current request；

搜索mos，发现该问题是一个bug，通过执行如下命令暂时得到了处理：

处理完成后继续分析，检查操作系统的参数、数据库参数、io情况、网络；

• io通过增加表空间，发现最大io 为117m/s，在2.5t大库环境运行OLTP业务中，这种算是很差的情况了；

• 系统内核参数 默认的，开了个大页，连透明大页也没关。在rac环境中，不关这个不是找死吗？参考oracle 进行关闭： Disable Transparent HugePages on SLES11, RHEL6, RHEL7, OL6, OL7, and UEK2 and above (Doc ID 1557478.1)

• 另外资源回收相关的vm参数一个都没设置。信号量参数设置也和oracle分配的process不合理。

• 网卡，业务网卡服务器上是做的bond：

BONDING_OPTS="mode=0 miimon=100 primay=eth0" mode=0为不是rac安装所建议的，该模式需要交换机支持，在本例中也有大量的sql... to client/from client等待事件，判断和这个有关，将其调整如下： BONDING_OPTS="mode=1 miimon=100"

• oracle参数也是设置混乱，我甚至都不想去管，但又实在看不下去，将参数文件转换后逐步清理调整；

...

总结

• 处理了太多的卡、慢，宕机案例，基本上都和配置有关，在本例中也不例外。
• 为什么会出现这种问题，基本上是信息化管理和重视程度不够，找一些非专业的dba实施、实施人员运维，导致系统存在风险，我估计做这个rac的人连修改参数都改不来，另外也没有相关linux调优的经验，网卡绑定随便设置。综合其它它就产生卡、慢情况。
• 另外asm存储性能差，服务器大量的垃圾sql运行，长时间未优化，drm等特性未关闭，导致业务心跳私发大量的数据。形成大量的gc等待，通过一系列处理优化，业务运行不再卡顿。
• 从底层逐步调整到数据库层面，最后找到业务中的垃圾sql，逐步调整sql就不再卡顿。