夜间快照看不到批处理作业是因为AWR默认60分钟采样，若短时作业未覆盖快照窗口则“隐身”；应查DBA_HIST_SNAPSHOT确认快照存在，或用粒度更细的DBA_HIST_ACTIVE_SESS_HISTORY回溯。
夜间快照里看不到批处理作业？先确认 DBA_HIST_ACTIVE_SESS_HISTORY 采样是否覆盖到作业窗口
awr 默认每 60 分钟打一个快照，但批处理常在凌晨 2–4 点密集运行，如果作业执行时间短（比如 8 分钟），又没落在快照起止边界内，它就直接“隐身”了。这不是数据丢了，是采样粒度没对上。
实操建议：
- 查
DBA_HIST_SNAPSHOT，确认你关注的时间段内是否有快照：SELECT snap_id, begin_interval_time, end_interval_time FROM DBA_HIST_SNAPSHOT WHERE begin_interval_time >= DATE '2024-04-10' AND end_interval_time <= DATE '2024-04-11' ORDER BY snap_id;
- 若快照间隔太大，临时调高采样频率（需 DBA 权限）：
EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(interval => 15);—— 注意：只对后续快照生效，且增加 AWR 存储压力 - 更靠谱的做法：用
DBA_HIST_ACTIVE_SESS_HISTORY回溯，它每秒捕获一次活跃会话（默认保留 30 分钟，可延长），比快照细得多
怎么从 AWR 报告里快速定位耗时最长的批处理 SQL？
别翻“SQL Statistics”大表——那里按执行次数或逻辑读排序，和“单次耗时长”不是一回事。真正卡住业务的，往往是某条 SQL 执行一次就花了 20 分钟，但它只跑了一次，排不到前 10。
实操建议：
- 生成 AWR 报告时，在“Report Level”选
Typical或ALL，确保包含Top SQL with Top Events部分 - 重点看 “Elapsed Time per Exec (s)” 列，而不是 “Elapsed Time (s)” 总和；值大于 10 秒的值得点开
- 用
DBA_HIST_SQLSTAT手动过滤：SELECT sql_id, elapsed_time_delta/decode(executions_delta,0,1,executions_delta)/1000000 elap_per_exec FROM DBA_HIST_SQLSTAT WHERE snap_id BETWEEN 12345 AND 12346 AND executions_delta > 0 ORDER BY elap_per_exec DESC FETCH FIRST 5 ROWS ONLY;
- 注意：
executions_delta = 0表示该 SQL 在这个区间没执行完，或被 cancel，此时elapsed_time_delta是累计等待+执行时间，不能直接除
为什么 DBA_HIST_SQL_PLAN 里找不到批处理 SQL 的执行计划？
AWR 不保存所有 SQL 的完整执行计划，只存那些被认定为“高负载”的语句（由内部阈值控制），或者在生成 AWR 报告时被显式抓取的。很多批处理用的是绑定变量+动态拼接，SQL_ID 频繁变化，系统根本没把它当“重点监控对象”。
实操建议：
- 作业运行时，立刻查
V$SQL_PLAN（非历史视图），它反映当前库缓存中的真实计划：SELECT * FROM V$SQL_PLAN WHERE sql_id = 'abc123xyz';
- 若已结束，且没开
FORCE_MATCHING_SIGNATURE，试试用DBA_HIST_SQLTEXT模糊匹配原始 SQL 片段，再反推可能的sql_id - 长期方案：在批处理脚本开头加
/*+ MONITOR */提示，让 Oracle 强制记录其执行计划到V$SQL_MONITOR和 AWR 中 - 注意：
DBA_HIST_SQL_PLAN的plan_hash_value和V$SQL_PLAN的不完全等价——前者可能被截断或归一化
评估批处理耗时，只看 AWR 里的 DB Time 和 DB CPU 就够了吗？
不够。尤其夜间低谷期，DB Time 高可能只是因为 I/O 等待（db file sequential read）或锁等待（enq: TX - row lock contention），而这些在 AWR 汇总页里被揉进“Other”或“Background”里，一眼看不出瓶颈在哪。
实操建议：
- 必须打开 AWR 报告的 “Wait Events” 部分，重点关注
Top 5 Timed Foreground Events，排序依据是% DB Time，不是绝对毫秒数 - 若看到大量
direct path read，说明批处理在做全表扫描+并行加载，得查是不是缺少索引或统计信息过期 - 对比两个相邻快照的
DB Time差值 和Elapsed Time（即真实耗时），如果前者远小于后者，说明大量时间花在非数据库环节（网络、应用层解析、外部 API 调用）——AWR 看不见这些 - 夜间批处理常受
Resource Manager限制，检查DBA_RSRC_CONSUMER_GROUP_PRIVS和当前会话的resource_consumer_group值
批处理不是单点问题，它是 SQL + 计划 + 等待事件 + 资源配额 + 外部依赖的叠加态。AWR 快照只是切片，切歪了就什么都看不到。
