CONVERT DATABASE必须在OPEN READ ONLY状态下执行，否则报RMAN-06136或ORA-01126；TO PLATFORM值须严格匹配V$TRANSPORTABLE_PLATFORM；命令不生成控制文件，需手动重建并执行RECOVER；输出目录须提前创建且有写权限。
CONVERT DATABASE必须在OPEN READ ONLY状态下执行
直接报 RMAN-06136 或 ORA-01126？八成是状态错了。RMAN 需要从数据字典里读取表空间路径、文件名、块大小等元信息，这些只有在 OPEN READ ONLY 下才稳定可读。MOUNT 状态下运行会静默失败或报 RMAN-03002，提示模糊，容易误判为权限或路径问题。
正确顺序只能是：
SHUTDOWN IMMEDIATESTARTUP MOUNTALTER DATABASE OPEN READ ONLY
如果 OPEN READ ONLY 失败，说明还有活跃事务或未断开的应用连接，得先查 v$session 清理，不能跳过这步硬上。
TO PLATFORM值必须严格匹配V$TRANSPORTABLE_PLATFORM.PLATFORM_NAME
写错一个空格、大小写或连字符，就会报 RMAN-06004 或 ORA-19575。这不是拼写建议，而是硬性校验——Oracle 会逐字符比对，不支持模糊匹配。
查可用平台的唯一可靠方式是：
SELECT PLATFORM_NAME FROM V$TRANSPORTABLE_PLATFORM WHERE ENDIAN_FORMAT = (SELECT ENDIAN_FORMAT FROM V$DATABASE);
常见合法值示例（注意括号、空格、大小写）：
Linux x86 64-bitMicrosoft Windows x64AIX-Based Systems (64-bit)
非法写法（哪怕看着很像）：
-
linux x86_64（大小写错 + 缺空格 + 缺连字符） -
Windows x64（漏了Microsoft和完整后缀） -
Linux x8664-bit（数字连写，缺空格）
如果目标平台没出现在查询结果里，说明 Oracle 不支持该组合，别调参数、别换版本，直接放弃这条路。
CONVERT DATABASE不生成控制文件，必须手动重建
这是最常被忽略的致命点。命令输出只有转换后的 .dbf 文件、一个 crdb.sql 脚本和一个 PFILE，但没有控制文件、重做日志、临时文件、密码文件。目标库没控制文件就根本启不动。
推荐做法：
- 在源库用
BACKUP FOR TRANSPORT DATABASE替代CONVERT DATABASE，它会自动打包控制文件快照 + 转换脚本 - 若已用
CONVERT DATABASE，必须在目标端执行crdb.sql中的CREATE CONTROLFILE语句，并把所有DATAFILE和LOGFILE路径改成目标主机实际路径 - 重建后必须立刻执行
RECOVER DATABASE USING BACKUP CONTROLFILE，否则必然报ORA-01113或ORA-01244
漏掉 RECOVER 这步，等于拿一套 SCN 不对齐的文件强行启动，数据库会卡死在 mount 状态。
DB_FILE_NAME_CONVERT目录必须提前创建且有写权限
CONVERT DATABASE 命令里指定的输出路径（比如 FORMAT '/u01/convert/%U'），对应目录必须在执行前手动建好，且 Oracle 进程用户对该目录有读写权限。否则报 ORA-19504: failed to create file，不是磁盘满，而是权限或路径不存在。
实操要点：
- 提前在源库创建目标路径（即使只是临时存放，也得存在）
- 确认
oracle用户能touch该目录下的测试文件 - 路径中避免使用软链接，RMAN 不解析符号链接
- 若用 NFS 共享路径，确保挂载选项含
hard,intr，避免传输中断时 RMAN 卡住
跨平台迁移真正难的不是命令本身，而是每个环节都依赖前序步骤的精确完成——状态、平台名、控制文件、路径权限，四者缺一不可。任何一处偏差都会导致后续完全无法推进，且错误信息往往不指向真实原因。
