应通过MODULE LIKE 'LogMiner%'或ACTION LIKE '%extract%'并加SESSION_TYPE = 'background'过滤ASH数据，因OGG Extract真实资源消耗者是后台LogMiner会话，PROGRAM字段不稳定且常为空或为oracle@host (J000)等通用值。
goldengate extract进程本身不直连数据库，它背后的logminer会话才是真实资源消耗者——ash里查不到ogg$extract，但一定能抓到module like 'logminer%'或action like '%extract%'的后台会话。
为什么不能直接按PROGRAM过滤Extract进程
OGG Extract在DB中显示的PROGRAM可能是oracle@host (J000)、ora_j000_*甚至空值，尤其当LogMiner通过JOB启动时；真正稳定可依赖的是MODULE和ACTION字段。Oracle内部把LogMiner操作归类为模块级行为，而非进程名。
- 查
V$SESSION确认当前Extract关联会话：SELECT sid, serial#, program, module, action FROM v$session WHERE module LIKE 'LogMiner%' OR action LIKE '%extract%' - 必须加
session_type = 'background'条件，否则ASH默认只采样前台会话，后台LogMiner会话大概率被漏掉 - 如果用
PROGRAM LIKE '%extract%'查不到结果，不是没发生问题，而是匹配逻辑错了
重点盯这三类等待事件
LogMiner性能瓶颈最终落在I/O、字典读取和内存队列争用上，ASH里对应三个典型等待：
-
log file sequential read：Extract在读归档日志（尤其是跨ASM磁盘组、NFS挂载路径）时卡住，平均等待>20ms基本可判定存储吞吐不足 -
db file sequential read：LogMiner使用离线数据字典（DBMS_LOGMNR_D.BUILD导出到表空间），反复读字典块导致热块争用 -
enq: US - contention：LogMiner缓冲区满（由隐含参数_logminer_buffer_size控制），新日志无法入队，Extract被迫挂起；此时WAIT_CLASS = 'Configuration'且SESSION_STATE = 'WAITING'
如何关联ASH与实际解析的SCN范围
只看等待事件不够，得知道“慢”的那段时间LogMiner到底在解析哪段日志。关键字段是SQL_ID和CURRENT_OBJ#，但更直接的是从V$LOGMNR_CONTENTS反推（需提前开启日志挖掘）：
- 先用ASH锁定时间窗口：
SELECT MIN(sample_time), MAX(sample_time), COUNT(*) FROM v$active_session_history WHERE module LIKE 'LogMiner%' AND sample_time > SYSDATE - 1/24 - 再查该窗口内LogMiner实际处理的SCN区间：
SELECT MIN(scn), MAX(scn), COUNT(*) FROM v$logmnr_contents WHERE timestamp BETWEEN [start_time] AND [end_time]（注意：此视图需已执行DBMS_LOGMNR.START_LOGMNR） - 若
v$logmnr_contents为空，说明LogMiner尚未开始解析——问题可能出在日志定位阶段（如归档缺失、路径不可读）
容易忽略的采样陷阱
ASH数据不是“全量记录”，而是带权重的抽样。LogMiner这类长等待操作虽被高频捕获，但仍有两个硬限制：
- 内存缓冲区默认最多保留约1小时（
V$SGASTAT中name LIKE '%ASH buffers%'可查实际大小），超时即覆盖，别等第二天再查 - 后台进程采样率低于前台，必须显式加
session_type = 'background'，否则V$ACTIVE_SESSION_HISTORY里几乎看不到DBWR/LGWR/LogMiner -
enq: US - contention在V$ENQUEUE_STAT里无统计，得靠V$LOGMNR_SESSION和V$LOGMNR_PROCESS交叉验证缓冲区使用率
