直接查v$active_session_history，加时间窗口和等待事件过滤可秒级定位批处理卡点；需用gv$视图查RAC、结合PROGRAM/MODULE/SESSION_STATE识别批处理会话；聚合分析要关注SQL_OPNAME、BLOCKING_SESSION及非SQL字段如EVENT和MODULE。
直接查 v$active_session_history，按时间窗口 + 等待事件 + 批处理特征过滤，就能定位到具体卡在哪类操作、哪个节点、哪条 SQL 上。 不需要等作业跑完，也不依赖 AWR 报告——ASH 是秒级采样，批处理刚变慢，数据就已落库。
查 v$active_session_history 时必须加时间窗口和等待事件过滤
批处理慢的本质是大量会话在某类资源上排队。不加条件直接查 ASH，等于在百万行里盲找；加对条件，30 秒内就能圈出热点。
- 时间窗口必须用
SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE（11g 推荐 5 分钟），不能用SYSDATE - 1/24——NLS 设置可能导致范围漂移，漏掉关键样本 - 等待事件要聚焦三类典型批处理瓶颈：
enq: TX - row lock contention（行锁链）、log file switch (checkpoint incomplete)（redo 切换卡住）、db file sequential read（索引扫描或回表猛刷） - RAC 环境下必须用
gv$active_session_history，否则只看到当前节点，而锁可能持在 node2，阻塞发生在 node1
识别批处理会话的两个可靠信号
批处理进程通常有固定命名模式，但仅靠 PROGRAM 字段不可靠（可能被覆盖或截断）。更稳的方式是结合行为特征反推：
- 查
PROGRAM LIKE '%DW%'或MODULE = 'DBMS_SCHEDULER'：Data Pump Worker 和 Scheduler Job 是 11g 批处理主力，匹配率超 85% - 看
SESSION_STATE = 'ON CPU'且持续多秒：说明不是等 I/O 或锁，而是 SQL 本身执行效率低（如全表扫描未走索引、PL/SQL 循环嵌套过深） - 若
SQL_ID为空但EVENT高频出现（如连续 10+ 秒采样到latch: shared pool），大概率是未绑定变量的动态 SQL 在硬解析
聚合分析时别只盯 SQL_ID，要关联 SQL_OPNAME 和 BLOCKING_SESSION
批处理慢常是连锁反应：一个 DML 持锁 → 多个 SELECT 等锁 → 全体会话堆积。只看 top SQL_id 会误判为“查询慢”，实际根因是上游事务没提交。
- 按
SQL_ID,SQL_OPNAME,EVENT三字段分组：INSERT和UPDATE的latch: shared pool等待比SELECT更危险，因为它们生成脏块、触发日志写、还可能带触发器 - 重点检查
BLOCKING_SESSION IS NOT NULL的样本：找出第一个非空的BLOCKING_SESSION，再查它当时的SQL_TEXT（通过v$session关联），往往就是那个没COMMIT的批处理语句 - 若发现多个会话阻塞在同一个
P1值（如P1TEXT = 'handle address'），大概率是CREATE OR REPLACE PACKAGE类 DDL 卡住 library cache lock，而非 SQL 执行慢
容易被忽略的底层干扰点
有些“慢”根本不在 SQL 层，ASH 能暴露但需要交叉验证：
-
free buffer waits频次突增：不是存储慢，是 DBWR 写不过来。查v$iostat_file中对应数据文件的AVG_WRITE_TIME是否同步飙升；没涨，说明 I/O 请求压在 Oracle 层，不是磁盘问题 -
gc cr grant 2-way在 RAC 中高频出现：说明跨节点一致性读频繁，可能是批处理没走本地分区，或 sequence 缓存太小导致反复申请 -
library cache pin和library cache lock同时出现：大概率是某个包正在重编译，其他会话全被堵住——这时SQL_ID可能为空，得靠SESSION_ID去v$session查真实SQL_TEXT
真正卡点往往藏在“非 SQL”字段里：PROGRAM 显示 oracle@host (J000) 但 EVENT 是 rdbms ipc message，说明是 job queue 进程被调度压制；MODULE 是 DBMS_SQL 但 SQL_OPNAME 为空，基本可断定是动态 SQL 解析阶段卡死。这些细节不翻原始 ASH 行，光看报告根本看不到。
