Oracle RAC故障排查与日志分析实战指南

1. Oracle RAC故障排查全景指南

作为一名经历过无数次深夜救火的DBA，我深知Oracle RAC环境故障排查的痛点。不同于单机环境，RAC架构的分布式特性使得问题定位往往需要跨越多层日志体系。本文将系统梳理RAC环境下的日志查看路径与关键诊断方法，这些实战经验曾帮助我在30分钟内定位过导致业务停摆2小时的集群脑裂问题。

2. 排查方法论：分层诊断策略

2.1 故障域划分原则

RAC环境故障通常呈现"雪崩效应"——一个层面的异常会引发连锁反应。我习惯将排查分为三个层级：

1. 系统层：硬件、OS内核、网络等基础设施
2. 集群层：CRS、ASM、节点间通信等集群服务
3. 数据库层：实例进程、SQL执行等数据库活动

重要提示：实际排查时应遵循"由外向内"原则，先确认底层环境正常，再深入数据库内部问题。我曾见过团队花费6小时排查SQL性能问题，最终发现是存储阵列的电池故障导致IO延迟。

2.2 节点信息快速获取

开始排查前需要确认基础信息（以下命令在所有节点执行）：

bash复制# 获取节点名称
hostname

# 获取实例名（在SQLPLUS中执行）
show parameter instance_name;

# 获取数据库名
show parameter db_name;

3. 系统层深度排查

3.1 操作系统日志分析

系统层问题常表现为节点意外重启、硬件故障等。关键日志位置：

bash复制cd /var/log/
# 按时间倒序查看系统消息日志
ll -lthr message*

重点关注：

• 硬件错误（disk, memory, CPU相关）
• OOM killer记录
• 网络中断事件
• NTP时间同步异常

实战案例：某次节点频繁重启，最终在message日志中发现"EDAC MC0: UE memory read error"记录，确认是内存条故障。

3.2 网络与存储检查

bash复制# 检查网络连通性
ping -c 3 <其他节点VIP>
ping -c 3 <SCAN_IP>

# 检查多路径状态（存储环境）
multipath -ll

# 检查ASM磁盘头状态（需grid用户）
kfed read /dev/oracleasm/disks/DATA_DG1 | grep kfbh.type

4. 集群层关键日志解析

4.1 集群警报日志(alert.log)

集群的"黑匣子"，记录CRS、VIP、ASM等核心资源的异常事件。

bash复制su - grid
# 典型路径（根据实际ORACLE_CRS_HOME调整）
ll -lthr $ORACLE_CRS_HOME/log/$(hostname)/alert$(hostname).log

# 备选路径（11g常见）
ll -lthr /u01/app/grid/diag/crs/$(hostname)/crs/trace/alert.log

关键内容：

• 节点驱逐(eviction)事件
• 资源启动/停止记录
• 心跳超时警告
• ASM磁盘组状态变更

4.2 CRS守护进程日志

bash复制# CRSD主日志（资源管理）
ll -lthr $ORACLE_CRS_HOME/log/$(hostname)/crsd/crsd.log

# 实时检查资源状态
crsctl stat res -t -init

典型问题：

• CRS-0215：资源启动失败
• CRS-2674：资源状态异常
• CRS-2632：节点通信故障

4.3 核心进程日志组

OHASD日志

集群基础服务的"总指挥"：

bash复制ll -lthr $ORACLE_CRS_HOME/log/$(hostname)/ohasd/ohasd.log

OCSSD日志

节点心跳与脑裂防护：

bash复制ll -lthr $ORACLE_CRS_HOME/log/$(hostname)/cssd/ocssd.log

EVMD日志

集群事件总线：

bash复制ll -lthr $ORACLE_CRS_HOME/log/$(hostname)/evmd/evmd.log

排查技巧：当出现节点驱逐时，这三个日志需要交叉比对。我曾通过ohasd日志发现是ocssd进程被OOM killer终止，而根本原因是误配置的HugePages挤占了过多内存。

4.4 ASM诊断日志

bash复制# ASM警报日志
ll -lthr /u01/app/grid/diag/asm/+asm/+ASM2/trace/alert_+ASM2.log

# ASM磁盘组状态检查（SQL*Plus）
select name, state, total_mb, free_mb from v$asm_diskgroup;

常见故障模式：

• 磁盘路径变更导致ASM磁盘组MOUNT失败
• 存储阵列性能问题导致ASM重平衡卡住
• 多路径配置错误导致ASM磁盘丢失

5. 数据库层诊断工具

5.1 数据库警报日志

bash复制su - oracle
ll -lthr $ORACLE_BASE/diag/rdbms/$DB_NAME/$INSTANCE_NAME/trace/alert_$INSTANCE_NAME.log

重点关注：

• ORA-00600/ORA-07445内部错误
• 实例恢复(instance recovery)进度
• RAC特有的锁转换(lock conversion)问题
• 等待事件突增情况

5.2 AWR/ASH报告生成

常规报告生成

sql复制sqlplus / as sysdba
-- AWR报告
@?/rdbms/admin/awrrpt.sql
-- ASH报告
@?/rdbms/admin/ashrpt.sql

手动快照（紧急情况）

sql复制begin
  dbms_workload_repository.create_snapshot();
end;
/

报告分析要点：

• 检查gc cr block busy等待事件
• 关注global cache相关统计项
• 对比各节点负载均衡情况

5.3 集群诊断工具集

TFA日志收集

bash复制su - grid
cd $ORACLE_HOME/tfa/bin
./tfactl diagcollect -all -from "2023-07-27 02:50:00" -to "2023-07-27 03:00:00"

OSWatcher分析

bash复制su - grid
ps -ef | grep osw
cd $ORACLE_BASE/tfa/repository/suptools/$(hostname)/oswbb/grid/archive

关键指标：

• CPU利用率（特别是sys%过高）
• 内存交换(swap)情况
• 网络丢包率
• 存储IO延迟

6. 经典故障排查案例

6.1 节点驱逐问题

现象：节点频繁被驱逐，alert.log显示"Eviction initiated for node 2"

排查步骤：

1. 检查ocssd.log中的心跳超时记录
2. 验证网络连通性（ping/私网带宽）
3. 检查存储响应时间（asm_disk_io_stat视图）
4. 确认时钟同步状态（ntpstat）

最终原因：存储阵列控制器缓存电池故障导致IO延迟飙升至2000ms，触发心跳超时。

6.2 VIP漂移故障

现象：VIP无法在节点间迁移，业务连接中断

排查路径：

1. crsd.log查看资源状态转换失败原因
2. ohasd.log检查网络资源配置
3. 操作系统层面验证IP配置（ifconfig）
4. 检查ARP缓存情况（arp -an）

解决方案：网络交换机端口STP配置错误导致VIP通告失败，调整交换机配置后恢复。

7. 高级诊断技巧

7.1 日志时间戳关联

RAC环境需要将各节点日志时间对齐：

bash复制# 设置统一时间格式
export TIMEFORMAT='[%Y-%m-%d %H:%M:%S]'

# 跨节点日志同步查看
pdsh -w racnode1,racnode2 "grep 'CRS-2674' $ORACLE_CRS_HOME/log/$(hostname)/crsd/crsd.log"

7.2 动态跟踪CRS事件

bash复制crsctl debug trace res ora.db.db1.svc -t
crsctl debug log res "ora.db.db1.svc:1" "SQLT:1"

7.3 内存转储分析

当遇到进程崩溃时：

bash复制# 查找trace文件
cd $ORACLE_BASE/diag/rdbms/$DB_NAME/$INSTANCE_NAME/trace
ls -ltr *trc

# 使用oradebug分析
oradebug setmypid
oradebug dump errorstack 3

8. 预防性维护建议

1. 日志轮转策略：

   bash复制# 配置日志自动清理
   crsctl modify resource ora.crsd -attr "AUTO_START=always,CHECK_INTERVAL=30,LOGGING_LEVEL=1"
   

2. 定期健康检查：

   sql复制-- 检查RAC组件状态
   select * from gv$cluster_interconnects;
   select * from gv$instance;
   

3. 容量规划：

   sql复制-- 监控缓存融合流量
   select * from gv$cr_block_server;
   

4. 备份关键配置：

   bash复制# 集群配置导出
   crsctl export cluster -all -output /backup/crs_config.xml
   

这套方法论在笔者维护的多个32节点RAC环境中经过验证，平均故障定位时间从原来的4小时缩短至40分钟。记住，好的DBA不是在解决问题，而是在问题发生前就消除隐患。