ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 会因离线表空间卡住，因MRP拒绝应用涉及OFFLINE表空间的redo；需先查DBA_TABLESPACES和DBA_DATA_FILES确认状态，若ONLINE_STATUS为RECOVER则须CANCEL后RECOVER DATAFILE，若存在UNNAMED文件还需手动重建。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 会卡在离线表空间上，不是因为“不能跳过”，而是 Oracle 默认拒绝应用涉及离线表空间的 redo —— 它认为这可能破坏一致性。
离线表空间如何阻断 MRP 进程
MRP（Managed Recovery Process）在应用归档日志时，会对每条 redo 记录做逻辑校验：如果 redo 涉及某个数据文件，而该文件所属表空间当前是 OFFLINE 状态（哪怕只是 OFFLINE NORMAL），MRP 就会直接报错并中止应用，不再继续往后读日志。
典型错误信息出现在备库 alert.log 中：ORA-01157: cannot identify/lock data file N 或更直接的 ORA-01110: data file N: '/path/to/file.dbf'，但注意：这个文件其实存在且可读，只是它所在的表空间被设为离线。
- MRP 不会自动跳过、重试或等待表空间上线；它一旦遇到就停住
-
v$managed_standby中MRP0状态会变成WAIT_FOR_LOG或APPLYING_LOG但SEQUENCE#长期不更新 - 即使其他表空间完全正常，只要有一块“离线”挡路，整个恢复链就冻结
为什么 ALTER TABLESPACE ONLINE 不总能立刻解堵
执行 ALTER TABLESPACE xxx ONLINE 后，MRP 仍可能继续卡住，原因常被忽略：
- 表空间虽已 online，但对应的数据文件状态仍是
RECOVER（查DBA_DATA_FILES.STATUS）—— 这说明控制文件里该文件标记为“需恢复”，MRP 仍拒绝应用其 redo - 主库在表空间 offline 期间做了操作（如 drop tablespace、truncate、甚至新增对象），这些操作生成的 redo 在备库没有对应物理结构支撑，MRP 无法绕过
- 备库控制文件未同步主库最新结构变更（比如主库 offline 前刚 add datafile，但归档未传全），导致备库元数据不一致
真正有效的解法顺序
别急着重启 MRP，先确认问题根因再动手：
- 查清哪个表空间离线：
SELECT TABLESPACE_NAME, STATUS FROM DBA_TABLESPACES WHERE STATUS = 'OFFLINE'; - 查对应数据文件真实状态：
SELECT FILE_ID, FILE_NAME, STATUS, ONLINE_STATUS FROM DBA_DATA_FILES WHERE TABLESPACE_NAME = 'XXX';—— 关键看ONLINE_STATUS是OFFLINE还是RECOVER - 如果
ONLINE_STATUS = RECOVER，说明文件需要介质恢复；此时必须先停 MRP：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;，再手工恢复：RECOVER DATAFILE N;（需备库处于 MOUNT 状态） - 如果只是
ONLINE_STATUS = OFFLINE，且你确认主库早已 online 该表空间，则可能是备库控制文件滞后 —— 可尝试ALTER DATABASE BACKUP CONTROLFILE TO TRACE;对比主备控制文件 SCN，必要时从主库拷贝最新 controlfile 替换
最容易被跳过的细节：standby_file_management
当主库 offline 表空间后又 online，并在此期间新增了数据文件，而备库 standby_file_management 设为 AUTO 但实际没生效（比如磁盘组权限不足、路径映射错误），就会导致备库控制文件里残留 UNNAMED 占位符。这种情况下，即使表空间 online，MRP 仍会因找不到物理文件而反复报 ORA-01110。
验证方式：SELECT FILE_NAME FROM DBA_DATA_FILES WHERE FILE_NAME LIKE '%UNNAMED%'; —— 有结果就得按 ORA-01111 场景手动重建数据文件，不能只靠 online 表空间。
