Oracle 11GR2 RAC节点故障深度剖析：CRS Crash与诊断步骤

Oracle 11GR2 RAC (Real Application Cluster)节点crash故障分析是针对Oracle 11.2.0.4版本数据库集群在AIX 7100环境中遇到的问题进行深入探讨的文章。作者魏斌，作为新炬网络数据库专家，针对节点2突然crsh hang（即系统崩溃）的情况进行了详细故障排查和解决策略。 当遇到这样的故障时，首先，应关注数据库（DB）下的alert日志和相关trace日志，因为它们通常记录了问题发生时的关键信息。在这些日志中查找关于错误的详细描述和堆栈跟踪，有助于定位问题根源。同时，执行`crsctl`命令的状态检查和输出至关重要，因为它可能提供关于集群服务（CRS）状态的线索。 查看所有节点的`errpt-a`输出可以帮助收集系统级别的错误报告，特别是`GRID_HOME`目录下各服务（如CRSD、CSSD、OHASD等）的日志文件，如alert.log、crsd.log、ocssd.log以及agent日志。这些日志中可能会包含关于crash的具体原因，比如硬件故障、内存泄漏、资源争用等。 检查LMON、LMS*和LMD0 tracefiles对于理解锁管理、监控和诊断性能瓶颈也是必要的。这些文件记录了数据库实例在运行时的活动，包括事务处理和资源分配。 此外，检查OSW（Oracle Shared Workarea）的输出可以揭示与内存管理、线程池或共享组件相关的异常。OSW负责管理和调度数据库工作负载，任何异常都可能导致节点crash。 如果问题是CRS引起的重启，那么在`/etc/oracle/lastgasp`目录下的文件中会有相应的记录，这些记录会表明重启的原因，如crash恢复策略或维护任务。 最后，如果VIP（Virtual IP）没有正确地从故障节点切换到节点1，可能涉及到集群管理和网络配置，需要检查网络连接、VIP配置和集群状态的恢复策略。 对Oracle 11GR2 RAC节点crash故障的分析是一个系统性的过程，涉及数据库、服务日志、性能监控和集群管理等多个层面。通过细致的排查和利用适当的工具，可以有效地定位和解决此类问题，确保数据库集群的高可用性和稳定性。