备库无法自动回退已应用的误删操作，必须停MRP、用主库误删前的控制文件和归档做不完全恢复至目标SCN，再手动重建表空间并补全日志后重启MRP。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL 执行后，备库不会自动回退已应用的变更，也不会还原被主库误删的表空间——物理DG不支持“反向同步”或“逻辑回滚”。必须明确：**误删表空间不是同步中断，而是数据逻辑损坏；恢复目标不是“重新同步”，而是让备库回到一个主库仍存在的、一致的SCN点**。
为什么不能直接 RECOVER DATABASE 或重启MRP？
主库执行 drop tablespace ... including contents and datafiles 后，该操作会生成redo并传到备库。如果mrp正在运行，备库会照单全收，同样删掉对应数据文件（前提是路径可写、权限足够）。此时备库状态可能仍是 open read only 或 read write（adg），但内部已缺失该表空间所有数据文件，后续任何恢复命令都会报 ora-01157（无法识别数据文件）或 ora-01110（文件不存在）。强行 recover database 会卡在缺失文件上，rman报错 rman-06054 或 rman-06169。
确认表空间是否已在备库物理删除
登录备库，查两件事：
-
SELECT tablespace_name, status FROM dba_tablespaces WHERE tablespace_name = 'XXX';—— 如果返回空行，说明表空间元数据已删 -
SELECT name FROM v$datafile WHERE name LIKE '%xxx%';—— 如果无结果，且对应ASM磁盘组或文件系统里确实没该文件，确认物理丢失 - 检查告警日志关键词：
ORA-01157、ORA-01110、datafile not found
只要任一条件成立，就不可用“延迟应用”补救——因为延迟只是暂停MRP，不逆转已执行的DROP操作。
必须回退到误删前的SCN点
核心动作是：停MRP → 从主库拉取误删前的控制文件和归档 → 在备库做不完全恢复 → 重建缺失表空间。关键点：
- 先在主库查误删时间点对应的SCN：
SELECT SCN_TO_TIMESTAMP(123456789) FROM DUAL;或用FLASHBACK DATABASE TO TIMESTAMP ...反推（需主库开启闪回） - 用
BACKUP CURRENT CONTROLFILE FOR STANDBY从主库生成新控制文件，并拷贝到备库 - 确保主库保留了误删前的所有归档（
LIST ARCHIVELOG ALL确认SEQUENCE#连续且覆盖目标SCN） - 在备库执行：
RMAN> STARTUP NOMOUNT;<br>RMAN> RESTORE STANDBY CONTROLFILE FROM '/path/to/standby_controlfile.ctl';<br>RMAN> ALTER DATABASE MOUNT;<br>RMAN> RECOVER DATABASE UNTIL SCN 123456789;
- 恢复完成后，
ALTER DATABASE OPEN RESETLOGS会失败（物理DG不允许），必须保持MOUNT状态，再手动重建表空间
重建表空间后如何重新接回同步链路
不完全恢复后，备库处于MOUNT状态，且与主库SCN已对齐。此时不能直接启MRP，必须先补全被删对象：
- 若表空间含普通表：从主库导出（
expdp）再导入（impdp）到备库对应PDB/CDB，或用CREATE TABLESPACE ... DATAFILE ...手动重建并恢复数据文件 - 若使用ASM，注意
db_file_name_convert是否生效；路径不匹配会导致UNNAMED文件，需用ALTER DATABASE CREATE DATAFILE ... AS ...重定向 - 重建完成后，用
RECOVER DATABASE补齐从目标SCN到当前的归档（确保APPLIED='YES'的最新归档已注册） - 最后启动MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
整个过程最易忽略的是：误删操作本身不可逆，备库没有“后悔药”；所谓“延迟应用”只对尚未到达的redo有效，对已落地的破坏性DDL毫无作用。真正能救命的，永远是主库的归档保留策略和控制文件快照频率。
