可直接通过v$active_session_history中session_type='BACKGROUND'且program LIKE '%j00%'识别Scheduler Job真实会话，其中J00x进程反映实际执行状态，而ora_cjq0仅负责调度；若ASH无记录，需检查dba_scheduler_running_jobs、资源窗口及job_queue_processes等外部因素。
直接看 v$active_session_history 里的 session_type 和 program，就能区分 scheduler job 会话，不用靠猜。
如何从 ASH 中识别 Scheduler Job 的真实会话
Oracle 12c 的 Scheduler Job 执行时，会在 v$active_session_history（ASH）中留下记录，但默认不带 job 名称。关键在于两个字段：session_type 必须是 BACKGROUND，且 program 包含 ora_cjq0 或 ora_j00 —— 前者是协调进程（CJQ0），后者是 job slave 进程（J00x）。真正干活的是 J00x 进程，它的 sql_id、event、p1text 才反映 job 实际卡在哪。
-
ora_cjq0进程只负责分发，几乎不消耗资源，ASH 中通常只有极短的“ON CPU”或“scheduler monitor”等待，忽略它 - J00x 进程的
client_id字段在 12c 中常为空，不能依赖；但module字段有时会填入 job 名（如DBMS_SCHEDULER），action可能为空或含部分 job_name - 最稳的识别方式：查
sql_id对应的sql_text，如果开头是call DBMS_SCHEDULER.RUN_JOB或调用你定义的存储过程名，基本可确认
为什么 job 看似“卡住”，ASH 却没看到对应会话
常见于 job 处于“已触发但未真正执行”的状态，比如被资源管理窗口阻塞、或卡在排队队列里——此时还没派生 J00x 进程，ASH 自然无记录。这时要查 dba_scheduler_running_jobs 是否为空，再结合 dba_scheduler_job_log 的 status = 'RUNNING' 但无后续日志，大概率是资源争用或窗口关闭导致“假运行”。
- 检查当前打开的资源管理窗口：
SELECT window_name, enabled, active FROM dba_scheduler_windows WHERE active = 'TRUE' - 确认 job 所属 job_class 是否绑定了无效 service：
SELECT job_class, service FROM dba_scheduler_jobs WHERE job_name = 'YOUR_JOB'，再查dba_rsrc_consumer_groups或gv$active_services - 若
job_queue_processes被设为 0 或极低，CJQ0 不启动，所有 job 都不会进入 ASH —— 此时v$process里根本看不到ora_cjq0
查 ASH 时必须加的过滤条件和易错点
直接 SELECT * FROM v$active_session_history 容易淹没在海量后台会话中。必须限定时间范围 + 进程类型 + 等待事件，否则白忙。
- 时间范围别用
sample_time > SYSDATE - 1/24这种模糊写法，ASH 默认只保留 1 小时（受_ash_sampling_interval和内存限制），应优先用sample_time BETWEEN ... AND ...显式指定 - 过滤
program LIKE '%j00%'比program LIKE '%ora_j%'更准，避免误抓ora_q00或ora_p00 - 别漏掉
session_state = 'WAITING'，很多慢 job 卡在enq: TX - row lock contention或db file sequential read，这些在session_state = 'ON CPU'下看不到 - 注意 12c 多租户环境：ASH 视图默认只返回 CDB$ROOT 数据，查 PDB job 必须先
ALTER SESSION SET CONTAINER = your_pdb，或用cdb_active_session_history并过滤con_id
真正难的不是找到 job 会话，而是确认它“该出现却没出现”——这时候得跳出 ASH，去看 dba_scheduler_window_details 的 last_start_date 和 duration，或者 gv$resource_limit 里 jobs 的 current_utilization 是否已达上限。这些地方不动手查，光刷 ASH 永远找不到空档。
