整点卡顿源于定时任务（如job或物化视图刷新）触发执行计划劣化，awr对比是唯一能锚定“时间+sql+执行计划”三重证据链的方法；需用dba_hist_snapshot查真实end_interval_time快照，前后延15分钟取区间，严格对比正常与异常整点的两份报告，重点分析top 5 timed events、sql executions及plan_hash_value变化。
整点卡顿不是时间本身有问题，而是某个在整点准时触发的任务正在拖垮数据库——AWR对比是唯一能锚定“时间+SQL+执行计划”三重证据链的方法。
确认整点是否存在AWR快照且时间对齐
很多人直接用sysdate查快照，结果发现整点没数据。AWR默认每小时生成一次快照，但实际时间点是end_interval_time，并非严格00:00:00，而是类似09:00:55、10:01:02这种带秒偏移的值。
- 必须用
dba_hist_snapshot查真实快照范围：select snap_id, to_char(end_interval_time,'YYYY-MM-DD HH24:MI:SS') from dba_hist_snapshot where end_interval_time >= to_date('2026-10-01 08:00','YYYY-MM-DD HH24:MI') and end_interval_time - 整点卡顿往往落在两个快照中间（比如09:00:00卡，但快照在08:59:58和09:59:57），所以建议取前后各延15分钟的区间，确保覆盖问题窗口
- RAC环境注意
instance_number不能混用，每个实例要单独查快照
生成并对比「正常整点」与「异常整点」两份AWR报告
单看一份报告会误判：可能某条SQL在“异常整点”执行了100次，在“正常整点”只执行了5次，但平均耗时一样——不对比就看不出频次突增。
- 选两个业务负载相似的整点窗口，例如：「09:00–10:00（卡顿）」vs「07:00–08:00（平稳）」，确保
DB Time、Transactions/s量级接近 - 重点比对
Top 5 Timed Events中等待事件的Total Wait Time和Waits次数：若log file sync等待总时长翻3倍，但次数只翻1.2倍，说明平均每次提交更慢，大概率是归档或IO子系统在整点被压垮 -
SQL ordered by CPU页要交叉看Executions列：某条物化视图刷新SQL在卡顿时执行了24次（每小时一次），但执行计划plan_hash_value变了，说明统计信息更新后优化器选错路径
盯住SQL Statistics里的三个危险信号
整点任务常以中等消耗、高频次方式出现，不会出现在“Elapsed Time Per Exec”榜首，但累积杀伤力极强。
-
Buffer Gets Per Exec> 50000：说明SQL没走索引，或谓词失效（如where trunc(create_time) = trunc(sysdate)） -
Parse To Execute Ratio≈ 1：硬解析占比过高，整点JOB反复执行未绑定变量的SQL，共享池压力陡增 -
Rows Processed Per Exec异常低（比如0.1）：SQL返回空结果集却仍全表扫描，可能是定时清理脚本逻辑缺陷
用dbms_xplan.display_awr验证执行计划漂移
AWR里看到SQL执行次数暴增，但不确定是不是执行计划变差导致的——必须查它在卡顿时的真实执行路径。
- 先从
DBA_HIST_SQLSTAT定位问题SQL的sql_id：select sql_id, plan_hash_value, executions_delta, buffer_gets_delta from dba_hist_sqlstat where snap_id between &start_snap and &end_snap and sql_id in (select sql_id from dba_hist_sqltext where sql_text like '%MV_REFRESH%') order by buffer_gets_delta desc;
- 再用
dbms_xplan.display_awr查该sql_id在卡顿时的执行计划：select * from table(dbms_xplan.display_awr('your_sql_id', null, null, 'ALL')); - 重点比对是否出现
TABLE ACCESS FULL或NESTED LOOPS驱动大表——这类计划在并发高时极易引发latch: cache buffers chains
整点卡顿最隐蔽的坑在于：它看起来像系统抖动，实则是某个JOB、物化视图刷新或定时SQL在固定时刻触发执行计划劣化。AWR对比不是比数字大小，而是比“谁在整点突然多干了什么”。漏掉executions_delta或plan_hash_value变化，就等于只看了病历没查CT片。
