备库存储掉线后须先检查归档堆积与传输状态，再重置控制文件角色为physical standby，最后手动补全日志缺口并启用mrp；否则将触发ora-16139等错误或mrp拒绝启动。
备库存储掉线后，不能直接重启MRP或强行恢复；必须先确认归档是否堆积、主库是否仍在尝试传输、控制文件是否仍认为该备库有效——否则大概率触发ORA-16139、ORA-01275或LGWR阻塞。
查清归档堆积和传输状态再动手
存储掉线期间，主库的归档日志可能已在LOG_ARCHIVE_DEST_2目标持续堆积，但备库无法接收。不清理这个“假在线”状态就操作，会导致后续日志切换卡住：
- 在主库执行：
SELECT DEST_ID, STATUS, ERROR, TRANSMIT_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;—— 若STATUS是ERROR且ERROR列有内容（如ORA-12547），说明传输已失败，可安全清理 - 再查堆积量：
SELECT THREAD#, SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG WHERE DEST_ID = 2 AND APPLIED = 'NO' ORDER BY SEQUENCE# DESC FETCH FIRST 5 ROWS ONLY; - 如果
V$ARCHIVE_DEST_STATUS.STATUS仍是VALID或DEFERRED，说明主库还在“假装能连”，此时需先ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;暂停传输，再继续后续步骤
备库启动前必须重置控制文件角色
存储恢复后，即使你把数据文件、控制文件都原样找回，只要没重置DG角色，备库STARTUP MOUNT后V$DATABASE.DATABASE_ROLE仍可能是PRIMARY或INVALID，导致MRP拒绝启动：
- 确保备库已
SHUTDOWN IMMEDIATE，然后用STARTUP NOMOUNT - 从主库拉取最新控制文件：
RMAN> RESTORE STANDBY CONTROLFILE FROM SERVICE <master_db_unique_name>;</master_db_unique_name>（19c+支持，无需停库） - 再
ALTER DATABASE MOUNT;，立刻验证：SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;—— 必须是PHYSICAL STANDBY+MOUNTED - 若仍是
PRIMARY，说明控制文件未生效或拉取失败，不能跳过这步硬切：ALTER DATABASE CONVERT TO PHYSICAL STANDBY;，然后SHUTDOWN IMMEDIATE; STARTUP MOUNT;
启用日志应用前先堵住GAP黑洞
存储掉线期间漏掉的归档不会自动补全。如果直接RECOVER MANAGED STANDBY DATABASE，MRP会卡在第一个缺失日志上，报WAIT_FOR_LOG且V$ARCHIVE_GAP为空（因为FAL机制依赖备库能连通主库，而此时网络/存储刚恢复，FAL可能尚未激活）：
- 先手动查缺口：
SELECT * FROM V$ARCHIVE_GAP;，拿到LOW_SEQUENCE#和HIGH_SEQUENCE# - 若主库仍有对应归档，去主库
scp过来，放到备库LOG_ARCHIVE_DEST_1目录，再CATALOG START WITH '<path>'</path>注册 - 若主库归档已覆盖删除，必须用
RMAN> RECOVER STANDBY DATABASE FROM SERVICE <master_db_unique_name>;</master_db_unique_name>（19c专属命令），它会自动拉取缺失段并应用，无需提前停MRP、无需手动注册 - 最后才启用实时应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
最关键的细节藏在第二步：哪怕所有文件都完好，只要控制文件没被重新拉取或没执行CONVERT TO PHYSICAL STANDBY，备库就永远不是DG意义上的“备库”，只是个挂着旧身份的空壳。这点在闪回区被清空、spfile参数残留DB_UNIQUE_NAME指向错误实例时尤其容易忽略。
