ASH不监控后台进程，仅采样活动会话；后台进程默认等待空闲事件，故不出现在v$active_session_history中；需通过v$session、v$process及v$session_wait组合查询其真实等待状态。
直接结论：ash 本身不监控后台进程（如 ora_pmon、ora_dbw0），它只采样“活动会话”——而 oracle 后台进程默认不计入活动会话，除非它们显式进入非空闲等待事件且被 v$session 视为 session。真正能定位后台进程异常等待的，是 v$session_wait 和 v$process 的组合查询，不是 v$active_session_history。
为什么 v$active_session_history 查不到 ora_pmon 等后台进程？
ASH 的设计目标非常明确：只记录“活动会话”（Active Session），即满足两个条件之一的会话：
– 正在 CPU 上执行（state = 'ON CPU'）；
– 正在等待一个**非空闲等待事件**（non-idle event，如 db file sequential read、enq: TX - row lock contention）。
而绝大多数后台进程（ora_pmon、ora_mmon、ora_mmnl 等）在空闲时等待的是 PMON timer、MMNL sleep 这类空闲事件（idle event），这些根本不会被 ASH 采样。
即使它们偶尔卡住，只要没进入非空闲等待，就不会出现在 v$active_session_history 中。
怎样真正监控 ora_pmon / ora_dbw0 等后台进程的等待？
必须绕过 ASH，直查底层会话与进程状态：
- 用
v$process找出后台进程的pid和spid（操作系统 PID）：SELECT pid, spid, program FROM v$process WHERE program LIKE 'ora_%';
- 关联
v$session获取其当前会话状态（注意：后台进程也有 session 记录，type = 'BACKGROUND'）：SELECT s.sid, s.serial#, s.state, s.event, s.wait_time_micro, p.program FROM v$session s JOIN v$process p ON s.paddr = p.addr WHERE s.type = 'BACKGROUND' AND p.program LIKE 'ora_pmon%';
- 重点看
event和wait_time_micro：如果event是非空闲事件（比如latch: shared pool、library cache lock），且wait_time_micro持续增长，说明该后台进程已被阻塞。 - 补充检查
v$session_wait_history（每个会话最近 10 次等待）：SELECT event, wait_time_micro, p1text, p1 FROM v$session_wait_history WHERE sid = &sid;
什么情况下后台进程会意外出现在 ASH 中？
极少数但关键的场景，确实会让后台进程“漏进”v$active_session_history：
-
ora_dbw0在写脏块时遭遇 I/O 延迟，等待db file parallel write（这是非空闲事件）； -
ora_lgwr因归档日志满或磁盘慢，卡在log file sync或log file parallel write； -
ora_pmon在清理异常会话时，被长时间持有锁阻塞，等待enq: TX - row lock contention； - 所有这类情况都意味着数据库已处于严重异常状态——不是“监控需求”，而是“故障征兆”。此时
v$active_session_history里能看到它们，但数据量极少、持续时间短，靠手工查容易遗漏。
更可靠的后台进程健康检查方案
不要依赖 ASH 报告（@?/rdbms/admin/ashrpt.sql）诊断后台进程问题。应构建轻量级巡检脚本，每 5 分钟执行一次：
- 检查关键后台进程是否存活：
ps -ef | grep ora_pmon | grep -v grep； - 检查它们的等待事件是否异常：
SELECT program, event, seconds_in_wait FROM v$session WHERE type='BACKGROUND' AND state='WAITING' AND wait_class != 'Idle';； - 结合
v$system_event看全局后台进程等待占比：SELECT event, total_waits, time_waited FROM v$system_event WHERE event LIKE 'latch%' OR event LIKE 'enq:%' ORDER BY time_waited DESC;； - 对
ora_dbw0和ora_lgwr，额外关注 I/O 相关指标：v$sysstat中physical writes与log buffer space是否突增。
ASH 是为前台业务会话设计的“高分辨率显微镜”，不是后台进程的“心电监护仪”。真要盯住 ora_pmon 是否心跳正常，得靠 v$session + v$process + OS 层联动，而不是等它偶然出现在 ASH 里。
