Oracle Data Guard备用日志组数量如何计算？

备用日志组数量不够会导致主库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 )

但实际部署中，更可靠的做法是按以下三者取最大值：

1. 主库 ONLINE REDO LOG 组数 × 2 + 1（最小保底值，防突发切换）
2. 主库峰值每分钟日志切换次数 × 3（覆盖 3 分钟缓冲，应对网络抖动或 I/O 暂停）
3. 主库单个日志文件大小（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 就万事大吉：

1. 所有 SRL 必须与主库 ONLINE REDO 日志大小严格一致（ALTER DATABASE ADD STANDBY LOGFILE 时漏写 SIZE 会默认用 DB_BLOCK_SIZE，极易引发 ORA-38500）
2. SRL 文件路径需在备库本地可写，且不能与主库路径相同（否则 RMAN duplicate 或 switchover 时可能误删）
3. 添加后必须重启 MRP0（ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL → DISCONNECT），否则新增 SRL 不会被 MRP 进程识别
4. 使用 FORCE LOGGING 模式时，即使业务低峰，SRL 消耗速度也可能远超预期——别只看历史 AWR 报告，要查 V$STANDBY_LOG 的 STATUS 和 FIRST_TIME 变化频率

如何验证当前 SRL 数量是否真的够用？

别只看 V$STANDBY_LOG.STATUS 是否全是 ACTIVE 或 UNASSIGNED，重点查动态行为：

1. 运行 SELECT COUNT(*) FROM V$STANDBY_LOG WHERE STATUS = 'CURRENT' —— 正常应始终 ≤ 1；若频繁出现 ≥2，说明 SRL 严重不足
2. 查最近 1 小时内 V$ARCHIVED_LOG 的 DEST_ID = 2（备库）记录数，对比 V$STANDBY_LOG 总数，若前者持续 > 后者 × 0.8，就是临界预警
3. 观察 SELECT * FROM V$DATAGUARD_STATS WHERE NAME = 'apply lag'，如果 apply lag 非零且随日志切换周期性跳变，大概率是 SRL 循环覆盖导致重传

真正难的是把「理论公式」和「实时负载毛刺」对齐——比如批处理窗口那 10 分钟的日志爆发量，往往比日常高 5 倍，这部分必须单独测算并预留。