RMAN TARGET / 在备库报 ORA-19573 是因备库控制文件为只读镜像、DB_UNIQUE_NAME 未在主库 RMAN 注册、且备库未处于 MOUNT 状态；须主库配置 CONNECTIDENTIFIER、备库用 standby 控制文件启动至 MOUNT 并 CATALOG 数据文件，方可执行 BACKUP DATABASE PLUS ARCHIVELOG。
不能直接在备库执行 RMAN TARGET / 就开始备份，因为 standby 控制文件是只读的、由主库生成的“镜像”，RMAN 默认不把它当独立可备份数据库看待。必须显式告诉 RMAN “这是谁”“连得上”“认得清文件”，三者缺一不可。
为什么 RMAN TARGET / 在备库会报 ORA-19573
ORA-19573 错误本质是 RMAN 试图以独占模式访问数据文件失败——它根本没识别出备库是个合法的备份源。原因有三层：
- 备库控制文件不是自己启动时生成的，而是主库传来的
standby controlfile，RMAN 默认拒绝信任它作为备份源头 -
DB_UNIQUE_NAME没在主库 RMAN 中注册，RMAN 不知道orcl_stdby这个别名对应哪个实例 - 备库处于 OPEN 状态（或未 MOUNT），而 RMAN 要求物理备库必须在
MOUNT状态下才能执行BACKUP DATABASE
必须在主库 RMAN 中配置 DB_UNIQUE_NAME 和连接标识
这步是前提，否则备库再怎么配监听、改 tnsnames 都白搭。主库 RMAN 必须提前“认识”备库：
- 执行
CONFIGURE DB_UNIQUE_NAME 'orcl_stdby' CONNECTIDENTIFIER 'orcl_stdby'; - 确保主库
tnsnames.ora里有orcl_stdby条目，指向备库监听地址和服务名 - 备库监听必须已注册该
DB_UNIQUE_NAME（可通过lsnrctl status确认服务名出现） - 如果用了恢复目录（强烈推荐），所有数据库都需注册进 catalog，且
DB_UNIQUE_NAME必须全局唯一
备库必须用 standby 控制文件启动到 MOUNT 状态
不能用 STARTUP 或 STARTUP OPEN，也不能用普通控制文件。正确流程是：
- 先
STARTUP NOMOUNT - 用主库生成的最新
standby controlfile恢复：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/';（文件系统）
注意：CATALOG START WITH 路径必须和 v$datafile 显示的实际路径一致；若用了 OMF + ASM，路径是系统生成的，别靠猜，先查视图。
BACKUP DATABASE PLUS ARCHIVELOG 在备库的实际含义
这不是备份“当前备库打开状态”，而是备份“主库某个 SCN 点的一致性快照”。关键点：
- 备份的是已应用到该 SCN 的全部数据文件，事务一致，但不包含尚未应用的归档日志
-
PLUS ARCHIVELOG是显式要求——不加就只备份数，不会碰归档；加了也只备份已在备库ARCHIVE_LAG_TARGET或LOG_ARCHIVE_DEST_n配置下落盘的归档 - 推荐写法：
BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;，避免归档堆积填满磁盘 - 备份集仍归属
DB_UNIQUE_NAME='orcl_stdby'，可在恢复目录中被主库识别并用于还原（物理备库间可交换，逻辑备库不行）
最易被忽略的是：备库控制文件本身不能靠 RMAN 备份来保障恢复能力——它必须从主库实时生成，任何 backup current controlfile for standby 都只是过期快照，主库结构一变，备份的控制文件就失效，还原后大概率触发 ORA-01122。
