Oracle DG环境中，RMAN备份与DG日志传输本质不同，备库RMAN备份默认对主库不可见，必须共用recovery catalog或统一控制文件，并共享存储路径、解除READ ONLY限制、同步保留策略，才能实现主备一致的备份恢复能力。
在oracle dg容灾方案中，**不能把rman备份和dg日志传输混为一谈，也不能默认认为开了dg就自动有了可恢复的备份**。rman备份是独立的数据副本，dg只是实时日志应用通道；没有显式配置备份策略和元数据同步机制，备库上执行的rman备份对主库不可见，主库也无法基于该备份做恢复。
RMAN备份必须显式注册到catalog或统一控制文件
ADG备库上运行RMAN时，默认只写入本地控制文件，主库控制文件完全不知道这些备份存在。一旦主库崩溃且无catalog，即使备库有完整备份集，RESTORE DATABASE也会报错找不到备份片（no backup or copy of datafile found）。
- 必须在主库和备库共用同一个
recovery catalog数据库，并在两边都执行REGISTER DATABASE - 若不用catalog，只能靠
CONTROL_FILE_RECORD_KEEP_TIME参数延长控制文件中备份记录的保留时间（默认7天），但跨库不可见问题依然存在 -
BACKUP ... PLUS ARCHIVELOG DELETE INPUT在备库执行时，归档日志会被删，但主库归档路径未同步清理，易引发归档缺失误判
ADG备库开启RMAN备份前必须解除READ ONLY限制
物理备库默认处于MOUNT或OPEN READ ONLY状态，而RMAN BACKUP要求数据库至少处于MOUNT状态——但OPEN READ ONLY下RMAN会拒绝启动备份（报错ORA-16004: backup database requires recovery或ORA-01159: file is not from the same database）。
- 正确做法：在备库执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL停掉MRP进程，再STARTUP MOUNT，此时才能运行BACKUP DATABASE - 备份完成后需重新启动MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT - 注意：
STARTUP MOUNT期间备库停止日志应用，RPO实际变为0，此窗口应尽量缩短
备份存储路径必须跨主备共享且权限一致
如果主库备份写/backup/primary，备库备份写/backup/standby，即使路径内容相同，RMAN也无法跨实例识别同一份备份集——因为DB_UNIQUE_NAME不同导致备份集DBID和DB_NAME校验失败。
- 推荐使用NFS或ASM共享目录，如
+BACKUP/rman或/shared/rman，主备均挂载为相同本地路径 - 确保
oracle用户在共享路径上有读、写、执行权限，否则RMAN分配channel时会卡在allocate channel阶段 - 避免在备库使用
FORMAT '/backup/%U'这种不含实例标识的路径，否则主库LIST BACKUP查不到该备份
备份保留策略在主备间不自动同步
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS这类命令只作用于当前连接的控制文件，主库设了不代表备库也生效。更麻烦的是，DELETE OBSOLETE在备库执行，只会删掉它自己控制文件里标记为过期的备份，而主库可能还在依赖这些备份。
- 务必在catalog中统一配置保留策略：
CONNECT CATALOG rman/rman@catdb; CONFIGURE RETENTION POLICY... - 禁用备库上的自动
DELETE OBSOLETE，改由主库统一调度清理，或通过脚本在catalog中查询RC_BACKUP_SET后人工判断 - 定期检查
V$BACKUP_SET和RC_BACKUP_SET中备份集状态是否一致，尤其关注STATUS = 'AVAILABLE'是否跨库同步
真正难的不是让RMAN在备库跑起来，而是让主备两端对“哪些备份存在、哪些还能用、哪些该删”达成一致认知。控制文件的局部性、DB_UNIQUE_NAME的隔离性、以及RMAN元数据的非广播特性，决定了这必须靠显式设计，而不是靠“开了DG就自动好了”这种直觉。
