CHM是唯一能在RAC节点宕机前捕获秒级OS指标的数据源，其数据由osysmond推送至ologgerd写入本地BDB文件，独立于数据库和CRS；需检查timestamp是否临近崩溃时间、.bdb文件是否完好，并用chmca以UTC时间精准提取宕机前60秒峰值数据。
CHM 是唯一能在 RAC 节点宕机前捕获秒级 OS 指标的数据源——只要 oclumon 仓库没被清空、ologgerd 在宕机前仍在运行，数据就存在。它不依赖数据库实例存活，也不需要 AWR 或 SQL 执行上下文。
确认 CHM 采集是否覆盖宕机时刻
很多人误以为“节点挂了 CHM 就没数据”，其实不然：CHM 数据由 osysmond 实时推送给 ologgerd，后者写入本地 BDB 文件（如 crfclust.bdb），这个过程独立于数据库和 CRS 的完整性。关键看两点：
- 宕机前最后一条记录的时间戳是否临近崩溃时间（用
chmca -d /path/to/chm -s "2026-09-15 14:22:00" -e "2026-09-15 14:23:00" -n racnode1导出并检查 CSV 中最大timestamp） - 宕机节点的
/opt/oracle/chm（或oclumon manage -get reppath返回路径）下是否存在未损坏的.bdb文件——即使节点无法启动，只要磁盘可挂载，数据就能提取 - 若
crsctl stat res ora.crf -init显示STATE=OFFLINE，不代表历史数据丢失；但若oclumon manage -get repsize返回OCM-00012: Repository not found，说明 CHM 从未启用或已被手动销毁
从 .bdb 文件中抢救宕机前 60 秒数据
chmca 是唯一能读取原始 BDB 的工具，但它对时间范围非常敏感：指定的 -s 和 -e 必须落在实际采集窗口内，且格式严格为 "YYYY-MM-DD HH:MM:SS"（注意空格，不能用 T 分隔）。常见失败原因：
- 时区错配：
chmca解析的是 UTC 时间，而系统日志（如/var/log/messages记录的 ocssd kill 时间）多为本地时区，需先转换（例如 CST 是 UTC+8，若宕机日志写的是2026-09-15 14:22:33 CST，则-s应设为"2026-09-15 06:22:00"） - 路径错误：不能直接用
/opt/oracle/chm/db/racnode1/，必须是/opt/oracle/chm（即reppath的父目录） - 权限不足：必须用
grid用户运行，且该用户对.bdb文件有读权限；若文件属主是root，需先chown grid:oinstall *.bdb
定位宕机前最关键的三个指标峰值
导出 CSV 后，不要看平均值，重点筛出宕机前 60 秒内单点最高值。真正压垮节点的往往不是持续高负载，而是某几秒的瞬时叠加：
-
os_cpu_utilization> 95% 且持续 ≥3 秒：结合os_runqueue_length看是否真有大量进程等待 CPU，排除监控抖动 -
os_mem_used_percent> 90% 并伴随os_swap_in_out_rate突增：说明开始疯狂换页，osysmond自身也可能因内存不足被 OOM killer 杀掉 -
os_io_wait_time> 500ms 且os_disk_busy_percent接近 100%：典型存储卡死信号，常导致ocssd.bin心跳超时，触发节点驱逐
为什么 CHM 数据有时“看起来有，却提不出有效信息”
最常被忽略的是数据保留策略和磁盘空间隐性失效。CHM 默认只保留约 3 天数据（按 repsize 配置的字节数循环覆盖），但一旦磁盘满（如 /u01 使用率 100%），ologgerd 会静默停止写入，不报错、不告警——此时你看到的“最新数据”其实是三天前的。务必在每次排查前执行：df -h /u01 和 du -sh /opt/oracle/chm/db/*/*.bdb | sort -hr | head -5，若发现某个 crfclust.bdb 超过 10G，大概率是 BUG 10165314 导致的异常膨胀，该文件已不可信，需清理后重置仓库大小。
