awr可精准定位日志频繁切换根因：先查top 5 timed events中log file switch等待占比，再结合redo size/s、log switches频次、sql physical reads及v$log_history时间分布交叉验证。
日志频繁切换不是靠猜，awr 能直接定位到具体 sql 和对象，前提是快照时间选对、报告看准关键页。
查 AWR 报告里哪个等待事件在拖后腿
打开 AWR 报告后，先翻到 Top 5 Timed Events 部分。如果 log file switch (checkpoint incomplete) 或 log file switch (archiving needed) 占比高（比如 >10% DB Time），就说明 Redo 日志根本没来得及被重用，切换被迫卡住——这不是“写得多”，而是“写完没法清”。
- 前者多因检查点太慢，常见于 Redo 太小、Buffer Cache 过大、I/O 瓶颈；
- 后者多因归档跟不上，比如归档路径满、归档进程挂起、或磁盘写入慢；
- 若两者都低，但
log file sync等待高，则问题在提交响应慢，要查应用层是否高频短事务。
看 Redo size 指标估算真实压力
在 AWR 报告的 Instance Activity Stats 或 Redo Statistics 区域找 Redo size per second 和 Redo size per transaction。这两个数决定 Redo 文件撑多久。
- 比如
Redo size per second是 1.09 MB/s，那 200MB 的日志文件理论上撑不到 3 分钟（200 ÷ 1.09 ≈ 183 秒）； - 再结合
log switches数量：如果一小时切了 120 次，平均 30 秒一次，基本可断定 Redo 配置严重偏小； - 注意：单个大事务（如批量 UPDATE）可能瞬间打爆一个日志组，不看吞吐只看峰值会误判。
用 SQL ordered by Physical Reads 定位高日志生成对象
很多人忽略一点：物理读多的 SQL，往往也伴随大量 Redo 写入——尤其是带索引维护、LOB 更新、或未绑定变量的重复 DML。去 AWR 报告的 SQL Statistics → SQL ordered by Physical Reads 页面，找那些 Physical Reads 高且 Executions 也高的语句。
- 重点看执行计划里有没有
INDEX RANGE SCAN后接大量TABLE ACCESS BY INDEX ROWID+UPDATE； - 对照
v$sql查sql_id对应的buffer_gets和disk_reads，确认是否是热点行更新； - 案例中曾发现
UPDATE wri$_adv_objects在错误时区下白天高频执行，就是靠这页揪出来的。
别跳过 Log History 和 v$log_history 的时间分布验证
AWR 报告只反映“某段时间内”的聚合结果，但日志切换可能是周期性爆发的。必须补一手原始数据验证：
- 运行
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;查过去一小时每分钟切换次数； - 如果出现“13:00–13:05 切了 20 次，其余时间几乎不切”，说明是某个定时任务触发，不是整体负载问题；
- 此时立刻查
dba_scheduler_jobs和dba_scheduler_window_details，比盲调 Redo 大小高效十倍。
真正难的不是找到 SQL，而是区分“谁在写日志”和“谁让日志没法回收”。时区错位、检查点滞后、归档阻塞、甚至一个没加 WHERE 的 UPDATE，表现都是日志狂切——AWR 只给线索，结论得靠交叉验证。
