不能直接在备库连RMAN TARGET /备份，因DG备库控制文件为只读的standby控制文件，RMAN默认不信任其作为备份源，需先配置DB_UNIQUE_NAME、挂载standby控制文件并编目数据文件。
为什么不能直接在备库连 RMAN TARGET / 就开干
因为默认情况下，rman 会把备库当成“只读副本”，不识别其作为独立备份源的身份——它连不上控制文件、找不到数据文件路径、甚至报 ora-19573: cannot obtain exclusive enqueue for datafile。根本原因是：dg 备库的控制文件不是自己生成的，而是主库传来的“standby controlfile”，rman 默认不信任它做备份源头。
- 必须先用主库生成的 standby 控制文件启动备库到
MOUNT状态（不能OPEN） - 需在主库 RMAN 中显式配置备库的
DB_UNIQUE_NAME和连接标识，否则 RMAN 不知道“orcl_stdby”这个别名指向哪 - 如果用了 ASM + OMF，备库上
v$datafile显示的文件名是系统生成的，RMAN 编目时会不认识，得手动CATALOG START WITH或重建目录映射
怎么让 RMAN 认出备库是个可备份的“真·数据库”
核心动作就三步：告诉 RMAN “这是谁”、让它“连得上”、再“认得清文件”。缺一不可。
- 在主库 RMAN 中执行：
CONFIGURE DB_UNIQUE_NAME 'orcl_stdby' CONNECT IDENTIFIER 'orcl_stdby'; - 在备库上确保监听已注册该
DB_UNIQUE_NAME，且tnsnames.ora里有对应条目（比如orcl_stdby = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = stdby-host)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl_stdby)))） - 启动备库：
SQL> STARTUP NOMOUNT;RMAN> RESTORE STANDBY CONTROLFILE FROM '/tmp/std.ctl';SQL> ALTER DATABASE MOUNT STANDBY DATABASE; - 最后强制编目所有数据文件：
RMAN> CATALOG START WITH '+DATA/ORCL/';（ASM 场景）或CATALOG START WITH '/u01/oradata/orcl/';（FS 场景）
在备库执行 RMAN 备份时，BACKUP DATABASE 的实际行为是什么
它不是备份“当前备库状态”，而是备份“主库某 SCN 对应的一致性镜像”——也就是说，你备份的是一个已应用到某个归档点的、完整且事务一致的数据库快照。但要注意：它不会自动备份归档日志，除非你显式加 PLUS ARCHIVELOG，而这些归档日志必须已在备库本地落盘（ARCHIVE_LAG_TARGET 或 LOG_ARCHIVE_DEST_n 配置要到位）。
- 推荐命令：
BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;（删掉已备份的归档，防磁盘满） - 不加
PLUS ARCHIVELOG→ 只备份数据文件和 standby 控制文件，恢复时只能到最近一次归档应用点，无法前滚到最新 - 如果备库启用了
RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT（实时应用），那PLUS ARCHIVELOG实际备份的是刚接收但尚未应用的归档，安全但需确认归档路径可写 - 备份路径建议用共享存储（如 NFS 或 ASM 共享磁盘组），避免主备切换后备份集不可见
最容易被忽略的两个坑：保留策略失效 & 归档删除失控
很多人设了 CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;，结果发现旧备份没删——因为在备库执行的备份，RMAN 默认不把它们纳入主库 recovery catalog 的生命周期管理，除非你显式把备库也注册进 catalog 并用 CONNECT CATALOG 连过去。
- 不连 catalog 时，备库上的
DELETE OBSOLETE只看本地控制文件记录，而 standby 控制文件不记录主库产生的备份元数据，容易误删或漏删 -
DELETE INPUT要小心：如果归档还没传到其他备库或没被 catalog 记录，删了就真没了；建议先LIST ARCHIVELOG ALL;确认范围 - 主库若开了
ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;，而备库 RMAN 备份又删了归档，可能触发主库误判“归档已被应用”，导致主库提前删除自己的归档，断掉其他备库同步链
真正落地时，备库 RMAN 备份不是“抄个命令就能跑”，它本质是把 DG 架构里的角色权限、路径可见性、元数据归属全拉到前台来校验一遍。少配一个 CONNECT IDENTIFIER，或者忘了 CATALOG START WITH，备份集就可能是无效的。
