Oracle CFS报错：一次遭遇更值得注意
在使用Oracle Clusterware时，我们可能会遇到Oracle CFS报错的情况。这并不是什么稀奇的事情，在使用Oracle Clusterware过程中，出现各种错误是很常见的。但是，今天我们要讲的是一次遭遇更值得注意的Oracle CFS报错。
在我的工作中，我遇到了一个非常奇怪的问题。我们有一个2个节点的Oracle RAC集群，运行的是Oracle 11gR2，操作系统是Oracle Enterprise Linux 5.9。该集群已经运行了很长时间，但最近出现了一些奇怪的问题。我们发现，节点之间的Oracle CFS挂载点会不停地挂掉，我们尝试了很多办法，包括重启节点、重新安装Oracle Clusterware，但问题依然存在。
在检查日志时，我们发现了一些奇怪的事情。首先是在Oracle Clusterware日志中出现了以下错误：
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4000: Command Status Fled
然后，我们检查了Oracle CFS日志，发现了以下错误：
CFS-91001 [Verification fled with error 18]
CFS-91003 [Communication error]
这个问题看起来非常棘手，因为我们已经尝试了很多办法，但却无法解决。最终，我们决定查看一下操作系统的日志。在操作系统的日志中，我们发现了以下错误：
kernel: cfsd[31903]: segfault at 0000000000000000 rip 0000000000422820 rsp 00007fff62b68448 error 4
这就是我们遭遇到的问题。这个错误可能表明cfsd守护进程已经崩溃了。当这个守护进程崩溃时，Oracle CFS将无法正常运行，导致节点之间的通讯出现了问题。
我们做了一些研究，并发现了一个Oracle文档，其中提到了一个名为Bug 13528153的问题，该问题会在安装了EM Agent之后触发。我们使用的确实是EM Agent，而且似乎正是这个问题导致了我们的Oracle CFS出现了错误。
我们升级了我们的EM Agent版本，并重新启动了Oracle Clusterware。神奇的是，一切都恢复了正常，我们再也没有遇到了任何问题。
总结
这个问题的解决过程非常有启发性，因为它告诉我们，在处理Oracle Clusterware问题时，需要全面考虑所有可能的因素。如果我们仅仅停留在Oracle Clusterware日志或Oracle CFS日志中，我们可能无法找到问题的实际根源。只有当我们检查了操作系统日志时，我们才能找到真正的答案。
虽然这个问题的解决非常简单（升级EM Agent），但它告诉我们在使用Oracle Clusterware时，遇到问题时一定要细心，不要忽略任何可能的线索。只有这样，我们才能有效地解决问题。