Redo Log过小导致“log file switch (checkpoint incomplete)”高频出现，表现为AWR中该事件进入Top 5、Waits/Time(s)显著偏高、DB Time占比超5%，并常伴“log file switch (archiving needed)”升高；需结合Redo size per second与期望切换周期（如20分钟）反推单组日志应≥1.3GB，同时验证v$log中SEQUENCE#增长速率及STATUS循环频率。
看AWR里“log file switch (checkpoint incomplete)”是否高频出现
这个等待事件排进Top 5，基本就能断定Redo Log太小了。它不是说磁盘慢或归档卡住，而是检查点跟不上日志填满速度——旧日志还没刷完，新日志又满了，只能干等。
常见现象：
- AWR报告中该事件的“Waits”和“Time(s)”数值显著高于其他I/O类等待
- DB Time占比超过5%，尤其在业务高峰时段集中爆发
- 伴随“log file switch (archiving needed)”一起升高，说明归档也成了瓶颈
算Redo size per second再乘以切换周期
AWR报告“Load Profile”部分有Redo size per second，这是最硬的输入数据。拿它乘以期望的最小切换间隔（比如20分钟），就能反推单组日志至少该有多大。
例如：
- 报告里显示
Redo size per second是1.09 MB/s - 1.09 × 60 × 20 ≈ 1308 MB → 单组日志建议 ≥ 1.3 GB
- 如果当前每组才200 MB，那平均每10分钟就切一次，远超20分钟建议值
注意：别只看平均值。要翻到“SQL ordered by Gets”或“SQL ordered by Executions”，找那些批量INSERT/UPDATE的语句，它们可能在短时间制造数MB的Redo，导致局部尖峰。
查v$log状态确认是否真被频繁切换
光看AWR不够，得下钻验证实际日志轮转节奏。连上数据库执行：
SELECT group#, bytes/1024/1024 AS mb, status, sequence# FROM v$log;
关键看：
-
STATUS列是否在CURRENT→ACTIVE→INACTIVE之间快速循环 - 同一组日志的
SEQUENCE#在1小时内增长是否超过50（意味着每分钟切1次以上） - 有没有长期卡在
ACTIVE状态的组？那说明检查点严重滞后，Redo Log尺寸和fast_start_mttr_target可能都需调
警惕“log file sync”高但redo buffer allocation retries不高的误导
log file sync等待高，很多人第一反应是调log_buffer，但其实更可能是Redo Log太小触发密集刷盘。这时候要交叉验证：
- 查
v$sysstat里redo buffer allocation retries是否稳定为0 —— 如果是，说明Log Buffer够用，问题不在内存缓冲区 - 同时看
log file parallel write平均写入时间是否正常（log file sync高，大概率是日志切换太勤，每次sync都在等下一个可用日志组 - AWR里“Instance Efficiency Percentages”中
Buffer Nowait %和Redo NoWait %若双双低于99%，说明竞争已实质影响并发
真正难判断的点在于：Redo Log大小和检查点频率、归档吞吐、甚至备份窗口都耦合在一起。调大日志能减少切换，但会延长实例恢复时间；设太多组又增加管理复杂度。所以必须结合业务SLA来定——比如能否容忍15分钟以上的崩溃恢复？能不能接受归档延迟？这些比单纯看AWR数字更关键。
