log file sync 等待的 p2（Sync SCN）集中且 wait_time_milli 在 8–15ms，叠加 LGWR 的 log file parallel write 耗时相近，可判定为存储 I/O 瓶颈。
查 ASH 中 log file sync 的等待参数是否指向 I/O
log file sync 等待本身不直接暴露磁盘延迟，但它的 wait_time_milli 和关联的 session_id、blocking_session 能帮你判断瓶颈在哪。关键看两个参数：p1（Buffer#）和 p2（Sync SCN）——如果大量会话的 p2 值高度集中、且 wait_time_milli 普遍在 8–15ms 区间，大概率不是 CPU 或 latch 争用，而是 LGWR 写盘卡在某一批次。
执行以下查询快速筛出典型样本：
SELECT sample_time, session_id, sql_id, event, p1, p2, wait_time_milli FROM v$active_session_history WHERE event = 'log file sync' AND sample_time > SYSDATE - 1/24 ORDER BY wait_time_milli DESC FETCH FIRST 10 ROWS ONLY;
若发现多个会话的 p2（Sync SCN）相同或连续，说明它们被同一次 LGWR 写操作阻塞，这是 I/O 同步瓶颈的强信号。
关联 LGWR 进程的 ASH 记录看真实写入耗时
单纯看前台等 log file sync 不够，必须找到对应时刻的 LGWR 进程行为。LGWR 的会话类型是 BACKGROUND，程序名通常是 LGWR，它在写盘时会触发 log file parallel write 等待。
用如下语句把前台等待和后台写入串起来：
SELECT a.sample_time, a.session_id, a.event, a.wait_time_milli,
b.session_id lgwr_sid, b.event lgwr_event, b.wait_time_milli lgwr_wait
FROM v$active_session_history a
JOIN v$active_session_history b
ON b.sample_time BETWEEN a.sample_time - INTERVAL '1' SECOND
AND a.sample_time + INTERVAL '1' SECOND
WHERE a.event = 'log file sync'
AND b.program = 'LGWR'
AND b.event = 'log file parallel write'
AND a.sample_time > SYSDATE - 1/48
ORDER BY a.sample_time DESC
FETCH FIRST 5 ROWS ONLY;- 如果
a.wait_time_milli和b.wait_time_milli数值接近（比如都落在 10±2ms），基本锁定是存储 I/O 慢 - 如果
a.wait_time_milli高（如 20ms+）但b.wait_time_milli很低（ -
b.wait_time_milli在 ASH 中为 0 表示未捕获到等待，需配合v$event_histogram查直方图
用 ASH 时间分布验证 I/O 延迟是否离散化
平均等待时间容易掩盖毛刺。I/O 卡顿往往表现为偶发长延时，比如 90% 的 log file sync 是 3ms，但 5% 是 32ms+——这在 ASH 中能直观看到。
运行这个聚合查询看延迟分布：
SELECT
CASE
WHEN wait_time_milli < 1 THEN '<1ms'
WHEN wait_time_milli < 4 THEN '1-3ms'
WHEN wait_time_milli < 8 THEN '4-7ms'
WHEN wait_time_milli < 16 THEN '8-15ms'
ELSE '>=16ms'
END bucket,
COUNT(*) cnt,
ROUND(RATIO_TO_REPORT(COUNT(*)) OVER(), 3) pct
FROM v$active_session_history
WHERE event = 'log file sync'
AND sample_time > SYSDATE - 1/24
GROUP BY
CASE
WHEN wait_time_milli < 1 THEN '<1ms'
WHEN wait_time_milli < 4 THEN '1-3ms'
WHEN wait_time_milli < 8 THEN '4-7ms'
WHEN wait_time_milli < 16 THEN '8-15ms'
ELSE '>=16ms'
END
ORDER BY bucket;若 “>=16ms” 桶占比超过 10%，尤其集中在业务高峰时段，基本可排除应用提交频率问题，直指底层 I/O 异常（如 RAID 5 写惩罚、磁盘 %util 饱和、SAN 队列堆积）。
别漏掉 RAC 或 DG 环境下的隐藏阻塞源
单机库中 log file sync ≈ LGWR 写完就通知；但在 RAC 或启用 SYNC AFFIRM 的 DataGuard 环境下，LGWR 必须等 SCN 同步完成才敢通知前台——这时 log file sync 长，log file parallel write 短，但你可能在 ASH 里看到 LGWR-LNS wait on channel 或 gc cr grant 2-way 等关联等待。
检查这类环境要加一层过滤：
SELECT sample_time, session_id, event, p1text, p1, p2text, p2, program
FROM v$active_session_history
WHERE sample_time > SYSDATE - 1/48
AND (event IN ('log file sync', 'LGWR-LNS wait on channel', 'gcs log flush sync')
OR program = 'LMS')
ORDER BY sample_time DESC
FETCH FIRST 10 ROWS ONLY;- 看到
LGWR-LNS wait on channel且持续时间长 → DG 同步慢，检查备库网络、归档应用延迟、log_archive_dest_n的SYNC和AFFIRM设置 - 看到
gcs log flush sync或大量 LMS 会话高负载 → RAC 内部 SCN 传播瓶颈，需查gc cr block busy和 interconnect 网络质量 - 即使没看到这些事件，只要
log file sync平均 >5ms 且log file parallel write
真正难的不是定位，是区分“LGWR 写得慢”和“LGWR 被别的事拖住”。ASH 提供的是时间切片证据，不是因果结论——同一毫秒级时间点上谁在等谁、谁在做什么，才是判断依据。
