问题描述
某日，客户的系统突然出现故障，业务系统无法使用。DBA发现三节点的集群突然变慢，其中1号和2号节点的数据库均无法正常使用。
晚上19点左右接到报障后，老白立即远程登录进行处理，由于当时是客户的业务高峰期，因此首要是恢复系统运行，然后再开展问题调查，消除故障隐患。
通过HANGANALYZE分析发现1节点大量会话HANG住，并且存在大量GCBUFFER BUSY WAIT等待的会话，杀掉其中几个阻塞严重的会话后，ZZZOSS1恢复正常。
在处理ZZZOSS2的时候发现2号节点也存在大量HANG住情况，杀了数个阻塞会话后，仍无法恢复，只能采取重启的方式。重启2号节点后，系统恢复正常。
分析过程
通过ALERT LOG检查发现，18:53分ZZZOSS3出现了故障，并且进行了自动重启，自动重启后，就出现了集群3个节点全部HANG住的现象。HANG住的主要原因是ZZZOSS1,ZZZOSS2在帮助ZZZOSS3做实例恢复时出现了大量的全局热块冲突，从而导致RACINTERCONNECT故障。ZZZOSS3被驱逐的主要原因是18:52分时ZZZOSS1,ZZZOSS2与ZZZOSS3的lms通讯突然发生异常。从而导致ZZZOSS1,ZZZOSS2认为ZZZOSS3出现了故障，从而驱逐ZZZOSS3。
通过对ZZZOSS3相关LMS进程日志的分析发现：
LMS进程在等待56/57号闩锁，通过V$LATCHNAME查一下相关闩锁的名称：
56号闩锁是OS PROCESS：request allocation，这和进程的内存分配有关，57号闩锁是kair sgalatch，和SGA内存管理有关。出现这两个闩锁等待，首先怀疑是操作系统的内存出现了问题。
于是检查ZZZOSS3的nmon日志，发现从18:45分左右开始，物理内存空闲比例大幅度下降，并且在18:51分开始出现了大量的系统换页。从而可以初步断定操作系统换页是该问题的最主要原因。
故障原因
1、 由于几天前客户做操作系统升级失败，操作系统升级回退后，以前调整过的参数maxperm%恢复为系统缺省的80%（为防止类似故障出现，之前3个节点的maxperm%都已经修改为15%），因此大量物理内存被文件缓冲占用，一旦系统有大内存需要，可能导致严重换页，从而导致LMS进程无法获得足够的操作系统资源和时间片，和其他节点通讯异常，从而导致节点分裂
2、 节点分裂后，在做实例恢复的时候，出现了RAC GCS问题，而DRM没有关闭，从而导致数据库HANG住
处理方案
1、将maxperm%修改为15%
2、关闭DRM
评论
1 1 0 点赞 0 点赞
