CHM数据导出前必须启用autocollect并使用UTC时间：先确认crsctl config crs含autostart启用，再检查ora.chm在线、crsctl get css autocollect返回TRUE；chmcli时间参数须为UTC且精确到分钟（如"2024-05-20 07:00:00"），导出CSV无表头需按固定字段顺序解析，数据默认仅保留3天。
CHM数据导出前必须确认crsctl是否启用autocollect
chm（cluster health monitor）默认不自动采集历史资源数据，很多用户导出为空或只有最近几分钟数据，根本原因是crsctl没开启自动收集。rac节点上运行crsctl check cluster -all只能验证集群状态，不能反映chm是否在干活。
实操建议：
- 先执行
crsctl config crs，确认输出含CRS-4622: Oracle High Availability Services autostart is enabled.——这是基础前提 - 再查CHM状态：
crsctl stat res -t | grep -i "ora.chm"，若显示OFFLINE，需手动启动：crsctl start resource ora.chm - 最关键一步：确认自动采集已开：
crsctl get css autocollect，返回AUTO_COLLECT=TRUE才算真正就绪；若为FALSE，必须执行crsctl set css autocollect true并重启CSSD（crsctl stop crs && crsctl start crs）
用chmcli导出时时间范围必须用UTC且精度到分钟
CHM内部所有时间戳都存为UTC，但chmcli命令不校验时区，直接填本地时间会导致查不到数据，比如上海时间下午3点对应UTC上午7点，填错就导出空结果。
常见错误现象：
-
chmcli -collect -s "2024-05-20 15:00:00" -e "2024-05-20 16:00:00"→ 返回No data found - 即使加
-n all也无效，因为时间根本对不上
实操建议：
- 先用
date -u查当前UTC时间，再换算目标时段；例如本地15:00 → UTC 07:00，应写"2024-05-20 07:00:00" - 起止时间必须精确到分钟，秒级会被截断，且不能省略前导零（
"2024-05-20 7:00:00"会报错） - 推荐组合命令快速换算：
date -d "2024-05-20 15:00:00 CST" -u +"%Y-%m-%d %H:%M:%S"
chmcli -export生成的CSV字段顺序固定但无表头，解析易出错
导出文件是纯CSV，没有列名，字段顺序硬编码为：timestamp,node,cpu%,mem%,swp%,io_wait%,load_avg，但不同版本Oracle CHM字段数可能变化（如12.2+新增disk_read_kb/s），靠经验硬解析风险高。
使用场景：
- 用Python pandas读取时，必须显式指定
names=...参数，不能依赖header=0 - 用awk处理单节点数据时，
$2 == "racnode1"比用列号更可靠（节点名比位置稳定）
实操建议：
- 先导出一行测试：
chmcli -export -s "2024-05-20 07:00:00" -e "2024-05-20 07:01:00" | head -1，确认字段数和含义 - 生产脚本中避免直接
cut -d, -f3取CPU，改用awk -F, '$2=="racnode1"{print $3}' - 注意timestamp字段带毫秒（如
2024-05-20T07:00:00.123Z），部分工具无法直接解析，建议先用sed 's/\.[0-9]\+Z/Z/'截断
CHM数据默认只保留3天，超期数据不可恢复
CHM不是归档系统，ora.chm资源背后是内存+小文件缓存机制，默认保留窗口就是72小时，过期数据从内存刷出后即丢弃，chmcli查不到就是真没了。
性能与兼容性影响：
- 调大保留时间（如设为7天）需改CSSD配置：
crsctl set css chm_retention 7，但会增加节点内存压力，尤其在24核以上RAC中明显 - 11.2.0.4及更早版本不支持该参数，强行设置会报
CRS-4001: Invalid parameter - 19c开始CHM被
OSWatcher和ADRCI部分替代，但RAC实时诊断仍强依赖CHM原始粒度
容易被忽略的地方：CHM数据导出本身不触发归档，也不写入$GRID_HOME/log，所有操作痕迹只留在chmcli命令行历史里。如果没定期导出，故障复盘时连“当时有没有高负载”都难确认。
