备库不能直接执行RMAN TARGET /备份，因其控制文件为只读且标记STANDBY，RMAN拒绝识别；需先在主库配置DB_UNIQUE_NAME、确保监听与tnsnames.ora一致，再在备库挂载备用控制文件并强制编目数据文件后方可备份。
不能直接在备库执行 RMAN TARGET / 就开始备份，因为备库控制文件是只读的 standby 控制文件，RMAN 默认拒绝将其视作合法备份源——会卡在连接阶段或报 ORA-19573: cannot obtain exclusive enqueue for datafile。
为什么备库连不上 RMAN TARGET /
RMAN 不是“连不上数据库”，而是根本没打算信任这个备库：它发现控制文件里写着 STANDBY 标志、OPEN_MODE 是 MOUNTED、且没有自己的 DBID 注册记录，就直接判定“这不是个能自主备份的库”。更实际的问题是：v$datafile 路径在 ASM 下全是系统生成名（如 +DATA/ORCL/DATAFILE/SYSTEM.256.123456789），RMAN 在未编目前压根不认识这些路径。
让备库被 RMAN 认作合法备份源的三步动作
缺一不可，顺序也不能错：
- 在主库 RMAN 中显式声明备库身份：
CONFIGURE DB_UNIQUE_NAME 'orcl_stdby' CONNECTIDENTIFIER 'orcl_stdby'; - 确保备库监听已注册该
DB_UNIQUE_NAME，且tnsnames.ora有对应条目（不是随便起个 alias 就行，必须和CONNECTIDENTIFIER完全一致） - 在备库上用主库传来的 standby 控制文件启动到 MOUNT 状态：
STARTUP NOMOUNT→RESTORE STANDBY CONTROLFILE FROM '/path/to/std.ctl'→ALTER DATABASE MOUNT STANDBY DATABASE - 最后强制编目数据文件：
CATALOG START WITH '+DATA/ORCL/';（ASM）或CATALOG START WITH '/u01/oradata/orcl/';（文件系统）
备库执行 BACKUP DATABASE 的真实行为
它备份的不是“当前备库状态”，而是主库某个 SCN 点的一致性快照。这意味着：
- 不加
PLUS ARCHIVELOG，只备份数据文件，不包含归档日志 - 归档日志必须已在备库本地落盘（靠
ARCHIVE_LAG_TARGET或LOG_ARCHIVE_DEST_n配置保证），否则PLUS ARCHIVELOG会报找不到日志 - 推荐命令：
BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;—— 否则归档堆积极易填满磁盘
备库控制文件不能靠 RMAN 备份来保障恢复
哪怕你执行了 BACKUP CURRENT CONTROLFILE FOR STANDBY，得到的也只是静态快照。一旦主库新增表空间、重命名数据文件，这个备份就失效了，还原后大概率触发 ORA-01122 或 ORA-01110 —— 数据文件头与控制文件记录的 checkpoint 或文件名对不上。
真正可靠的备库控制文件，只能从主库实时生成并传输，不能依赖任何 RMAN 备份产物。
