非归档模式下RMAN全库备份必须在MOUNT状态执行，因OPEN状态下活动数据文件无法保证一致性，RMAN强制拦截并报ORA-19602；唯一例外是控制文件和SPFILE备份。
backup database 在非归档模式下必须在 MOUNT 状态执行，否则会报 ORA-19602 错误。Open 状态直接运行该命令必然失败，这是硬性限制，不是配置或权限问题。
为什么不能在 OPEN 状态下执行 RMAN 全库备份？
非归档模式下，oracle 不允许对“活动数据文件”做一致性备份 —— 因为没有归档日志来保证崩溃恢复时的数据一致性。rman 检测到数据库处于 open 且 noarchivelog 时，会立即拒绝 backup database 请求，并抛出 ora-19602: cannot backup or copy active file in noarchivelog mode。
这不是 RMAN 的 bug 或限制疏漏，而是设计上的安全拦截：强制你先停写、再备份，确保备份集本身是事务一致的。
- 即使只读打开（
ALTER DATABASE OPEN READ ONLY）也不行 —— RMAN 仍视其为 active -
BACKUP AS COPY DATABASE同样受阻，本质相同 - 唯一例外是
BACKUP CURRENT CONTROLFILE或BACKUP SPFILE，它们不依赖数据文件活性
正确执行 RMAN 全库冷备份的步骤
核心是三步闭环：干净关闭 → mount → 备份。整个过程数据库不可用，属于真正的“冷备”。
- 用
SQL*Plus执行SHUTDOWN IMMEDIATE（避免ABORT，否则下次启动需实例恢复，可能失败） - 再执行
STARTUP MOUNT（注意不是OPEN；此时v$instance.status应为MOUNTED） - 用
rman target /连入，直接运行BACKUP DATABASE; - 备份完成后，RMAN 会自动触发一次
CONTROL FILE AND SPFILE AUTOBACKUP（默认开启），生成类似c-1234567890-20260515-01的文件
示例关键输出片段：
starting control file and spfile autobackup at 2026-05-15 09:22:33 piece handle=/u01/app/oracle/product/19c/dbs/c-1234567890-20260515-01 comment=NONE
容易被忽略的两个关键点
第一，DBID 必须已知才能还原控制文件或 SPFILE。如果连 initorcl.ora 都损坏了，startup nomount 会失败 —— 此时 RMAN 进入后第一件事不是 restore，而是 SET DBID xxxxxxxxx，否则 RESTORE CONTROLFILE FROM AUTOBACKUP 会找不到匹配的备份片。
第二，RMAN 默认备份路径是 $ORACLE_HOME/dbs（Linux）或 %ORACLE_HOME%\database（Windows），不是 FRA。若未配置 DB_RECOVERY_FILE_DEST，且 $ORACLE_HOME/dbs 空间不足，backup 会因写入失败而中断，错误提示可能是 RMAN-03009 + ORA-19502，而非 ORA-19602。
