备用日志组数量不够会导致主库arch进程频繁挂起、lgwr等待log file switch (archiving needed)，备库mrp0进程日志应用延迟飙升，甚至出现ora-00313或ora-00312报错，根本原因是srl被新日志覆盖导致断点续传失败。
备用日志组数量不够会导致什么现象？
最直接的表现是主库 ARCH 进程频繁挂起、LGWR 等待 log file switch (archiving needed)，备库 MRP0 进程日志应用延迟飙升，甚至出现 ORA-00313（open failed: no members）或 ORA-00312 报错。根本原因是主库切换日志时，备库还没来得及归档完前一组，新日志又覆盖了旧的 standby redo log（SRL），导致断点续传失败。
计算公式：必须满足「主库最大并发日志切换量 + 安全冗余」
Oracle 官方推荐公式为：max( (2 × 主库 ONLINE REDO LOG 组数) + 1, 主库每小时平均日志切换次数 ÷ 60 × 平均单次切换耗时（秒） ÷ 60 + 3 )
但实际部署中，更可靠的做法是按以下三者取最大值：
- 主库 ONLINE REDO LOG 组数 × 2 + 1（最小保底值，防突发切换）
- 主库峰值每分钟日志切换次数 × 3（覆盖 3 分钟缓冲，应对网络抖动或 I/O 暂停）
- 主库单个日志文件大小（MB） ÷ 备库归档写入吞吐（MB/s） × 1.5（留出 50% 冗余，避免 SRL 被覆盖）
例如：主库有 4 组 ONLINE REDO，每组 512MB；峰值每分钟切 2 次；备库归档写入能力约 30MB/s → 计算得：4×2+1=9，2×3=6，512÷30×1.5≈26 → 最终应设至少 26 组 SRL。
添加备用日志组时最容易踩的坑
不是加得越多越好，也不是复制主库 ONLINE REDO 的 size 就万事大吉：
- 所有 SRL 必须与主库 ONLINE REDO 日志大小严格一致（
ALTER DATABASE ADD STANDBY LOGFILE时漏写SIZE会默认用 DB_BLOCK_SIZE，极易引发ORA-38500） - SRL 文件路径需在备库本地可写，且不能与主库路径相同（否则 RMAN duplicate 或 switchover 时可能误删）
- 添加后必须重启
MRP0（ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL→DISCONNECT），否则新增 SRL 不会被 MRP 进程识别 - 使用
FORCE LOGGING模式时，即使业务低峰，SRL 消耗速度也可能远超预期——别只看历史 AWR 报告，要查V$STANDBY_LOG的STATUS和FIRST_TIME变化频率
如何验证当前 SRL 数量是否真的够用？
别只看 V$STANDBY_LOG.STATUS 是否全是 ACTIVE 或 UNASSIGNED，重点查动态行为：
- 运行
SELECT COUNT(*) FROM V$STANDBY_LOG WHERE STATUS = 'CURRENT'—— 正常应始终 ≤ 1；若频繁出现 ≥2，说明 SRL 严重不足 - 查最近 1 小时内
V$ARCHIVED_LOG的DEST_ID = 2（备库）记录数，对比V$STANDBY_LOG总数，若前者持续 > 后者 × 0.8，就是临界预警 - 观察
SELECT * FROM V$DATAGUARD_STATS WHERE NAME = 'apply lag'，如果 apply lag 非零且随日志切换周期性跳变，大概率是 SRL 循环覆盖导致重传
真正难的是把「理论公式」和「实时负载毛刺」对齐——比如批处理窗口那 10 分钟的日志爆发量，往往比日常高 5 倍，这部分必须单独测算并预留。
