必须验证源库与目标库平台字节序兼容性，执行select platform_name, endian_format from v$database natural join v$transportable_platform；若不匹配，须用convert database或backup for transport中转，且备份必须含控制文件自动备份与plus archivelog。
确认源库与目标库的平台兼容性
RMAN跨主机迁移前必须验证源和目标平台是否属于同一字节序（endian format）。Oracle只允许在同 endian 平台间直接 restore，否则必须用 CONVERT DATABASE 或 Data Pump 中转。常见错误是把 Linux x86_64（little-endian）直接 restore 到 Windows IA（little-endian）看似可行，但实际需检查 DBA_DATABASES.PLATFORM_NAME 是否精确匹配，例如 'Linux x86 64-bit' 和 'Linux x86 64-bit (Big Endian)' 就不兼容。
执行以下查询确认：
SELECT platform_name, endian_format FROM v$database NATURAL JOIN v$transportable_platform;
若平台名不一致或 endian 不同，必须走转换流程——不是靠 RMAN 自动识别，而是显式调用 CONVERT DATABASE 或改用 BACKUP FOR TRANSPORT + RESTORE FOREIGN TABLESPACE。
备份阶段必须包含控制文件自动备份与归档日志
异机 restore 的成败关键不在数据文件本身，而在能否重建完整 SCN 链。只 backup database 不够，PLUS ARCHIVELOG DELETE ALL INPUT 是硬性要求，否则目标端 recovery 会卡在“找不到归档日志”。
-
CONFIGURE CONTROLFILE AUTOBACKUP ON必须启用，且格式路径要可写（如FORMAT '/backup/cf_%F'） - 备份命令中必须显式指定
ARCHIVELOG，不能依赖隐式归档备份 - 如果源库开启 FORCE LOGGING，目标端也要保持一致，否则某些 DML 可能跳过 redo 记录
典型安全备份脚本片段：
RMAN> RUN {<br> ALLOCATE CHANNEL c1 DEVICE TYPE DISK;<br> BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT;<br> BACKUP CURRENT CONTROLFILE;<br> RELEASE CHANNEL c1;<br>}
目标端还原时目录结构不一致必须用 SET NEWNAME
多数人失败是因为直接把备份拷过去就 run restore，结果报错 ORA-01180: can not create datafile 1 或 ORA-19870: error while restoring backup piece。根本原因是目标端路径与源端不一致，而 RMAN 默认按控制文件里记录的绝对路径找文件。
解决方式不是硬建一模一样的目录，而是用 SET NEWNAME 显式重定向：
- 先
STARTUP NOMOUNT，再RESTORE CONTROLFILE FROM '/backup/cf_*' - 然后
ALTER DATABASE MOUNT - 对每个数据文件执行：
SET NEWNAME FOR DATAFILE 1 TO '/u01/oradata/newdb/system01.dbf'; - 最后
SWITCH DATABASE TO COPY同步控制文件记录
注意：不要漏掉临时文件和 redo log 路径，它们不参与 restore，但 open 前必须用 ALTER DATABASE ADD LOGFILE 和 ALTER DATABASE TEMPFILE ... ADD 重建。
OPEN RESETLOGS 前必须完成完全恢复且无 gap
restore 完只是复制了块，recovery 才是让数据库回到一致状态的关键步骤。常见误操作是看到 RESTORE SUCCESSFUL 就急着 ALTER DATABASE OPEN，结果报 ORA-01113: file 1 needs media recovery。
正确流程是：
- 执行
RECOVER DATABASE——它会自动读取归档日志直到最后一个可用 SCN - 检查输出末尾是否出现
Media Recovery Complete - 运行
SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG WHERE NAME IS NOT NULL ORDER BY 2;确认所有归档都已应用 - 只有这时才能
ALTER DATABASE OPEN RESETLOGS
如果 recovery 报 “cannot find archived log”，说明备份集不全或传输过程中损坏，别强行 open，应重新核对 LIST BACKUP OF ARCHIVELOG ALL 输出。
