物理备库备份可在主库还原，因其与主库共享dbid、数据块结构一致，rman通过恢复目录绑定db_unique_name并自动重写路径；逻辑备库因sql apply改变数据块结构、dbid不同，rman无法识别其备份，故不兼容。
主备库之间 RMAN 备份能通用，但必须满足三个硬性条件：使用恢复目录（recovery catalog）、主备库 DB_UNIQUE_NAME 不同、且不能跨逻辑备库混用。
为什么物理备库的备份能在主库还原，而逻辑备库不行
物理备库与主库共享同一 DBID，只是 DB_UNIQUE_NAME 不同（比如 prod 和 standby1），RMAN 通过恢复目录把每个备份片和它的 DB_UNIQUE_NAME 绑定。还原时 RMAN 自动重写控制文件和数据文件路径，适配目标库环境。
- 逻辑备库使用 SQL Apply，底层数据块结构已改变，DBID 也不同，
LIST BACKUP查不到主库的备份记录 - 即使强行注册逻辑备库备份到同一恢复目录，
RESTORE DATABASE会报错ORA-19505: failed to identify a file - 物理备库上执行的
BACKUP DATABASE，在主库RESTORE时无需额外参数，RMAN 自动映射文件名
恢复目录是主备间备份通用的前提
不配置恢复目录时，RMAN 只依赖目标库控制文件存储备份元数据，而主备库控制文件彼此独立——你在备库备份完，主库控制文件根本不知道这个备份存在。
- 必须创建专用 catalog 用户，运行
CREATE CATALOG，再用REGISTER DATABASE分别注册主库和备库 - 注册后，所有备份操作（无论在哪台库执行）都写入该 catalog，
LIST BACKUP在任意注册库上都能查全 - 若误删某库控制文件又没 catalog，
RESYNC CATALOG会失败，只能靠RECOVER FROM REDO挣扎恢复元数据
备份交换时容易踩的坑
看似“备份通用”，实操中几个细节不处理就会卡在 RESTORE 阶段：
-
CONTROLFILE AUTOBACKUP必须开启，否则备库上做的备份不带控制文件，主库还原时找不到最新 SCN 位置 - 归档日志路径在主备库通常不同，RMAN 不自动重定位；需提前在目标库用
SET ARCHIVELOG DESTINATION或修改LOG_ARCHIVE_DEST_1 - 如果用
BACKUP AS COPY（映像复制），文件名和路径完全保留，必须手动SWITCH DATABASE TO COPY后才能RECOVER - 主库还原备库备份后，首次
OPEN RESETLOGS前要确认DB_RECOVERY_FILE_DEST路径可写，否则报ORA-19802
真正麻烦的不是技术限制，而是备份生命周期管理——比如主库删了 7 天前的归档，但备库还没应用完，这时用备库备份还原主库就会因缺少归档而中断恢复。这类问题不会报错在 RMAN 命令行，只会在 RECOVER DATABASE 阶段突然停住。
