首页 > 数据库 >如何通过AWR分析业务低谷期_利用夜间快照评估批处理作业耗时

如何通过AWR分析业务低谷期_利用夜间快照评估批处理作业耗时

来源：互联网 2026-04-19 14:44:05

夜间批处理作业在AWR报告中消失？检查DBA_HIST_ACTIVE_SESS_HISTORY采样覆盖许多DBA都曾遇到类似情况：凌晨运行的批处理任务明明负载很高，但事后查看AWR报告时，相关的会话和SQL却难以找到。这通常是由于采样粒度不匹配造成的。AWR默认每60分钟采集一次快照，而许多批处理

夜间批处理作业在AWR报告中消失？检查DBA_HIST_ACTIVE_SESS_HISTORY采样覆盖

许多DBA都曾遇到类似情况：凌晨运行的批处理任务明明负载很高，但事后查看AWR报告时，相关的会话和SQL却难以找到。这通常是由于采样粒度不匹配造成的。AWR默认每60分钟采集一次快照，而许多批处理作业恰恰集中在凌晨2点到4点这样的短暂窗口期内运行。如果某个作业执行时间很短，例如仅8分钟，且其运行时段恰好未落在任何一次快照的起止时间点上，那么它在AWR报告中就很可能无法被体现。这并非数据丢失，而是采样频率未能捕捉到作业的执行节奏。

遇到此类问题，可以按照以下步骤进行排查：

长期稳定更新的攒劲资源： >>>点此立即查看<<<

首先，查询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权限），例如调整为15分钟一次：EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(interval => 15);。但需注意，此调整仅对后续快照生效，并且会增加AWR存储空间的占用。
更常规可靠的做法，是直接查询DBA_HIST_ACTIVE_SESS_HISTORY。其采样粒度更细，默认每秒捕获一次活跃会话信息（通常保留30分钟，可配置延长），是回溯短时作业的有效工具。

如何从AWR报告中快速定位耗时最长的批处理SQL？

不必在AWR报告数十页的“SQL Statistics”表格中进行大海捞针式的查找。该部分通常按总执行时间、逻辑读或执行次数排序。而真正影响业务的关键SQL，往往是那些执行次数极少（可能仅一次）、但单次运行就耗时几十分钟的语句。这类SQL在按总量排序的榜单中，很难进入前列。

要精准定位，需要转换思路：

生成AWR报告时，在“Report Level”处选择Typical或ALL级别，确保报告包含Top SQL with Top Events这一关键部分。
重点关注“Elapsed Time per Exec (s)”这一列，而非仅仅查看“Elapsed Time (s)”的总和。任何单次执行时间超过10秒的SQL都值得深入分析。

也可以直接查询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在快照区间内未执行完成或被取消。此时，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，再寻找计划。
从长远来看，一个治本的方案是在批处理脚本的关键SQL语句前添加/*+ MONITOR */提示。此提示会强制Oracle将该SQL的执行详情记录到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（即真实流逝的墙钟时间）。如果DB Time远小于Elapsed Time，则说明有大量时间消耗在数据库之外，例如网络传输、应用层逻辑处理或调用外部API——这些是AWR无法监控的盲区。
最后，不要忽略资源管理器的影响。夜间批处理常受到Resource Manager策略的限制。检查DBA_RSRC_CONSUMER_GROUP_PRIVS以及当前会话的resource_consumer_group值，确认作业没有因资源配额不足而处于排队等待状态。