CHM是AWR的补充，每秒采集OS和集群层指标以捕获瞬时抖动；需验证仓库存在、oclmmon ONLINE及磁盘空间，并用chmca提取秒级CPU/内存/IO峰值数据。
CHM（Cluster Health Monitor）不是AWR的替代品，而是它的补充——它每秒采集OS和集群层指标，能抓到AWR快照间隙里消失的瞬时抖动。如果你在AWR里只看到“DB Time偶尔跳高”，但用户坚称“那几秒卡得像死机”，CHM就是唯一能定位到具体秒级资源尖峰的工具。
确认CHM是否已启用并正常采集
CHM默认随Grid Infrastructure安装启用，但常被误关或磁盘满导致停采。别信“应该开着”，直接查：
- 运行
oclumon manage -get repsize：输出类似Current repository size: 32768 MB表示仓库存在；若报错OCM-00012: Repository not found，说明CHM根本没启 - 检查采集状态：
crsctl stat res -t | grep oclumon，状态必须是ONLINE，且对应节点名不为空 - 验证最近数据：
diagcollection.pl -collect -chm -duration 5（采集最近5分钟），若生成空zip或报No data found for the specified duration，大概率是磁盘空间不足（/opt/oracle/chm或+GRID_CHMASM磁盘组满）
用chmca提取秒级CPU/内存/IO尖峰数据
CHM原始数据是二进制，chmca 是唯一官方解析工具。重点不是看“平均值”，而是找“单点峰值”：
- 导出节点1过去10分钟所有指标：
chmca -d /opt/oracle/chm -s "2026-08-27 07:40:00" -e "2026-08-27 07:50:00" -n p19c01 -o chm_p19c01.csv - 打开CSV，重点关注三列：
timestamp、metric_name、value；筛选metric_name为os_cpu_utilization、os_mem_used_percent、os_io_wait_time - 排序
value列，找前10高值——例如某秒os_cpu_utilization=98.2，而前后秒均os_io_wait_time 是否同步飙升，可判断是CPU瓶颈还是IO卡顿
关联CHM与AWR定位跨层根因
CHM告诉你“哪一秒OS崩了”，AWR告诉你“那一秒数据库在干什么”。两者时间戳必须对齐（注意CHM用UTC、AWR用数据库时区）：
- 从CHM找到抖动时刻（如
2026-08-27 07:42:15），转换为数据库时区时间（如CST即+8），得到AWR快照号范围（假设该秒落在快照#1234→#1235之间） - 查AWR报告中
Top 5 Timed Foreground Events：若此时enq: TX - row lock contention占比突增，再结合CHM发现同一秒os_cpu_utilization并未拉满，说明是锁争用而非CPU打满 - 更关键的是查
SQL ordered by Elapsed Time：找出该快照内执行时间集中在07:42:10–07:42:20的SQL，用DBA_HIST_ACTIVE_SESS_HISTORY下钻，确认是否某条SQL在CHM记录的尖峰时刻正在做大量逻辑读或等待
CHM数据易被忽略的陷阱
CHM不是万能的，它的盲区恰恰是抖动分析中最容易踩坑的地方：
- CHM不采集Oracle内部等待事件（如
db file sequential read），只管OS层；所以看到CPU低但业务卡，别急着查CHM，先看AWR的DB Time vs DB CPU比值 - CHM默认只存7天（
oclumon manage -get retention可查），超期自动清理；若抖动发生在3天前，而今天才想起查，数据早已丢失 - RAC下CHM数据按节点隔离，
chmca导出时必须指定-n节点名；漏掉一个节点，就可能错过真正出问题的实例（比如只有p19c02在抖，但你只查了p19c01）
