物理备库MRP进程不会自动重试日志应用，REOPEN仅控制主库LNS归档传输重试，与MRP无关；MRP停摆是设计行为，恢复需满足实时应用、GAP可识别等条件，并经三步排查后手动启动。
物理备库不会自动重试归档传输，网络闪断后mrp进程停摆是默认行为，不是故障，而是设计使然。
REOPEN参数只控制归档传输（LNS），不控制日志应用（MRP）
很多人误以为设置LOG_ARCHIVE_DEST_n里的REOPEN就能让备库“自动续上”中断的日志流。实际上：REOPEN仅影响主库端的LNS进程——即主库尝试把归档发给备库时，若连接失败，等待多少秒后重试；它对备库端的MRP（Managed Recovery Process）完全无效。MRP一旦因GAP、文件缺失或控制文件不一致而中止，就会卡在APPLYING_LOG或WAIT_FOR_LOG状态，不会自行重启。
常见错误现象：
- 主库
V$ARCHIVE_DEST_STATUS显示ERROR或REOPEN计数持续增加，但备库V$MANAGED_STANDBY里MRP0进程状态为STOPPED - 备库
ALERT.log反复出现ORA-00308: cannot open archived log或ORA-16037: no archived log found for thread - 执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT后MRP启动，但几秒内又退出
真正决定MRP能否自动恢复的是REDO APPLY模式和GAP检测机制
MRP是否能“自动续传”，取决于两个底层条件：是否启用实时应用（REAL-TIME APPLY），以及GAP是否可被自动识别并填补。Oracle 12c默认关闭实时应用，且GAP自动修复需满足严格前提：
- 主库必须配置
LOG_ARCHIVE_DEST_n含SYNC或ASYNC+VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，且传输已验证成功 - 备库控制文件必须同步到最新检查点；若曾手工删过归档或控制文件陈旧，
V$ARCHIVE_GAP可能为空，但实际存在隐性GAP - 未启用
FLASHBACK DATABASE时，MRP无法跨化身（incarnation）恢复；ORA-19909报错即表明此限制生效
验证命令示例：
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
若返回空行，不代表无GAP——要结合V$ARCHIVED_LOG中APPLIED='NO'且DELETED='NO'的归档序列号比对。
手动触发MRP恢复前必须确认三件事
盲目执行RECOVER MANAGED STANDBY DATABASE常导致ORA-16004或ORA-01157。先做这三步排查：
- 查
V$MANAGED_STANDBY确认MRP0进程是否存在，状态是否为WAIT_FOR_LOG而非APPLYING_LOG；若为后者，说明已在运行，无需干预 - 查
V$ARCHIVED_LOG中最近APPLIED='YES'的归档SEQUENCE#，再查主库对应THREAD#下该SEQUENCE# + 1是否已生成并传输到备库归档目录 - 确认备库归档路径权限正常、磁盘空间充足，且
db_recovery_file_dest路径存在并已设db_recovery_file_dest_size
只有当以上都通过，才执行：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
想让MRP更“健壮”，得靠组合配置，不是单靠REOPEN
单独调大REOPEN=60没用。真正提升容错能力的配置组合是：
- 主库启用
LOG_ARCHIVE_DEST_2双路径：一个指向备库（SYNC），另一个本地异步归档（LOCATION=/local/arch VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)），防止单点传输失败丢日志 - 备库开启
FLASHBACK DATABASE并确保db_recovery_file_dest可用——这是MRP遇到化身不匹配时能自动回退的前提 - 定期用RMAN校验：
LIST ARCHIVELOG ALL;+CROSSCHECK ARCHIVELOG ALL;，清理EXPIRED条目，避免MRP被脏元数据干扰
最易被忽略的一点：REOPEN参数值单位是秒，但Oracle内部最小重试间隔为3秒；设REOPEN=1等同于REOPEN=3，不会更“灵敏”。
