redo log过小是rac中log file switch (checkpoint incomplete)等待的最常见根因，需通过v$system_event中该等待time_waited是否超db time 5%及v$log_history中近20次切换平均使用率是否长期低于60%双重确认；rac扩容必须全局对齐日志组大小与数量，严格按thread分别添加、逐实例切换、等全inactive后删除，并确保所有实例同group#的bytes值一致、路径统一、组数匹配。
redo log过小是rac中log file switch (checkpoint incomplete)等待的最常见根因，直接扩容日志组大小（而非只加组数）才是有效解法。
怎么确认真是Redo Log太小导致的等待
别只看切换频率。重点查两件事：v$system_event里log file switch (checkpoint incomplete)的time_waited是否持续高于总DB Time的5%；再看v$log_history里最近20次切换的平均日志使用率——如果长期低于60%，基本可以锁定是日志尺寸不足。
常见误判点：
- 看到“Thread X cannot allocate new log”就急着加日志组数，但若每组仍只有100MB，问题照旧
- 用
SELECT * FROM v$log只查本节点，漏掉其他实例日志大小不一致的问题 - 忽略RAC多线程特性：thread 1切得快，会强制推进全局SCN，拖慢thread 2的检查点进度
Oracle RAC中Redo Log大小必须全局对齐
RAC不是单实例，ALTER DATABASE ADD LOGFILE GROUP 4 SIZE 100M这种语句只在当前实例生效，其他实例根本“看不见”这个新组——这会导致ORA-15042或日志循环卡死。
安全操作必须满足：
- 所有实例的
v$log中相同group#的bytes值完全一致 - 所有日志成员路径必须落在同一ASM磁盘组（如统一用
+DATA，禁用+RECO混用） - 每个thread都必须有对应数量的日志组，比如thread 1有group 1~4，thread 2也必须有group 1~4
- 执行
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 4 ...和ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 4 ...是两步独立操作，缺一不可
RAC专用扩容步骤：先增后删，逐实例同步
不能在线直接RESIZE，只能新增+切换+删除。关键约束是：所有实例必须同时处于OPEN状态，且无ACTIVE日志组残留（查SELECT group#, status FROM v$log WHERE status = 'ACTIVE'结果为空）。
实操顺序：
- 在节点1执行：
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 4 '+DATA/db/redo04.log' SIZE 500M - 在节点2执行：
ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 4 '+DATA/db/redo04.log' SIZE 500M - 分别在两个节点执行：
ALTER SYSTEM SWITCH LOGFILE（注意：这不是全局命令，必须各节点单独跑） - 等所有旧组（如group 1~3）状态变为
INACTIVE后再逐个删除：ALTER DATABASE DROP LOGFILE GROUP 1
删完立刻验证：SELECT thread#, group#, bytes/1024/1024 mb FROM v$log ORDER BY thread#, group#，确保所有行mb列数值一致。
为什么500MB是RAC下较稳妥的起点
OLTP类RAC系统，日志切换理想间隔是15–25分钟。按常见redo生成速率8–12 MB/s估算，500MB可支撑约40–60秒写入——但这只是底线。真正要防的是高峰脉冲：某次批量导入可能瞬时写出200MB，若日志仅200MB，就会触发频繁切换并卡住检查点。
容易被忽略的细节：
- ASM条带化存储对redo顺序写无加速效果，别指望换磁盘组能绕过日志大小问题
-
FAST_START_MTTR_TARGET设得太小（如30秒）会人为加剧检查点压力，与小日志叠加后恶化更快 - 归档路径IO慢（如NFS挂载点）会放大
log file switch (archiving needed)等待，但它和checkpoint incomplete是两类问题，需分开诊断
