AWR报告不能直接给出Redo日志大小，但log file switch (checkpoint incomplete)高占比或日志切换超4次/小时即表明日志组总容量偏小，需扩容；黄金指标是每小时切换2–4次（15–30分钟一次），RAC环境下各实例日志组大小必须完全一致。
AWR报告本身不能直接告诉你“该把Redo日志设成多大”，但它能暴露一个关键信号：log file switch (checkpoint incomplete) 等待事件高占比，或日志切换频率持续高于 4 次/小时——这时基本可以确定当前日志组总容量偏小，必须扩容。
看 AWR 中的 Redo size per second 不是看绝对值，而是看趋势和上下文
Redo size（单位 bytes/sec）在 AWR 的 Load Profile 部分只反映逻辑 redo 生成强度，不是归档量，也不等于实际写入磁盘的日志体积。它包含 block padding、SCN 标记、IMU 开销等，实际归档文件体积通常只有它的 70%–90%。
常见误判：直接拿 Redo size ≈ 1.09 MB/s × 3600 秒 = 3.9 GB/h，再除以日志组数，得出“每组要 2GB”——这会严重高估。
- 真正该用的是：该快照周期内真实日志切换次数（来自
v$log_history或alert.log），而非理论推算 - 计算间隔不能依赖
DBA_HIST_SNAPSHOT.END_INTERVAL_TIME直接相减，它有分钟级漂移；应查DBA_HIST_SYSSTAT中连续两个 SNAP_ID 对应的实际采集时刻 - 若 AWR 显示
Redo size是 1.5 MB/s，且同期日志切换了 8 次/小时，则日志组总容量很可能不足1.5 × 60 × 60 ÷ 8 ≈ 675 MB
查日志切换频率比看 Redo size 更直接有效
黄金指标就一个：日志每小时切换次数是否落在 2–4 次区间（即 15–30 分钟切一次）。低于 2 次可能拉长恢复窗口；高于 4 次则极易触发 log file switch (checkpoint incomplete)。
实操建议：
- 在
alert.log中 grepThread 1 advanced to log sequence，统计单位时间出现次数（注意 RAC 多线程需分 thread# 统计） - 用 SQL 查历史节奏（需
STATISTICS_LEVEL = TYPICAL）：SELECT TRUNC(first_time,'HH24') dt, COUNT(*) switches FROM v$log_history WHERE first_time > SYSDATE - 7 GROUP BY TRUNC(first_time,'HH24') ORDER BY dt;
- 如果某小时切换达 8 次，而 AWR 显示同期
Redo size是 1.5 MB/s，那当前日志组总容量大概率不够
RAC 环境下各实例日志组大小必须完全一致
这不是性能建议，是硬约束。Oracle 11g RAC 中，v$log.bytes 在不同 thread# 下哪怕差 1 字节，都可能引发检查点推进卡顿、归档堆积，甚至报 ORA-15042 错误。
容易踩的坑：
- 扩容时只改了 thread 1 的日志组，忘了 thread 2
- 用
ALTER DATABASE ADD LOGFILE GROUP添加新组时，没显式指定所有 thread 对应的路径（尤其 DG 环境下 standby 成员易被忽略） - 误以为“只要总大小一样就行”，但 Oracle 校验的是每个
group#下各thread#的bytes值完全相等
别信“默认 50MB 就够用”，也别盲目堆到 1GB
Oracle 11g 默认 3 组 × 50 MB 是为极轻负载设计的。TPS 稍高（比如单事务写入超 1 MB），就可能每 5–10 分钟切一次日志。
但也不是越大越好：
- 日志太大（如单组 > 2 GB）会导致 checkpoint 周期拉长，实例恢复时间变长，不符合 RPO/RTO 要求
- 推荐组合：4–6 组，每组 200–500 MB，兼顾切换频率、恢复时间和磁盘空间
- 新增日志组后，必须多次执行
ALTER SYSTEM SWITCH LOGFILE，确保旧组状态变为INACTIVE才能安全删除——CURRENT和ACTIVE组无法 drop
最常被忽略的一点：扩容操作本身不难，难的是确认所有 thread 的日志组大小已同步、所有旧组确实处于 INACTIVE 状态、且归档已落盘完成。漏掉任一环节，都可能在下次切换时卡住。
