awr报告默认不显示dbw0/lgwr等后台进程的sql执行轨迹，因ash硬编码过滤background会话，仅采集前台活动；后台负载需通过v$sys_time_model、v$system_event及dba_hist_system_event等视图分析等待事件和系统统计。
awr 报告默认不显示所有后台进程活动，这不是 bug，而是 oracle 11g 的设计限制：mmon 只采集前台会话（v$session 中 type = 'user'）的完整执行上下文，而后台进程（如 dbw0、lgwr、ckpt）的活动仅以聚合指标形式出现在等待事件、系统统计中，不会单独展开为“sql 执行轨迹”或“活跃会话堆栈”。
为什么 V$ACTIVE_SESSION_HISTORY 不包含 DBW0/LGWR 等后台进程的 ASH 记录
Oracle 11g 的 V$ACTIVE_SESSION_HISTORY 默认过滤掉后台进程（SESSION_TYPE = 'BACKGROUND'），这是硬编码行为，与 STATISTICS_LEVEL 设置无关。即使设为 ALL，ASH 仍只捕获前台会话的每秒采样；后台进程的内部调度、I/O 提交、检查点推进等动作不进入 ASH 队列。
- 验证方式：
SELECT COUNT(*) FROM v$active_session_history WHERE session_type = 'BACKGROUND';—— 在 11.2.0.3 及之前版本中几乎总是返回 0 - 后果：AWR 报告中的 “Top SQL”、“SQL ordered by Elapsed Time” 等节完全不体现
DBW0刷脏块、LGWR写日志的 CPU/IO 消耗，容易误判“CPU 空闲”而忽略后台瓶颈 - 替代视图：
V$SYS_TIME_MODEL和V$SYSTEM_EVENT中的background elapsed time、log file sync、db file parallel write等事件才是后台负载的真实入口
STATISTICS_LEVEL=ALL 也无法让 AWR 显示后台进程的 SQL 文本
设为 ALL 只影响前台 SQL 的文本捕获（填满 DBA_HIST_SQLTEXT），对后台进程无效——因为后台进程本身不执行用户 SQL，它们运行的是内核级 C 代码逻辑，没有 SQL_ID 或可解析语句。
-
DBA_HIST_SQLSTAT表里所有行都对应sql_id IS NOT NULL，而后台进程活动无此字段，自然不会被关联进 SQL 统计报表 - 试图在 AWR 报告中搜索 “DBW0” 或 “LGWR” 的 SQL 活动，结果必为空——不是漏采，是根本不存在这个维度
- 若需定位后台瓶颈，应聚焦：
DBA_HIST_SYSTEM_EVENT中后台相关事件的等待时间占比，以及DBA_HIST_OSSTAT中PHYSICAL_WRITE_BYTES_TOTAL等 I/O 总量指标
如何确认后台进程是否正在拖慢系统（但 AWR 报告不显）
当 AWR 报告显示 “DB Time log file sync 或 db file parallel write 占比异常高时，大概率是后台进程饱和，但报告不会告诉你哪个后台进程卡在哪儿。
- 实时诊断：
SELECT event, p1text, p1, p2text, p2, p3text, p3 FROM v$session_wait WHERE sid IN (SELECT sid FROM v$session WHERE type = 'BACKGROUND') AND state = 'WAITING'; - 历史趋势：查
DBA_HIST_SYSTEM_EVENT，用event LIKE 'log file%'或event LIKE 'db file%'过滤，观察等待时间随时间的变化曲线 - 关键陷阱：
DBA_HIST_WAITSTAT中的class = 'log buffer'或'buffer cache'高值，往往比单个等待事件更能暴露后台资源争用本质
真正难排查的，从来不是前台 SQL 跑得慢，而是后台进程在默默吞掉所有 I/O 带宽或日志写入能力——AWR 报告给你的是一张“前台视角地图”，而底层真实压力可能全在后台进程的无声运转中。盯着 Top SQL 往往找不到根因，必须切到系统级等待和 OS 层面的 I/O 吞吐验证。
