平均等待>10ms不等于磁盘慢，需先用v$sysstat计算真实单次IO延迟（redo write time / redo writes × 10），>15ms才疑存储；若2–8ms则查LGWR行为、日志配置或CPU调度，并结合v$event_histogram（16ms+占比>30%）和iostat（w_await>15ms）交叉验证。
log file parallel write平均等待 >10ms 怎么快速定位真因
AWR 报告里 log file parallel write 平均等待时间高，不等于磁盘慢——它只是 LGWR 写日志的总耗时，可能被单次写量、IO 调度、redo 日志配置甚至 CPU 调度拖累。先别急着换 SSD。
真正该看的是这个公式：redo write time / redo writes * 10（单位 ms），从 v$sysstat 算出实际单次 IO 延迟，比 AWR 的“平均等待”更贴近物理层表现。
- 若结果长期 >15ms，才值得怀疑存储；2–8ms 波动，大概率是 LGWR 自身行为或日志组设计问题
- 查
v$event_histogram中wait_time_milli= 16/32 档位的wait_count占比：超 30% 才说明 LGWR 持续卡顿 -
iostat -x 1 5看await>15ms 或w_await显著升高（尤其 NVMe 盘），才是物理瓶颈；%util>90% 仅作辅助参考
为什么 redo 日志不能放在 RAID 5 或混放 LUN 上
RAID 5 对 redo 是灾难性组合：LGWR 典型写模式是小块顺序写（常为 512KB 批量），但在 RAID 5 下会被校验计算强制转成随机大写，I/O 效率归零。混放 LUN（比如 redo 和归档/数据文件共用同一 SSD）也会干扰 LGWR 的顺序写节奏。
- 所有 redo 日志组成员必须分散到独立物理磁盘（不同 RAID 组/LUN），哪怕只有一组也要单盘单文件
- SSD 上禁用
barrier=1、启用noatime，ext4 建议挂载参数data=writeback；xfs 不需 journal - RAID 卡缓存策略必须设为 Write-Back（非 Write-Through），否则 SSD 低延迟优势直接打折扣
lgwr 写量过大导致 log file parallel write 高怎么办
不是所有高等待都来自磁盘——如果每秒 user commits 超 200/s（提交风暴），或 redo blocks written / user commits 远低于 20（说明事务太碎），LGWR 就会被反复唤醒，调度开销放大，写量虽不大但延迟飙升。
- 运行 SQL 查真实压力：
SELECT ROUND(SUM(CASE WHEN NAME = 'user commits' THEN VALUE END) / 3600, 2) AS commits_per_sec FROM v$sysstat WHERE NAME IN ('user commits','user rollbacks'); - 配合
user calls / (user commits + user rollbacks)看事务粒度：结果接近 1 表明大量INSERT; COMMIT;类操作 - 禁用
SEQ.NEXTVAL的NOCACHE属性，避免每次取值触发数据字典递归 commit
commit_write=BATCH,NOWAIT 能不能开
能开，但不是“绕过问题”的捷径，而是用可接受的数据丢失风险换响应时间——实例崩溃时，最近一批未刷盘的 commit 可能丢失（通常几毫秒到最多 100ms）。
- 启用命令：
ALTER SYSTEM SET commit_write='BATCH,NOWAIT' SCOPE=BOTH; - 副作用真实存在：LGWR 单次写量变大，可能触发 I/O 峰值；
redo writing latch争用可能转移成redo allocation latch争用 - 仅适用于埋点、日志类系统；含资金、状态变更等关键事务的场景禁用
- 严禁与
NOLOGGING或临时表混用——会直接破坏 Data Guard 同步、闪回、RMAN 备份一致性
最易被忽略的点：RAC 环境下，log file parallel write 正常不代表 LGWR 发送没问题——SCN 传播延迟才是隐藏杀手，必须查 v$managed_standby 中各节点 LGWR 的 STATUS 和 SEQ# 是否同步。
