跨平台迁移前须确认两端平台字节序一致（同为Little或Big），否则需用XTTS或Data Pump；数据库须READ ONLY并启用归档，字符集须兼容；CONVERT DATABASE不处理控制文件等，目标端需清理残留并校验路径；迁移后必执行catuppst.sql和utlrp.sql。
确认平台兼容性再动手
跨平台迁移失败，八成卡在字节序或平台不支持上。别急着 CONVERT DATABASE，先查 v$transportable_platform：
SELECT platform_name, endian_format FROM v$transportable_platform ORDER BY platform_name;
只有两端都是 Little 或都是 Big 才能直接用 RMAN 转换。Windows x64 和 Linux x64 通常都是 Little，但 AIX（Big）和 Linux（Little）就不可直转——这时必须走 XTTS 或 Data Pump。
常见坑：
• 忘记检查目标平台名拼写，比如把 Linux x86 64-bit 写成 Linux x86_64，CONVERT 直接报错 ORA-19624；
• 源库未启用归档模式，DBMS_TDB.CHECK_DB 会返回 FALSE；
• 字符集不兼容（如源库是 AL32UTF8，目标库是 WE8ISO8859P1），即使平台可转，后续打开也会卡在字符集校验。
只读 + CHECK_DB 是强制前置步骤
数据库必须处于 OPEN READ ONLY 状态才能调用 DBMS_TDB.CHECK_DB 和执行 CONVERT DATABASE。挂载后直接 open read only，不是 mount + open —— 后者会报 ORA-01109。
执行检查时注意两点：
• DBMS_TDB.CHECK_DB('Linux x86 64-bit') 返回 TRUE 才算通过，否则要查日志或 DBMS_TDB.TRANSPORT_SET_CHECK 的 transport_set_violations 视图找具体对象（如外部表、物化视图日志）；
• DBMS_TDB.CHECK_EXTERNAL 必须单独跑，它不报错不代表没外部对象——它只检查是否存在，不验证路径可达性。迁移后这些对象得手动重建或调整目录路径。
CONVERT DATABASE 命令的关键参数不能错
RMAN> CONVERT DATABASE NEW DATABASE 'orcl' TO PLATFORM 'Linux x86 64-bit' FORMAT '/u01/convert/%U';
这个命令实际干三件事：转换所有数据文件、生成目标端的控制文件脚本（crdb.sql）、生成参数文件模板。但容易忽略：
• FORMAT 路径必须在目标主机上提前建好且有写权限，RMAN 不自动创建目录；
• NEW DATABASE 是目标库名，不是实例名，它会写入生成的 crdb.sql 中的 CREATE DATABASE 语句；
• 不会转换控制文件、重做日志、密码文件、临时文件——这些全得在目标端手动处理；
• DB_FILE_NAME_CONVERT 参数在这里无效，它是用于 DUPLICATE 场景的，CONVERT DATABASE 用的是 FORMAT 定义输出位置。
目标端启动前必须清理残留结构
别直接 startup nomount 就跑 crdb.sql。目标主机上如果有同名实例残留（比如之前测试留下的 orcl），或者 $ORACLE_HOME/dbs 下存在旧的 spfileorcl.ora 或 initorcl.ora，会导致控制文件创建失败或参数冲突。
正确顺序是：
• 删除目标端所有旧数据文件、redo 日志、控制文件；
• 清空 $ORACLE_HOME/dbs 下与目标库名相关的文件（spfile、init、orapw）；
• 用 sqlplus / as sysdba 连接后，确保 ORACLE_SID 已设为目标库名，再执行 startup nomount；
• 运行 @/u01/convert/crdb.sql，它会创建控制文件并尝试 ALTER DATABASE OPEN RESETLOGS——此时若提示 “file not found”，大概率是 crdb.sql 里写的路径和你实际存放数据文件的路径不一致，得手动编辑该 SQL 文件修正 DATAFILE 子句。
最常被跳过的环节：迁移后第一次打开库，必须立刻运行 catuppst.sql（如果跨版本）和 utlrp.sql，否则很多内置包（如 DBMS_STATS）会失效。这不是“建议”，是 Oracle 官方文档明确要求的步骤。
