chm是rac节点驱逐前唯一秒级os指标数据源，不依赖数据库/crs/asm；需用utc时间、正确路径及grid用户执行chmca提取，并检查.bdb完整性与timestamp是否紧邻驱逐日志。
CHM（Cluster Health Monitor）是唯一能在RAC节点被驱逐前持续采集秒级OS指标的数据源，只要ologgerd进程在宕机/驱逐前仍在运行，且.bdb文件未损坏，数据就可提取——它不依赖数据库、CRS或ASM是否存活。
确认CHM数据是否覆盖驱逐时刻
很多人看到crsctl stat res ora.crf -init显示STATE=OFFLINE就认为没数据，这是错的。关键看两点：
- 用
chmca -d /opt/oracle/chm -s "2026-10-01 08:22:00" -e "2026-10-01 08:23:00" -n racnode2导出CSV后，检查其中最大timestamp是否紧邻驱逐日志时间（如/var/log/messages里cssd报evicting node那条） - 去驱逐节点挂载磁盘后，检查
/opt/oracle/chm/db/racnode2/crfclust.bdb是否存在且file crfclust.bdb返回Berkeley DB——若为data或empty，说明文件已损毁
用chmca提取宕机前60秒峰值数据
chmca对输入极其敏感，常见失败不是因为没数据，而是参数错：
- 时间必须是UTC：若驱逐日志写的是
Oct 1 08:22:15 CST（CST = UTC+8），则-s必须填"2026-10-01 00:22:00"，不能用T分隔或本地时区 - 路径必须是
reppath父目录：oclumon manage -get reppath返回/opt/oracle/chm/db/racnode2，但-d只能填/opt/oracle/chm - 必须用
grid用户执行，且grid对.bdb有读权限；若属主是root，先chown grid:oinstall *.bdb
定位驱逐前最关键的三个OS指标峰值
别看平均值，重点筛出驱逐前60秒内单点最高值——瞬时叠加才是压垮节点的元凶：
-
os_cpu_utilization> 95% 且连续 ≥3 秒：再查os_runqueue_length是否同步飙升，排除监控抖动 -
os_mem_used_percent> 90% 并伴随os_swap_in_out_rate突增：说明开始疯狂换页，osysmond自身可能被OOM killer干掉（查dmesg | grep -i "killed process"） -
os_network_receive_bytes_per_sec或os_network_transmit_bytes_per_sec单点超阈值（如> 800MB/s）：结合os_network_receive_errors看是否网卡丢包引发CSS心跳失败
真正容易被忽略的是：CHM数据虽独立于CRS，但ologgerd若因内存不足提前退出，.bdb里最后一条记录的时间戳就会早于驱逐时间——这时得交叉比对ocssd日志中首次出现missed heartbeat的时间，倒推30秒再试一次chmca提取。
