必须用rman convert database，因跨平台时数据文件不兼容，需重写文件头、调整字节序和endianness；直接restore或拷贝会报ora-19505等错误，且convert必须在open read only状态下执行，平台名须严格匹配v$transportable_platform中的platform_name。
能直接迁移，但必须严格匹配平台字节序、Oracle版本和目录结构；跨平台或版本不一致时，CONVERT DATABASE 是绕不开的步骤。
RMAN备份文件怎么传到新服务器
备份集本身是二进制文件，传输过程不能解压、不能用普通FTP乱码模式、不能挂载NFS后直接改权限——这些都会破坏块校验。最稳妥的方式是：
- 用
scp -p（保留时间戳和权限）或rsync -avz逐个传输.bkp文件和控制文件备份（如cf_*.bkp） - 确认目标路径与源端
FORMAT中指定的路径逻辑一致，比如源备份用了FORMAT '/backup/%U'，新服务器就得有/backup/目录且 Oracle 用户有读写权限 - 别漏掉自动备份的控制文件：如果启用了
CONFIGURE CONTROLFILE AUTOBACKUP ON，它通常在$ORACLE_HOME/dbs或自定义路径下，得一并拷过去
目标服务器上恢复前要检查什么
很多人卡在 RMAN-06026: some targets not found 或 ORA-19822: invalid backup piece，往往不是备份坏了，而是环境没对齐：
-
ORACLE_SID和ORACLE_HOME必须与备份时一致；如果源库是orcl，新服务器也得设成orcl，否则 RMAN 找不到对应控制文件快照 - 检查
COMPATIBLE参数：目标实例的compatible不能低于源库（例如源是 12.1.0.2，目标至少设为'12.1.0'），否则RESTORE CONTROLFILE会失败 - 归档日志路径要提前创建好，尤其是
DB_RECOVERY_FILE_DEST指向的位置，RMAN 恢复过程中会尝试写入，权限不对直接中断
restore controlfile 后为什么 open 失败
常见现象是 ALTER DATABASE OPEN RESETLOGS 报 ORA-01139: RESETLOGS option only valid after incomplete database recovery，本质是控制文件里记录的 SCN 和数据文件头不匹配：
- 必须先
RESTORE DATABASE，再RECOVER DATABASE（含归档日志），最后才能OPEN RESETLOGS - 如果备份时用了
PLUS ARCHIVELOG DELETE INPUT，但传输过程中漏了某段归档，RECOVER就会停在缺失点；用LIST BACKUP OF ARCHIVELOG ALL核对归档日志序列号是否连续 - 跨平台迁移（比如 Linux → Windows）必须用
CONVERT DATABASE，否则即使 restore 成功，open 时也会报ORA-01200（文件大小不匹配）
真正麻烦的不是命令敲错，而是控制文件和数据文件的 SCN 链被断开——这种问题不会在 restore 阶段报错，要等到 open 才暴露，所以 RECOVER DATABASE 的输出里必须看到 “Media recovery complete”，才算真正过关。
