Oracle RAC故障处理经验分享

"Oracle RAC 故障处理过程，涉及RHEL6.6系统上的2节点RAC数据库，使用ASM存储，遇到CSS和HA无法启动的问题，最终通过重新执行root.sh脚本解决。" 在Oracle Real Application Clusters (RAC)环境中，当遇到故障时，处理过程通常需要深入分析和调试。在这个具体的故障案例中，问题出现在一个2节点的RAC数据库上，运行在Red Hat Enterprise Linux (RHEL) 6.6操作系统上，数据库版本为11.2.0.1.0，使用Automatic Storage Management (ASM)作为存储解决方案。 1. **故障描述** - 故障表现为两个节点的Clusterware (CSS) 和 High Availability (HA) 服务无法正常启动。CSS是RAC中的核心组件，用于管理集群的同步和心跳，而HA确保在节点故障时能无缝切换服务。 2. **故障排查** - 开始时，故障处理者查看了错误日志，同时搜索了Oracle Metalink Support (MOS)、百度和Google，尝试了各种可能的解决方案，包括尝试OCR (Oracle Configuration Registry) 的还原。 - OCR是RAC中的关键组件，存储集群配置信息，其丢失或损坏可能导致集群无法启动。 3. **解决步骤** - 当常规方法无效时，采取了重新执行`root.sh`脚本的策略。这个脚本是Oracle Clusterware安装的一部分，用于配置集群软件。在执行前，需要注意保持磁盘组不受影响，但在11.2.0.1版本中，可能无法使用`-keepdg`选项。 - 在第一个节点上执行卸载命令后，集群成功启动，但尝试以exec模式启动CRS (Cluster Resource Manager) 时，集群再次出现问题，OCR的磁盘无法找到。 4. **进一步处理** - 由于磁盘问题，故障处理者决定重新安装第二个节点的多路径软件，希望能恢复磁盘可见性。尽管如此，问题仍然存在，于是寻求了存储专家的帮助。 - 通过群内的肖总协助，存储问题得到解决，磁盘被找到。 5. **恢复操作** - 在存储问题解决后，继续进行恢复工作，包括再次执行`deconfig`命令来重新配置集群，这通常是解决OCR问题的步骤之一。 这次故障处理过程突显了RAC环境中的复杂性，特别是当涉及存储和多路径软件时。处理这类问题需要深入理解Oracle集群架构，以及与操作系统和存储设备的交互。此外，团队合作和利用社区资源也是解决问题的关键。