rman convert database 必须在 open read only 状态下执行，因需读取稳定元信息；to platform 值须严格匹配 v$transportable_platform.platform_name；且必须手动重建控制文件，否则目标库无法启动。
RMAN CONVERT DATABASE 必须在 OPEN READ ONLY 状态下执行，否则直接报 RMAN-06136 或 ORA-01126，不是权限或路径问题，是状态错了。
为什么 CONVERT DATABASE 总是失败？
根本原因是数据库没进对状态。RMAN 需要从数据字典里读取表空间路径、文件名、块大小等元信息，这些只在 OPEN READ ONLY 下稳定可读。很多人卡在 RMAN-03002 + 模糊提示，其实是误在 MOUNT 下运行——CONVERT DATABASE 在 MOUNT 下根本不解析 DB_FILE_NAME_CONVERT 中的源路径。
正确顺序只能是：
SHUTDOWN IMMEDIATESTARTUP MOUNTALTER DATABASE OPEN READ ONLY
如果应用连接未断开、有未提交事务，OPEN READ ONLY 会失败，得先清理会话（比如查 v$session 并 ALTER SYSTEM KILL SESSION），不能硬上。
TO PLATFORM 值怎么填才不报 RMAN-06004
它不是操作系统简称，也不是你猜的缩写，必须一字不差匹配 V$TRANSPORTABLE_PLATFORM.PLATFORM_NAME 的返回值，大小写、空格、括号、连字符全敏感。
在源库执行：
SELECT PLATFORM_NAME FROM V$TRANSPORTABLE_PLATFORM WHERE ENDIAN_FORMAT = (SELECT ENDIAN_FORMAT FROM V$DATABASE);
返回结果里哪个值就用哪个。常见合法值示例：Linux x86 64-bit、Microsoft Windows x64；linux x8664-bit、Windows 64 全部非法。若目标平台不在结果中，说明 Oracle 不支持该组合，别试了。
CONVERT DATABASE 不生成控制文件，这点必须手动补
这是最常被忽略的致命点。CONVERT DATABASE 输出只有转换后的数据文件（.dbf）、一个 transport script（crdb.sql）和一个 PFILE，但没有控制文件、重做日志、临时文件、密码文件。
目标库没有控制文件就无法启动。必须手动重建，典型做法是：
- 用生成的
crdb.sql作为参考 - 在目标库上执行
CREATE CONTROLFILE RESETLOGS - 随后执行
RECOVER DATABASE USING BACKUP CONTROLFILE
若跳过这步，目标库启动时必然卡在 ORA-00205 或 ORA-01103。
迁移前必须做的两个检查
光靠状态和平台名还不够，漏掉这两步容易在目标库还原时崩溃：
- 用
DBMS_TDB.CHECK_DB('Linux x86 64-bit')检查数据库是否可传输：返回TRUE且无输出才表示通过；若有报错，得先处理外部对象、BFILE、目录等 - 用
DBMS_TDB.CHECK_EXTERNAL查外部依赖：它会把所有外部对象（如 directory、BFILE 路径）打出来，目标库必须提前建好对应结构，否则impdp或打开时会报ORA-29342
跨平台迁移不是文件搬运，是元数据+物理格式+启动机制三者对齐。最容易翻车的地方，往往不在命令本身，而在 OPEN READ ONLY 是否真生效、PLATFORM_NAME 是否抄错、以及控制文件那一步有没有亲手敲完。
