AWR是唯一能锚定“时间+SQL+执行计划”三重证据链的工具，需用dba_hist_snapshot查快照范围，确认end_interval_time存在；生成HTML报告时DBID、INST_NUM、START_SNAP_ID、END_SNAP_ID顺序和取值必须准确；重点分析SQL ordered by CPU与Gets页，比对plan_hash_value变化，并排查物化视图刷新及JOB定时任务。
oracle cpu 使用率不稳，大概率不是系统抖动，而是某个 sql 在特定时段反复触发执行计划偏移或物化视图刷新——awr 是唯一能锚定“时间+sql+执行计划”三重证据链的工具。
查 AWR 快照范围必须用 dba_hist_snapshot 而非当前时间
很多人直接用 sysdate 去查快照，结果找不到数据。AWR 默认只保留 8 天（可调），且快照是按固定间隔（如每小时 1 次）生成的，不是实时写入。必须先确认问题发生时段是否存在快照：
- 执行
select snap_id, dbid, instance_number, to_char(end_interval_time,'YYYY-MM-DD HH24:MI:SS') from dba_hist_snapshot where end_interval_time between to_date('2026-04-15 09:00','YYYY-MM-DD HH24:MI') and to_date('2026-04-15 10:00','YYYY-MM-DD HH24:MI') order by end_interval_time; - 若返回空，说明该时段没采集快照，要么延长保留期（
dbms_workload_repository.modify_snapshot_settings），要么换用 ASH（v$active_session_history）临时补位 - 注意：快照时间是
end_interval_time，不是开始时间；CPU 波峰通常落在两个快照中间，所以建议取前后各延 15 分钟的区间
用 awr_report_html 提取报告时 DBID 和 SNAP_ID 不能错位
常见错误是把 INSTANCE_NUMBER 当成 DBID，或把 START_SNAP_ID 和 END_SNAP_ID 填反，导致报错 ORA-13516: AWR operation error: invalid snapshot range：
- DBID 来自
select dbid from v$database;，不是instance_number；后者是实例编号（RAC 环境才 >1） - START_SNAP_ID 必须小于 END_SNAP_ID，且两者差值不宜超过 100（否则 HTML 报告过大，浏览器打不开）
- 推荐命令：
select output from table(dbms_workload_repository.awr_report_html(&dbid, &inst_num, &start_snap, &end_snap));，参数顺序不可交换 - 输出是 CLOB，复制时务必全选——漏掉末尾几行会导致 HTML 格式损坏，打开空白
在 AWR 报告里盯住 SQL ordered by CPU 和 SQL ordered by Gets 两页
CPU 不稳往往不是单条慢 SQL，而是多条中等消耗 SQL 叠加，或某条 SQL 执行计划突变。光看“Top SQL”不够，要交叉比对：
-
SQL ordered by CPU页列出的是该时段内累计 CPU 时间最高的 SQL，适合定位“真凶” -
SQL ordered by Gets页列出逻辑读最高的 SQL，很多执行计划偏移（比如索引失效走全表扫描）不会立刻拉高 CPU，但会大幅增加 buffer gets，继而推高 CPU 后续处理压力 - 重点看同一
sql_id在不同快照中是否出现多个plan_hash_value；若有，说明执行计划不稳定，需进一步用dbms_xplan.display_awr对比两个计划 - 别忽略
PL/SQL Execution类型的高 CPU 占用——这往往是存储过程内循环或隐式类型转换导致，不在 SQL 文本里显式体现
物化视图刷新和 JOB 是 CPU 波动最隐蔽的定时源
AWR 报告底部的 Instance Activity Stats 里，如果 materialized view refreshes 或 job queue processes 计数突增，基本可以锁定：
- 查物化视图刷新日志：
select * from dba_mview_refresh_times where last_refresh = sysdate - 1/24; - 查调度任务：
select job_name, state, last_start_date, next_run_date from dba_scheduler_jobs where state = 'RUNNING' or next_run_date between sysdate - 1/24 and sysdate + 1/24; - 特别注意
ON COMMIT或FAST刷新模式的物化视图——它们可能在业务高峰期被频繁触发，且刷新 SQL 很难从会话中直接捕获，只能靠 AWR 时间戳对齐 - 一个典型坑：物化视图定义里用了
SYSDATE或USER等非确定性函数，导致每次刷新都重解析，CPU 持续飙高
AWR 不是万能的，但它是最接近“回放现场”的工具；真正难的不是生成报告，而是把报告里的 sql_id、plan_hash_value、snapshot_time 和操作系统层的 top -p 输出 PID 对上——这个时间差哪怕只有 3 秒，就可能错过关键线索。
