主备库redo log大小不一致必然导致物理Data Guard同步中断，MRP进程启动即崩溃并报ORA-00344；根本原因是Oracle 11g严格校验redo块尺寸，备库standby redo log尺寸必须不小于主库最大online redo log尺寸，且VALID_FOR需包含(PRIMARY_ROLE, ONLINE_LOGFILES)，RAC环境下须按最大thread的最大组对齐。
主备库 redo log 大小不一致，物理 Data Guard 同步会直接中断，不是“可能出问题”，而是必然失败。
MRP 进程启动即崩溃，日志里反复出现 ORA-00344
备库 MRP（Managed Recovery Process）尝试应用主库传来的归档或实时 redo 时，发现日志块长度、校验逻辑与本地 standby redo log 文件结构不匹配，会立即报 ORA-00344: unable to recreate online log 并退出。这不是配置错误，是 Oracle 内部写入路径的硬校验失败。
- 典型表现：DGMGRL 显示
State = APPLYING_LOG但Transport Lag和Apply Lag持续增长，v$managed_standby中MRP的status在APPLYING_LOG和IDLE间快速跳变 - 告警日志里紧随
ORA-00344出现RFS[2]: Archived Log: 'UNKNOWN'—— RFS 进程其实已无法将新接收的 redo 写入 standby log - 根本原因：Oracle 11g 对
redo块头中log_block_size字段做严格校验，主库生成的 block 尺寸 ≠ 备库 standby log 预期尺寸，直接拒绝写入
备库 standby redo log 尺寸必须 ≥ 主库最大 online redo log 尺寸
很多人误以为“只要主备 online redo log 大小一致就行”，其实关键在 standby log。主库每组 redo log 是独立写入的，而备库的 standby redo log 必须能容纳主库任意一组产生的最大连续 redo 流 —— 所以它必须不小于主库最大的那组 online redo log。
- 查主库最大尺寸：
SELECT MAX(bytes) FROM v$log; - 查备库 standby log 是否达标：
SELECT group#, bytes/1024/1024 size_mb, status FROM v$standby_log;—— 任何一组size_mb小于主库最大值，都算不合规 - 常见坑：主库有 3 组 50MB + 1 组 200MB，但备库只建了 4 组 50MB 的
standby logfile，结果 MRP 永远卡在应用那组 200MB 日志上 -
VALID_FOR必须包含(PRIMARY_ROLE, ONLINE_LOGFILES)，否则 RFS 根本不会往这组 standby log 写，哪怕尺寸够大也白搭
主库增大 redo log 后，备库不能只改 standby log 尺寸
主库执行完 ALTER DATABASE ADD LOGFILE GROUP ... SIZE 200M 并切换使用后，备库光新增大尺寸 standby log 不够，还必须确保旧 standby log 被彻底清理干净，否则残留的小尺寸组仍会被 RFS 选中尝试写入。
- 先停应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 删旧 standby log：
ALTER DATABASE DROP LOGFILE GROUP 4;（仅对UNASSIGNED或UNUSED状态操作，否则报ORA-01624） - 再加新组：
ALTER DATABASE ADD STANDBY LOGFILE GROUP 8 '/path/std_redo08.log' SIZE 200M; - 验证：
SELECT type, member, bytes/1024/1024 FROM v$logfile WHERE type = 'STANDBY';—— 输出里不应再出现旧尺寸
最容易被忽略的是：RAC 环境下，主库每个 thread 的 redo log 尺寸可能不同，备库必须按最大 thread 的最大组来对齐 standby log，而不是看整体平均值。
