ASM第二个实例异常报ORA-600错误，而另一个节点报4031错误的分析处理

ASM实例负责管理ASM的元数据，管理ASM磁盘，ASM磁盘组等，这个案例是某路局巡检发现的ASM磁盘组无法写入。这是个两节点集群，个节点报错4031错误，ORA-04031: unable to allocate 3768 bytes of shared memory ，第二个节点报错ORA-00600: internal error code, arguments: [ORA_NPI_ERROR], [603], [ORA-00603: ORACLE server session terminated by fatal error，从个节点4031看，与ASM实例内存使用有关系，4031错误一般是内存碎片或者是内存不足导致。

1 问题描述 

报错信息如下：

ORA -00569: Failed to acquire global enqueue.

ORA-00600: internal error code, arguments: [ORA_NPI_ERROR], [603], [ORA-00603: ORACLE server session terminated by fatal error

ORA-16038: log 4 sequence# 15223 cannot be archived

ORA-16038: log 4 sequence# 15247 cannot be archived

……

ORA-16038: log 6 sequence# 16872 cannot be archived

ORA-17502: ksfdcre:4 Failed to create file +RECOVERY

ORA-19504: failed to create file ""

2 问题分析：

从报错信息看是600异常造成无法写ASM磁盘组，其实这个错误的根因在于ASM实例内存大小和使用有关系。这个是我们的猜测，我们从MOS找到一篇详细的说明，大家可以参考：

ASM MANAGED DATABASE HITS ORA-00600 [ORA_NPI_ERROR], [603] + ORA-00569: FAILED TO ACQUIRE GLOBAL ENQUEUE ERRORS (Doc ID 1623955.1)

这个影响到11.2.0.3版本以及之后的版本。从文章的原因知道这是一个bug，Bug:16502516 - ORA-600 ARGS [ORA_NPI_ERROR], ALONG WITH ORA-00603 & ORA-00569，这个bug虽然是公开了，但是处于“Suspended‘ 状态，需要再ASM端解决4031错误，解决这个问题的方案是增加ASM实例的内存，从实际分配开目前两个实例仅仅配置了800M内存，根据系统总内存大小，我建议提高到2G 内存，具体实施需要使用高可用的方式，也就是先调整第二节点（不能写ASM磁盘节点），在调整个节点，使得第二个节点可以接过业务连接，如果先调整个节点很可能导致第二个节点重启（没有磁盘心跳）。其实，之后我的建议也是先2再1 ，但是具体实施时，对方觉得先1后2，也应该没问题，对于客户的坚持，我觉得我们说清利害关系就好了，事实证明我们的判断是对的，在实际实施时，用户调整1节点，导致了2节点重启，使得业务短暂中断，但是由于时间很多，几分钟，又是晚上实施，业务没有感知，也没有反馈，算是幸运吧。

3 建议方案：

1 申请变更窗口，需要与业务部门沟通协商。

2重启二节点集群，修改ASM实例的SGA为2G。等集群、数据库状态正常后，重启1节点，修改ASM实例的SGA为2G.

4 实施结果：

客户在2020年01月19日晚20：00实施变更，20：30变更结束，两个节点集群、数据库状态正常，问题解决。