CHM依赖MGMTDB，若ora.mgmtdb状态为OFFLINE或srvctl status mgmtdb报“MGMTDB is not running”，则CHM停止采集，历史性能数据中断；需先检查crsctl stat res -t | grep mgmt及ora.crf状态，再确认+MGMT磁盘组空间。
CHM（Cluster Health Monitor）是 Oracle 19c RAC 中唯一能提供秒级节点级历史性能数据的内置工具，但它的价值只有在系统挂起后回溯时才真正显现——前提是它没坏、数据没断、采集没被静默停掉。
CHM 数据是否可用，先看 crsctl stat res -t 和 srvctl status mgmtdb
挂起发生后第一件事不是翻 AWR 或查 alert，而是确认 CHM 是否还在工作。如果 ora.mgmtdb 资源状态是 OFFLINE 或 UNKNOWN，或者 srvctl status mgmtdb 报 “MGMTDB is not running”，那所有后续分析都失去时间锚点。
- CHM 依赖 MGMTDB（即 GIMR 数据库），它一挂，CHM 就停止写入，历史曲线从那一刻起变为空白
-
crsctl stat res -t | grep mgmt可快速定位资源状态；若显示INTERMEDIATE，说明数据库启动失败但 CRS 还在尝试拉起 - 别信
crsctl check cluster -all的“online”结果——它只检查 CRS 进程存活，不校验 CHM 数据链路
用 oclumon 提取节点级秒级指标，重点盯 cpu, memory, io_wait, network_in, network_out
oclumon 是 CHM 的原生查询工具，比 SQL 访问 gv$osstat 更直接、更及时，且不依赖数据库实例是否在线（只要 MGMTDB 活着）。
- 提取最近 2 小时数据：
oclumon dumpnodeview -all -v -s "2026-10-25 14:00:00" -e "2026-10-25 16:00:00"，输出是二进制，需用chmos解析或转 CSV - 最有效的排查路径：先看
cpu_busy_pct是否持续 >95%，再交叉比对io_wait_pct和memory_free_mb—— 若三者同时飙升，大概率是底层存储卡死或 ASM 磁盘组 offline - 私网流量异常（
network_in突增 10 倍以上）往往对应脑裂前兆或 GCS/GES 消息风暴，此时cssd日志里会出现大量 “missed heartbeat”
CHM 数据中断 ≠ CHM 挂了，也可能是 ora.crf 资源被手动 stop 或磁盘组空间不足
常见误判是看到 CHM 图表空白就去重建 MGMTDB，其实很多情况只是采集代理（CRF）停了，或 +MGMT 磁盘组快满了。
- 查 CRF 状态：
crsctl stat res ora.crf -p，若STATE是OFFLINE，执行crsctl start res ora.crf即可恢复采集（无需重启 MGMTDB） - 查 +MGMT 空间：
asmcmd lsdg MGMTDG，若free_mb - 注意：CHM 默认保留 3 天数据，但若磁盘组连续 2 小时 free_mb
CHM 分析真正的难点不在工具使用，而在于时间窗口对齐：你得把应用层报错时间、CRS 日志中第一个 “missed heartbeat” 时间、CSSD trace 中 “IPC timeout” 时间，和 CHM 里 cpu/io 异常拐点严格对齐到秒级，差 30 秒就可能误判为两个独立事件。
