Oracle RAC一节点宕机致使另外一节点HANG的问题分析

        正所谓“福无双至，祸不单行”，生产上有套2节点Oracle 11.2.0.4数据库，其中2节点因硬件故障宕机，1节点去HANG住了。咱们一块儿来分析这起故障。

        凌晨4点半，值班同时电话说一套生产库节点2宕机了，机房的同事看机器正在启动，估计是硬件缘由致使的。心想节点2宕了还有一个节点1在跑，应该问题不大，因而继续睡觉，离公司近的另外一位DBA同事赶往现场支持。但是没有过多长时间，到现场的DBA反馈信息：活着的另外一节点也出问题了。在宕掉的那个节点2上部署了ogg，因为宕机，自动切换到了节点1，但ogg的复制进程延迟一直的增加，感受像是一直没有应用。

        尝试用sqlplus进入库结果却报了ORA-00020超过最大进程数，没法登陆数据库，没法分析数据库当前的情况。

        因而分析哪一个应用服务器链接这套数据库，是否是因为应用问题形成的。

        找到链接数最多的那个ip上的应用，与相关业务人员确认，能够封堵其链接数据库的端口，减小数据库的外部链接。但是把这个ip禁掉以后，别的ip链接数又涨上来了。开始想到，是否是因为数据库的问题致使应用处理慢，进而致使链接数过多呢。如今没法登陆数据库也没法进行验证。

        与业务部门沟通是否能够尝试kill部分会话，让DBA能够链接到数据库后台，进行一些管理操做，和性能分析。获得业务部分同事的确定答复以后，kill了部分LOCAL=NO的会话。以sysdba登陆数据库后台，执行性能分析语句，刚查完session的等待事件，查第二个sql的时候，sql执行卡住了。重新的窗口登陆数据库依然报ORA-00020。这里进一步肯定了是因为数据库的性能问题致使了ogg及应用的问题。

        数据库都HANG住了，如何分析呢？

        想到了之前看别人分享的一个hanganalyze在数据库HANG住时能够用于分析HANG的缘由，因而找到命令ORADEBUG hanganalyze 3。分析trace文件，看到hang chain以下图

        再往下看，SMON进程在等待parallel recovery coord wait for reply，等待时间已经有289min，正是故障出现到hanganalyze的时间，并且他阻塞了1465个session。

        从trace中看到等待事件为parallel recover coord wait for reply 、gc domain validation。没见过这个等待事件，因而查询MOS，关于这两个等待事件的文档不是不少，找到一篇

        不知是否触发了ORACLE的BUG。

        因为时间紧迫，只能选择把节点1的数据库实例进行重启，重启后数据库恢复正常。

        过后找大神帮忙分析缘由，看SMON进程的trace信息

        发现正在作并行恢复，查看OSW中的SMON进程监控，没有发现性能问题。

        查看到有大量的p00xx的进程，说明是在并行进行恢复，也没有看出有什么问题。

        大神建议使用TFA查看日志进行详细，结果没有时间分析就给搁置了。

        总结故障就是：节点2宕机，节点1要接管节点2的数据，结果节点1也由于接管HANG住了。