1. Oracle 19c集群巡检概述

作为企业级数据库系统的核心组件，Oracle 19c RAC集群的稳定运行直接关系到业务连续性。不同于单实例数据库，集群环境涉及节点间通信、资源共享和故障转移等复杂机制，这使得常规巡检需要特别关注集群特有的健康指标。我在金融行业运维Oracle集群的五年实践中，发现超过60%的严重故障其实都有前期预警信号，只是被常规检查遗漏了。

完整的集群巡检应该覆盖三个维度：硬件资源层（服务器、存储、网络）、集群软件层（GI资源状态、节点间通信）和数据库层（实例状态、性能指标）。每次巡检就像给数据库做全身体检，不仅要看表面症状，更要发现潜在风险。下面这个真实案例很能说明问题：某电商平台在促销前巡检时发现一个节点cache fusion网络延迟偏高，及时更换网卡避免了活动期间集群脑裂事故。

2. 集群健康检查核心指标

2.1 节点可用性检查

首先通过crsctl工具检查集群服务状态：

# 检查集群整体状态 crsctl check cluster -all # 输出示例： CRS-4537: Cluster Ready Services is online CRS-4529: Cluster Synchronization Services is online CRS-4533: Event Manager is online

任何非"online"状态都需要立即排查。我曾遇到一个案例，节点2的CSS服务显示为"offline"，最终发现是multicast地址被防火墙拦截。

关键检查点：

• 所有节点VIP状态正常（ip addr show）
• SCAN监听器响应正常（srvctl status scan_listener）
• 节点间时钟同步偏差小于100ms（ntpstat）

2.2 集群资源状态分析

使用以下命令获取详细资源报告：

crsctl stat res -t -init

要特别注意以下几点：

1. 所有数据库实例状态应为ONLINE
2. 表决磁盘（voting disk）健康状态
3. OCR磁盘组冗余状态

常见异常处理：

• 资源频繁切换：检查节点负载均衡和网络延迟
• 资源卡在INTERMEDIATE状态：可能需要强制清理（crsctl stop res -f）

2.3 缓存融合性能检查

RAC集群的核心是Cache Fusion机制，通过以下SQL监控全局缓存效率：

SELECT inst_id, name, value FROM gv$sysmetric WHERE name IN ('GC CR Block Received Time', 'GC Current Block Received Time') AND group_id = 2;

健康阈值：

• GC CR Block Received Time < 15ms
• GC Current Block Received Time < 20ms

重要提示：当网络延迟超过30ms时，应考虑检查私网互联（如更换为RDMA网卡）

3. 存储与日志深度检查

3.1 ASM磁盘组健康度

ASM是RAC存储的基础，定期检查磁盘组冗余状态：

SELECT name, state, type, total_mb, free_mb FROM v$asm_diskgroup;

重点关注：

• 剩余空间不足20%时需要扩容
• 任何磁盘的FAILGROUP状态异常
• 重平衡操作是否完成（v$asm_operation）

3.2 集群日志分析

日志是故障诊断的金矿，关键日志位置：

1. GI报警日志：$GRID_HOME/log/ /alert .log
2. OCR自动备份：$GRID_HOME/log/ /client/ocrbackup_ .log
3. 节点驱逐日志：$GRID_HOME/log/ /agent/crsd/oraagent_oracle/oraagent_oracle.log

使用adrci工具高效分析：

adrci> show alert -tail 50

4. 性能瓶颈排查实战

4.1 全局等待事件分析

运行以下SQL识别集群性能瓶颈：

SELECT inst_id, event, count(*) FROM gv$session_wait WHERE wait_class != 'Idle' GROUP BY inst_id, event ORDER BY 3 DESC;

典型RAC特有等待事件：

• gc cr block busy：热点块争用
• gc buffer busy acquire：全局缓存竞争
• ges lock grant queue：全局锁等待

4.2 实例负载均衡检查

理想的RAC应该实现工作负载均匀分布：

SELECT inst_id, round(100*sum(case when status='ACTIVE' then 1 else 0 end)/count(*),1) as active_rate, count(*) as total_sessions FROM gv$session GROUP BY inst_id;

当某个实例的active_rate持续高于其他实例15%以上，需要考虑服务重分配。

5. 巡检自动化方案

5.1 使用Orachksum工具

Oracle官方提供的巡检工具：

$ORACLE_HOME/suptools/orachk/orachk -c all -d output_dir

检查内容包括：

• 集群配置最佳实践
• 已知问题匹配
• 性能基线偏差

5.2 自定义巡检脚本

这是我日常使用的巡检脚本框架：

#!/bin/bash # 集群状态检查 crsctl check cluster -all > cluster_status_$(date +%F).log # ASM空间检查 sqlplus -S / as sysdba @asm_space_check.sql # 性能指标收集 awr_report.py --last 4 --all-instances

6. 关键问题处理记录

6.1 脑裂场景处理

当集群出现脑裂时（节点间失去通信），应按以下步骤处理：

1. 确认故障范围：crsctl check cluster -all
2. 收集诊断信息：diagcollection.pl -collect -crshome $GRID_HOME
3. 谨慎执行节点恢复：crsctl stop cluster -all
4. 逐节点启动：crsctl start cluster -n <node_name>

6.2 OCR损坏恢复

若OCR出现损坏，使用自动备份恢复：

ocrconfig -restore $GRID_HOME/cdata/<cluster_name>/backup_<timestamp>.ocr

恢复后务必验证：

ocrcheck

7. 巡检报告生成技巧

专业的巡检报告应包含：

1. 执行摘要（1页）：关键发现和建议
2. 详细发现（按严重程度排序）：
   • 紧急问题（需24小时内处理）
   • 重要问题（需一周内处理）
   • 优化建议
3. 历史对比：与上次巡检结果的指标变化

使用以下命令生成HTML格式报告：

orachk -html -u dbaadmin -p "password" -c all -o full_report.html

在每月例行的某银行系统巡检中，通过分析AWR报告发现一个异常：节点2的"gc cr block busy"等待突然增加。进一步检查发现是该节点SSD缓存卡故障导致块传输延迟，更换硬件后性能提升40%。这个案例说明，不能只满足于集群"能运行"，更要关注性能指标的异常波动。