AWR中log file parallel write平均等待时间高通常非磁盘慢所致，而是LGWR在写前、写中或写后被卡住；需通过v$sysstat反推单次物理I/O延迟（redo write time / redo writes × 10），结合直方图（重点关注16ms+占比）及iostat的w_await交叉验证。
awr里log file parallel write平均等待时间高，90%以上不是磁盘慢，而是lgwr被“卡”在了写之前、写之中或写之后的某个环节——必须拆开看它到底在等什么。
查真实单次写延迟，别信AWR的Avg Wait(ms)
AWR报告里的log file parallel write Avg Wait(ms)是把每次批量写（含多个block）的总耗时除以写次数算出来的，容易失真。比如一次写512KB（约100个block），耗时12ms，它就记作“12ms/1次”，但实际每个block物理落盘可能只要1–2ms。
- 用
v$sysstat反推更准：执行SELECT name, value FROM v$sysstat WHERE name IN ('redo writes', 'redo write time');，然后算redo write time / redo writes * 10（单位ms），这个值才接近LGWR单次物理I/O的真实延迟 - 若该值稳定在2–8ms，但AWR显示12ms+，大概率是
LOG_BUFFER设太大，或事务太碎导致LGWR单次塞太多block，不是磁盘问题 - 如果
redo writes每秒超200次，且redo write time同步飙升，说明LGWR被高频唤醒拖累，而非I/O慢
看直方图分布，16ms+占比超30%才真卡
平均值掩盖不了长尾。真正拖慢响应的是那些反复发生的高延迟写，而不是偶尔一次抖动。
- 运行
SELECT wait_time_milli, wait_count FROM v$event_histogram WHERE event = 'log file parallel write' AND wait_time_milli IN (1,2,4,8,16,32); - 重点盯
wait_time_milli = 16和32这两档：若合计wait_count占总量超30%，说明LGWR持续卡顿，需深挖 - 若
wait_time_milli = 1或2占绝对大头（>70%），哪怕Avg Wait显示10ms，也基本可排除硬件I/O瓶颈
交叉验证OS层，iostat要看w_await，不是%util
%util > 95%不等于磁盘慢——RAID卡缓存策略、队列深度、文件系统挂载参数都可能让%util虚高。
- 用
iostat -x 1盯w_await（写响应时间）：Linux下持续>15ms才值得怀疑物理层；SSD应稳定在 -
aqu-sz（平均队列深度）若长期 - 模拟LGWR写法测裸盘：
dd if=/dev/zero of=/test/redo_test bs=512k count=200 oflag=direct,sync，同时跑iostat -x 1，比对w_await是否与数据库内一致
检查LGWR行为本身，LOG_BUFFER和日志组配置最常踩坑
LGWR不是“越快写越好”，它的节奏受配置强约束。很多高延迟，其实是人为调得太“激进”。
-
LOG_BUFFER建议3–8MB：设成32MB或更大，单次写量暴涨，反而拉长log file parallel write耗时；观察v$sysstat中redo buffer allocation retries是否>0，>0说明buffer不够用， - redo日志文件必须独占物理路径：不能和数据文件、归档、备份混LUN；RAID必须用1+0，禁用RAID 5；多组日志要跨不同控制器+磁盘柜
- 避免
commit_write=BATCH,NOWAIT滥用：它会让LGWR攒更多再写，单次log file parallel write延迟必然升高，只是把压力从用户进程转嫁给了LGWR
真正难判断的，是log file parallel write和log file sync时间差得不多（比如都是8–12ms），但直方图又没明显长尾——这时候问题往往藏在OS调度、CPU run queue或RAC的SCN同步机制里，得切到v$lgwr或v$instance_recovery里看actual_redo_blks和target_redo_blks是否持续偏离。
