Oracle 12c如何通过ASH诊断Log Writer进程瓶颈_分析LGWR后台进程等待-Oracle-PHP中文网

ash中准确定位lgwr会话应优先使用process_name = 'lgwr'（oracle 12c+）结合session_type = 'background'过滤，而非依赖program模糊匹配；其常见等待log file parallel write >10ms指向存储i/o瓶颈，而log file sync高发则需反查lgwr是否被阻塞。

怎么在ash里准确抓到lgwr的真实会话

ash本身不直接标记“lgwr进程”，v$active_session_history中lgwr的会话通常以program字段值为ora_lgwr_*、ora_lg00_*、ora_lg01_*等形式出现，但依赖program匹配不稳定——尤其在rac或多实例共享监听场景下，可能被覆盖或截断。更可靠的方式是结合process_name（oracle 12c+新增字段）和session_type过滤：

PROCESS_NAME = 'LGWR' 是最准标识，12c起该字段已稳定填充
SESSION_TYPE = 'BACKGROUND' 排除前台会话干扰
避免仅用PROGRAM LIKE '%lgwr%'，因ora_m000_*等MMON辅助进程也可能临时带类似字符串

执行示例（查最近30分钟）：

SELECT SAMPLE_TIME, EVENT, WAIT_CLASS, P1TEXT, P1, SESSION_STATE
FROM V$ACTIVE_SESSION_HISTORY 
WHERE PROCESS_NAME = 'LGWR' 
  AND SAMPLE_TIME > SYSDATE - 30/1440
ORDER BY SAMPLE_TIME DESC;

LGWR常见等待事件及对应瓶颈点

LGWR卡住时，ASH中高频出现的等待事件不是孤立现象，每种都指向特定资源层问题：

log file parallel write：最典型LGWR等待，说明LGWR正批量写入redo log文件。若平均等待时间>10ms，大概率是存储I/O响应慢（如ASM磁盘组跨物理盘、NFS挂载延迟高、redo日志文件碎片化）
log file sync：这不是LGWR自身的等待，而是用户进程在COMMIT后等待LGWR完成写入。ASH里看到大量log file sync且SESSION_STATE = 'WAITING'，需反查LGWR是否正被log file parallel write拖住
enq: SQ - contention：少见但关键，表示LGWR在争用序列号（Sequence#）生成锁，多见于高并发事务+未启用_use_single_log_writer = false时的SCALABLE LGWR竞争
db file sequential read（出现在LGWR会话中）：异常情况，说明LGWR被迫读取数据字典或控制文件块（如checkpoint信息异常），需检查control_file_record_keep_time或_log_write_precheck隐含参数是否被误调

如何区分是单LGWR还是SCALABLE LGWR瓶颈

Oracle 12.1+默认启用SCALABLE LGWR，但实际是否生效取决于_use_single_log_writer参数和CPU核数。光看进程名不够，得交叉验证ASH数据分布：

若PROCESS_NAME = 'LGWR'在ASH中占绝对主导（>95%的LGWR相关采样），且ora_lg00_*、ora_lg01_*等进程在ps中存在但ASH无采样，说明LGWR负载未真正分摊到子进程——可能是_max_outstanding_log_writes设得太小，或redo写压力未达触发阈值
若ASH中PROCESS_NAME IN ('LGWR', 'LG00', 'LG01')均有显著采样，且log file parallel write等待在多个进程间均匀分布，才是SCALABLE LGWR正常工作状态
注意：_use_single_log_writer = adaptive时，Oracle只在CPU核心数>1且系统负载>某个内部阈值时才启动多进程；空闲实例即使参数为adaptive，也只会跑单个ora_lgwr_*

确认当前配置：

Agent Git Oracle

高级仓库分析与重构指南。基于AI推理识别技术债务与架构反模式。

下载

SELECT a.ksppinm, b.ksppstvl 
FROM x$ksppi a, x$ksppcv b 
WHERE a.indx = b.indx 
  AND a.ksppinm IN ('_use_single_log_writer', '_max_outstanding_log_writes');