Oracle 19c RAC集群健康检查与故障排查指南

1. 项目概述

Oracle 19c RAC（Real Application Clusters）作为企业级数据库集群解决方案，其多节点运行状态的稳定性直接关系到核心业务系统的连续性。在实际运维中，我们经常需要快速判断集群健康状态，但官方文档往往过于庞杂，而网上资料又良莠不齐。这份优化版的排查指南，正是基于我在金融行业多年处理RAC故障的经验总结，提炼出最高效的检查路径。

注意：本文所有命令均在Oracle 19.3.0版本验证通过，适用于标准2-4节点RAC环境。特殊配置场景可能需要额外检查项。

2. 核心检查项与操作流程

2.1 集群基础状态速查

首先通过crsctl工具获取集群整体状态：

# 以grid用户执行 crsctl check cluster -all

典型健康输出应显示所有节点状态为"ONLINE"，类似：

CRS-4537: Cluster Ready Services is online CRS-4529: Cluster Synchronization Services is online CRS-4533: Event Manager is online

关键指标解析：

• 节点状态：必须全部ONLINE，任何OFFLINE节点都需要立即排查
• 服务状态：重点关注Clusterware三大核心服务（CRS/CSS/EVM）
• 响应时间：命令执行超过5秒可能预示网络或存储延迟

2.2 节点资源深度检查

2.2.1 资源状态全景视图

crsctl stat res -t

输出示例：

NAME TARGET STATE SERVER STATE_DETAILS -------------------------------------------------------------------------------- ora.DATA.dg ONLINE ONLINE node1 STABLE ora.LISTENER.lsnr ONLINE ONLINE node2 STABLE ora.ons ONLINE ONLINE node1 STABLE

异常状态处理指南：

1. OFFLINE状态：检查对应节点的alert日志
2. UNKNOWN状态：通常需要重启资源
3. FAILED状态：优先查看CRSD日志（$GRID_HOME/log/ /crsd/crsd.log）

2.2.2 存储层专项检查

# 检查ASM磁盘组状态 asmcmd lsdg # 检查表决磁盘健康 crsctl query css votedisk

存储排查要点：

• ASM冗余度：确保至少有一个FAILGROUP可用
• 表决磁盘：必须所有投票设备可访问
• I/O延迟：使用orion工具测试存储性能

2.3 网络健康诊断

2.3.1 私网连通性测试

# 在所有节点执行 cluvfy comp nodecon -n all -verbose

网络优化建议：

• 使用Jumbo Frame（MTU=9000）
• 禁用UDP校验和卸载
• 确保SCAN IP可解析

2.3.2 冗余网络检查

oifcfg getif

健康配置应显示至少两个私网接口：

eth0 192.168.1.0 global public eth1 10.0.0.0 global cluster_interconnect

3. 高级诊断技巧

3.1 日志快速定位法

关键日志路径：

1. 集群日志：$GRID_HOME/log/<hostname>/alert<hostname>.log
2. RAC实例日志：$ORACLE_BASE/diag/rdbms/<dbname>/trace/alert_<dbname>.log
3. OHAS日志：$GRID_HOME/log/<hostname>/ohasd/ohasd.log

使用以下命令实时监控：

tail -f $GRID_HOME/log/`hostname`/alert`hostname`.log | grep -E 'ORA-|ERROR|FAIL'

3.2 AWR报告关键指标

生成最近1小时的AWR报告：

SQL> @?/rdbms/admin/awrrpt.sql

核心关注点：

• 全局缓存等待事件：'gc cr block busy'
• 实例效率百分比：应>95%
• 集群等待时间：'cluster wait ratio'

4. 常见故障处理手册

4.1 节点驱逐（Node Eviction）

典型症状：

• 节点突然重启
• 日志中出现"Evicting member"消息

处理步骤：

1. 检查表决磁盘空间：df -h | grep voting
2. 验证网络心跳：ping -c 10 <其他节点私网IP>
3. 分析ocssd日志：grep -i "evict" $GRID_HOME/log/<hostname>/cssd/ocssd.log

4.2 脑裂（Split Brain）

应急方案：

# 强制停止集群 crsctl stop cluster -all -f # 在主节点重建集群 crsctl start cluster -all

预防措施：

• 确保表决磁盘奇数配置（至少3个）
• 私网使用冗余链路
• 定期验证存储多路径配置

5. 性能优化补充

5.1 缓存融合调优

调整以下参数（需重启实例）：

ALTER SYSTEM SET "_gc_policy_time"=0 SCOPE=spfile; ALTER SYSTEM SET "_gc_lms_processes"=4 SCOPE=spfile;

5.2 服务分布优化

使用srvctl平衡服务：

srvctl modify service -d <dbname> -s <service> -r "node1,node2" -a "node3,node4"

最佳实践：

• 关键服务配置TAF（Transparent Application Failover）
• 分离OLTP和报表服务到不同实例
• 使用Services实现工作负载管理

6. 自动化监控方案

推荐使用以下Shell脚本定时检查（配置到crontab）：

#!/bin/bash CRS_STATUS=$(crsctl check cluster) if [[ $CRS_STATUS != *"ONLINE"* ]]; then echo "CRITICAL: Cluster status abnormal - $CRS_STATUS" | mail -s "RAC Alert" dba@example.com fi

扩展建议：

• 集成Prometheus+Granfa实现可视化监控
• 配置OCWCH（Oracle Clusterware Health）检查
• 对关键指标设置基线告警阈值

我在实际运维中发现，90%的RAC问题可通过本文的检查流程快速定位。特别是在金融行业的高并发场景中，定期执行这些检查可预防大部分突发故障。最近一次重大事故排查中，正是通过crsctl stat res -t发现的ASM磁盘组异常，避免了数据文件损坏。