awr诊断redo瓶颈需三步：先看top 5 timed events中log file switch两类等待是否超10%，再用redo size/s与日志大小反推切换频率，最后通过v$log_history验证时间分布是否周期性突增。
AWR 能直接告诉你 Redo 瓶颈在哪，但必须看对三页、算对两个比值、补一手原始时间分布——跳过任意一步，都可能把“应用提交风暴”误判成“日志文件太小”。
查 Top 5 Timed Events 里是不是真卡在日志切换上
打开 AWR 报告后直奔 Top 5 Timed Foreground Events 页面，盯住这两个等待事件：
-
log file switch (checkpoint incomplete)占比 >10% DB Time → 检查点没跑完，旧日志组还被占着；常见于DB_CACHE_SIZE过大、I/O 慢、或LOG_BUFFER太小 -
log file switch (archiving needed)占比 >10% → 归档进程跟不上；检查归档路径是否满、ARCHIVE_LAG_TARGET是否设了非零值（如 1800）、备库同步是否拖慢主库 - 如果这两个都低，但
log file sync高 → 问题不在 Redo 配置，而在应用层：高频短事务、频繁COMMIT；得查v$session中event = 'log file sync'的sid和sql_id
用 Redo size/s 和 log switches 反推日志组是否撑得住
去 AWR 报告的 Redo Statistics 区域找两个数：Redo size per second 和一小时内的 log switches 次数。拿日志大小除一下，就能看出理论支撑时长：
- 比如
Redo size per second是 2.3 MB/s，当前v$log.bytes是 100MB → 理论撑约 43 秒（100 ÷ 2.3） - 若实测平均 20 秒切一次，说明不是单纯“写得多”，而是有突发峰值（如批量
UPDATE或LOB修改） - 如果
Redo size per second是 1.09 MB/s，而日志组总容量才 600MB（3 组 × 200MB），那撑不到 10 分钟就会切，属于明显偏小 - 注意：单个大事务可能瞬间打爆一个日志组，只看吞吐不看峰值会误判
从 SQL ordered by Physical Reads 定位高 redo 语句
去 AWR 报告的 SQL Statistics → SQL ordered by Physical Reads 页面，找那些 Physical Reads 高且 Executions 也高的语句：
- 物理读多的 SQL，往往 redo 也高——尤其带索引更新、未绑定变量的重复 DML、或
UPDATE后触发大量二级索引维护 - 重点看执行计划里有没有
INDEX RANGE SCAN后接大量TABLE ACCESS BY INDEX ROWID + UPDATE - 对应
sql_id在v$sql中的buffer_gets和disk_reads是否持续偏高 - 曾有案例：
DELETE FROM wri$_adv_objects在错误时区下白天高频执行，就是靠这页揪出来的
别跳过 v$log_history 的时间分布验证
AWR 报告只给聚合结果，但日志切换可能是周期性的（比如每天 13:00 固定飙升）。必须运行原始 SQL 验证：
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;
如果发现某几分钟内切换次数陡增（比如从平均 20 秒一次变成 5 秒一次），就要怀疑是否是定时任务、统计信息收集、或某个批处理脚本在作祟——这类问题光调大日志文件完全无效。
