环境：两台联想R680的物理机搭建一套2节点RAC，数据库版本为ORACLE 11.2.0.4
一、故障问题现象：
节点2频繁发生重启，从1月至2月发生多次重启，甚至一天内3次重启，让人头疼。
二、问题分析处理过程：
1、时间同步问题
首先怀疑是时间不同步造成的。
观察现象是该服务器的ntp时间同步offset过大（下图offset为11376）
并在数据库的CTSS日志出现不正常的返回值
在这里发现一个问题，就是时间源指向旧的时间源服务器10.33.144.18和10.33.144.19，而服务器在新的数据中心，所以修改为新数据的时间源服务器11.8.13.1和11.8.13.9，并修改了BIOS时钟，使系统时钟和硬件时钟时间一致。至此，时间同步问题排除。
2、数据库日志反应的问题
通过查ALERT日志，发现有节点驱逐
又查CSSD日志发现
显示有磁盘的心跳，但无网络的心跳。
此时判断：node 2 节点老是频繁重启，私网出问题的概率会较大，因此从网络处查。node 2 每次重启完以后，都能顺利加入rac集群，更不是时间同步的问题。
补充：
如果集群中的节点连续丢失磁盘心跳或网络心跳，该节点就会被从集群中驱逐，也就是节点重启。组管理导致的节点重启，我们称之为node kill escalation（只有在11gR1以及以上版本适用）。重启需要在指定的时间（reboot time,一般为3秒）内完成。
网络心跳:ocssd.bin进程每秒钟向集群中的各个节点通过私网发送网络心跳信息，以确认各个节点是否正常。如果某个节点连续丢失网络心跳达到阀值，misscount（默认为30秒，如果存在其他集群管理软件则为600秒），集群会通过表决盘进行投票，使丢失网络心跳的节点被主节点驱逐出集群，即节点重启。如果集群只包含2个节点，则会出现脑裂，结果是节点号小的节点存活下来，即使是节点号小的节点存在网络问题。
磁盘心跳：ocssd.bin进程每秒钟都会向所有表决盘（Voting File）注册本节点的状态信息，这个过程叫做磁盘心跳。如果某个节点连续丢失磁盘心跳达到阀值disk timeou(一般为200秒)，则该节点会自动重启以保证集群的一致性。另外，CRS只要求[N/2]+1个表决盘可用即可，其中N为表决盘数量，一般为奇数。
3、核查网络的问题
这套RAC的心跳网是由ETH13和ETH15两块网卡组成，对应两个交换机的两个端口。
先后采取激活宕掉交换机两个端口和网卡口没有解决问题，最后又采用换线、单独拉线等解决办法，发现线的光衰有点大，但重启问题没有最终解决。
4、是否是硬件的问题？
问题至此陷入了困境，换个思路既然网络和数据库都可能不是问题，那么硬件真的能独善其身，超然之外么？
答案是否定的，那就是硬件的问题。
在节点发生重启时，数据库的日志里有中断的现象，那么会不会是CPU和内存的问题呢？检查下MCELOG日志就知道了。
MCELOG不容忽视的日志
mcelog 是 x86 的 Linux 系统上用来检查硬件错误，特别是内存和CPU错误的工具。它的日志就是MCELOG.
一般来说大内存的服务器容易出现内存上的问题，现在内存控制器都是集成在cpu里，内存的校验错误和CPU的问题易引起服务器的重启。
好了，下面我们看看MCELOG日志的错误提示
ORACLE官方对MCELOG事件的解释：
至此，问题浮出水面。和硬件厂商联系，刷主板固件程序，更换一根内存后问题最终解决。
三、问题总结与思考：
1、不能忽视监控的作用。这次内存硬件的问题，在服务器硬件监控平台没有被发现，这个需要联系厂商，继续完善服务器硬件监控的细粒度和敏感性
2、从日志、网络、数据库、系统、硬件等方面全面排查，问题终会被发现。
3、解决问题靠的是耐心和细心，进一步再进一步，问题终会被解决。
本文出自 “滴水穿石孙杰” 博客，转载请与作者联系！