非归档模式下rman全库备份必须在mount状态执行，因open状态下活动数据文件无法保证一致性，rman强制拦截并报ora-19602；唯一例外是控制文件和spfile备份。
非归档模式下 RMAN 根本不支持热备份 —— 这不是配置或权限问题，而是 Oracle 的强制设计限制。
ORA-19602 错误的本质原因
当你在 OPEN 状态下执行 BACKUP DATABASE，RMAN 立即报 ORA-19602: cannot backup or copy active file in noarchivelog mode。这不是检测失败，而是主动拦截：Oracle 明确拒绝为“活动数据文件”生成备份片，因为没有归档日志支撑崩溃恢复时的一致性校验。
即使数据库是只读打开（ALTER DATABASE OPEN READ ONLY），RMAN 仍判定为 “active”，同样触发该错误。控制文件和 SPFILE 是唯一例外，它们可单独在 OPEN 下备份（BACKUP CURRENT CONTROLFILE / BACKUP SPFILE）。
为什么 mount 状态就能成功？
进入 MOUNT 后，实例已启动、控制文件已加载，但数据文件未被 SMON 或 DBWn 打开写入 —— 此时所有数据文件处于静止、一致状态，RMAN 可以安全地逐块读取并打包。
- 必须用
SHUTDOWN IMMEDIATE，避免SHUTDOWN ABORT导致下次STARTUP MOUNT失败（需实例恢复但无归档日志） -
STARTUP MOUNT后检查SELECT STATUS FROM v$instance;，输出必须是MOUNTED，不是OPEN -
BACKUP DATABASE在此状态下会自动触发一次CONTROL FILE AND SPFILE AUTOBACKUP（默认开启）
backup database 不加 format 时备份写到哪？
很多人执行完 BACKUP DATABASE; 就找不到文件，是因为 RMAN 默认把备份片写进快速恢复区（FRA），路径由 DB_RECOVERY_FILE_DEST 参数决定，不是当前目录，也不是 $ORACLE_HOME/dbs。
查 FRA 路径：SHOW PARAMETER db_recovery_file_dest；若未配置或空间不足，会直接报 ORA-19809，而非 ORA-19602。
- 生产环境务必提前配好 FRA，或显式用
FORMAT指定路径，例如：BACKUP DATABASE FORMAT '/backup/orcl_%U.bkp'; - 若用默认 FRA，注意
DB_RECOVERY_FILE_DEST_SIZE必须设足够大，否则备份中途失败 - 备份完成后，用
LIST BACKUP查看Piece Name，确认实际落盘路径
异机恢复时最容易忽略的两个致命点
非归档模式冷备迁移后，在新机器上恢复，有两处不检查就必然失败：
- 没提前用
SET DBID xxxxxxxxx设置 DBID —— 如果连initorcl.ora都损坏了，STARTUP NOMOUNT后 RMAN 进入第一件事就是SET DBID，否则RESTORE CONTROLFILE FROM AUTOBACKUP找不到匹配备份片 - 控制文件恢复后执行
ALTER DATABASE MOUNT前，没确认数据文件路径是否真实存在 —— 若源库用 ASM 或路径不一致，必须先用CATALOG START WITH '/backup/path/';（结尾必须带/）注册物理文件，再SET NEWNAME映射
冷备的本质是“停写 + 静态拷贝”，所有操作都围绕一致性展开，任何跳过 mount、绕过 DBID、忽略路径映射的动作，都会让备份失去可恢复性。
