RMAN BACKUP AS COPY 必须在 MOUNT 或 OPEN 状态下执行，不可在 NOMOUNT 状态；非归档模式下迁移后需 RESETLOGS 打开，且无法回退至迁移前 SCN。
RMAN BACKUP AS COPY 必须在 MOUNT 或 OPEN 状态下执行
数据库不能处于 nomount 状态，否则 backup as copy 会报 ora-01507: database not mounted。归档模式不是强制要求，但如果数据库是 noarchivelog，迁移后必须用 resetlogs 打开，且无法回退到迁移前的 scn —— 这点常被忽略。
常见错误现象：
-
RMAN-03002: failure of backup command at ... ORA-19602: cannot backup or copy active file in NOARCHIVELOG mode—— 表示数据库未归档且有活动数据文件（如 temp、undo）正被写入 - 执行
backup as copy database后，部分数据文件未出现在目标路径 —— 很可能是控制文件里记录的路径未被DB_FILE_NAME_CONVERT覆盖，或路径映射不全
实操建议：
- 优先使用
OPEN状态迁移：可在线做，但需确保业务可接受短暂只读窗口（迁移期间可设ALTER DATABASE BEGIN BACKUP配合，不过 RMAN COPY 本身已隐含一致性保障） - 若必须用
MOUNT，先确认所有数据文件状态为ONLINE：SELECT name, status FROM v$datafile; - 对 RAC 环境，只启动一个实例到
MOUNT，其余实例必须关闭，否则 ASM 锁冲突导致 copy 失败
DB_FILE_NAME_CONVERT 参数必须成对且路径末尾一致
DB_FILE_NAME_CONVERT 不是通配替换，而是「源路径前缀 → 目标路径前缀」的严格字符串替换。它只作用于 BACKUP AS COPY 命令中未显式指定 FORMAT 的数据文件，且必须成对出现，否则 RMAN 会忽略该参数并把文件落到 FORMAT 指定路径（或默认 OMF 路径）。
例如，原路径是 /u01/oradata/ORCL/system01.dbf，想迁到 +DG_NEW，以下写法有效：
BACKUP AS COPY
DB_FILE_NAME_CONVERT ('/u01/oradata/ORCL/', '+DG_NEW/ORCL/')
DATABASE;
但这些写法会出问题：
-
DB_FILE_NAME_CONVERT ('/u01/oradata/', '+DG_NEW/')—— 若存在/u01/oradata/OTHERDB/，也会被误换，引发跨库污染 -
DB_FILE_NAME_CONVERT ('/u01/oradata/ORCL', '+DG_NEW/ORCL')（缺末尾斜杠）—— 替换后变成+DG_NEW/ORCLsystem01.dbf，路径非法 - 只写一个值：
DB_FILE_NAME_CONVERT ('/u01/oradata/ORCL/')—— 语法报错RMAN-00571
注意：DB_FILE_NAME_CONVERT 对控制文件、SPFILE、归档日志无效，它们必须靠 FORMAT 单独指定。
SWITCH DATABASE TO COPY 后必须 RECOVER，否则 OPEN 会失败
SWITCH DATABASE TO COPY 只是更新控制文件里数据文件的指针，不校验一致性。如果源库在 copy 过程中产生了新归档，或 copy 后又写了 redo，直接 ALTER DATABASE OPEN 会报 ORA-01113: file 1 needs media recovery。
正确顺序必须是：
BACKUP AS COPY ...SWITCH DATABASE TO COPY-
RECOVER DATABASE—— 它会自动应用 copy 时间点之后的归档（前提是归档可用且 CONTROLFILE 记录了对应信息） -
ALTER DATABASE OPEN RESETLOGS（仅当数据库是NOARCHIVELOG或做了不完全恢复时才需要；归档模式下通常用OPEN即可）
容易踩的坑：
- 在 RAC 中，
RECOVER DATABASE必须在单实例MOUNT下执行，多实例并行 recover 会报ORA-00600: internal error code - 如果迁移后忘记删旧路径文件，下次启动可能因 ASM diskgroup mount 顺序或权限问题，意外打开旧文件 —— 建议迁移完成后用
ASMCMD ls -l核对新路径，并手动rm旧 ASM 别名或 OS 文件
ASM 磁盘组迁移要同步更新 SPFILE 和 OCR 配置
单纯 copy 数据文件不够。控制文件、SPFILE、OCR 中仍存有旧磁盘组路径引用，下次重启或故障切换可能失败。
关键动作包括：
- 用
CREATE SPFILE='+NEW_DG' FROM PFILE重建 SPFILE，并用srvctl modify database -d <db> -p +NEW_DG/...</db>更新 OCR 中的 SPFILE 路径 - 修改
control_files参数指向新 ASM 路径，再用ALTER SYSTEM SET control_files='...' SCOPE=SPFILE持久化 - RAC 环境下，每个节点的
$ORACLE_HOME/dbs/init<sid>.ora</sid>中的SPFILE=...行也得同步改掉，否则 srvctl start 会加载错 SPFILE - OCR 备份必须在迁移后立即执行：
ocrconfig -manualbackup，否则故障时恢复可能指向旧存储
最易被忽略的一点：迁移完成后，V$ASM_DISKGROUP 里旧磁盘组的 STATE 可能还是 MOUNTED，但里面已无数据文件。别急着 DROP DISKGROUP，先确认 SELECT COUNT(*) FROM V$ASM_FILE WHERE GROUP_NUMBER = <old_group></old_group> 返回 0，再执行 drop —— 否则 RMAN 可能还在后台尝试访问已清空的磁盘组，导致 I/O hang。
