若log file switch (checkpoint incomplete)或(log archiving needed)在top 5 timed events中占比超10% db time，表明存在严重争用：前者因检查点滞后致redo无法重用，后者因归档延迟致日志切换卡顿；需结合v$log、v$archive_dest_status、v$archive_gap、redo size/s与log switches频次、时间粒度切换分布、log file sync与parallel write延迟、user commits速率、rac scn同步及sql物理读等综合诊断。
看Top 5 Timed Events里log file switch占比是否异常高
如果log file switch (checkpoint incomplete)或log file switch (archiving needed)在Top 5 Timed Events中占比超过10% DB Time，基本可判定存在严重争用。前者说明检查点太慢，Redo日志无法及时重用；后者说明归档跟不上，常见于归档路径满、ARCH进程卡死或归档目标磁盘I/O慢。
注意：这两个等待事件不是“写得多”的表现，而是“写完没法清”的信号——哪怕Redo size/s不高，只要切换卡住，就会拖垮整体响应。
- 查
v$log确认当前日志组状态：STATUS列若长期卡在ACTIVE，说明检查点滞后 - 查
v$archive_dest_status中STATUS和ERROR字段，确认归档链路是否健康 - 运行
SELECT * FROM v$archive_gap;检查是否存在归档断点
结合Redo size/s与log switches频次交叉验证
AWR报告中Redo size per second和一小时内log switches数量必须一起看。比如Redo写入1.09 MB/s，日志文件200MB，理论撑约183秒；若实际一小时切了120次（平均30秒一次），说明配置严重偏小，不是负载问题，是容量硬伤。
但别只信平均值——单个大事务（如全表UPDATE）可能瞬间打爆一个日志组，掩盖真实瓶颈。得补一手时间粒度验证：
- 执行
SELECT TO_CHAR(FIRST_TIME, 'hh24:mi'), COUNT(*) FROM v$log_history WHERE FIRST_TIME > SYSDATE - 1/24 GROUP BY TO_CHAR(FIRST_TIME, 'hh24:mi') ORDER BY 1;看是否集中爆发 - 若某几分钟内切换次数陡增3倍以上，说明业务有周期性批量操作，需针对性优化而非盲目扩容
盯紧log file sync与log file parallel write的延迟关系
log file sync高不等于Redo争用，得先排除提交风暴。查AWR中user commits每秒速率：超过50/s是警戒线，超200/s大概率是应用层INSERT; COMMIT;滥用，此时调存储毫无意义。
只有当log file sync与log file parallel write平均等待时间高度接近（比如都在8–12ms），且v$event_histogram里16ms及以上档位占比超30%，才真正指向LGWR写盘慢——这时要查iostat -x 1 5的%util和await，尤其警惕RAID 5上放Redo日志。
- 别忽略RAC环境：SCN同步延迟也会抬高
log file sync，单节点查不出问题 -
commit_write='BATCH,NOWAIT'能压低该等待，但会丢失最近几毫秒提交，金融类系统禁用
别跳过SQL ordered by Physical Reads页面
物理读高的SQL，往往也是Redo大户——尤其是带索引更新、LOB列修改、或未绑定变量的重复DML。重点扫SQL ordered by Physical Reads页里Executions也高的语句。
例如看到UPDATE wri$_adv_objects执行频繁，再查v$sql对应buffer_gets和disk_reads，若热点行更新明显，就不是Redo配置问题，而是SQL本身该优化或加批量提交。
- 执行计划里出现
INDEX RANGE SCAN → TABLE ACCESS BY INDEX ROWID → UPDATE链路，是典型Redo放大器 - LOB字段更新一次可能生成数MB Redo，比普通UPDATE高几个数量级
真实争用往往藏在多个指标的错位里：比如log file switch不高，但log file sync飙升且user commits正常——这时该怀疑log_buffer设置不当或_log_io_size隐含参数干扰，而不是急着加日志组。
