跨平台TTS迁移需严格验证字节序兼容性、正确书写transport_tablespaces参数、启用transport_full_check=y并预检、保持数据文件元信息完整，任一环节出错将导致失败。
跨平台 tts 迁移不是“改个参数就能跑”，必须确认字节序（endian）是否兼容，否则 impdp 会直接报 ora-19721 或 ora-19722 —— 这类错误根本不是配置问题，而是数据文件头校验失败。
怎么判断源和目标平台字节序是否兼容？
不查清楚就动手，90% 的失败都卡在这一步。别信“Linux 到 Linux 就一定行”，x86_64 和 ARM64 的 endian 可能不同。
- 在源库执行：
SELECT platform_name, endian_format FROM v$transportable_platform WHERE platform_name = (SELECT platform_name FROM v$database); - 在目标库执行同样语句，对比
endian_format字段值：都是Little Endian或都是Big Endian才算兼容 - 若不一致（比如源是
Linux x86 64-bit，目标是Solaris[tm] OE (64-bit)），必须用RMAN CONVERT转换数据文件，不能跳过
transport_tablespaces 参数写错，导出就退化成普通 expdp
这个参数不是可选的，也不是靠默认值生效的。漏写、少字母、多空格，expdp 就当没这回事，默默走逻辑导出流程，TTS 优势全丢。
- 正确写法只有这一种：
transport_tablespaces=USERS,EXAMPLE（逗号分隔，无空格，s不能少） - 常见错误：
transport_tablespace=USERS（少一个s）、transport_tablespaces=USERS EXAMPLE（空格代替逗号）、transport_tablespaces=USERS,（末尾逗号） - 即使只传一个表空间，也必须写全名：
transport_tablespaces=APP_DATA，不能简写或省略
transport_full_check=y 不是开关，是自包含性验证的强制触发器
设成 n 或干脆不写，expdp 会跳过依赖检查，但 impdp 时大概率崩在 ORA-39123，还得回源库补救，更耗时。
-
transport_full_check=y会调用DBMS_TTS.TRANSPORT_SET_CHECK，扫描跨表空间引用（如索引在 IDX_TBS、表在 DATA_TBS） - 执行前建议手动预检：
exec dbms_tts.transport_set_check('USERS,EXAMPLE', true); select * from transport_set_violations; - 查出记录的典型原因：外键指向其他表空间、LOB 段分离、分区表部分分区不在列表内、物化视图日志残留
- 注意：
transport_full_check=y期间会锁住相关表空间的 DML，务必安排在业务低峰期
数据文件拷贝后，别碰文件名和权限
TTS 依赖数据文件头里的 tablespace_id、dbid、creation_time 做校验。OS 层重命名、chmod、chown 都可能破坏这些元信息。
- 拷贝后只做两件事：确认目标端路径可读、确认文件大小与源端一致
- 禁止操作：
mv system01.dbf system.dbf、chmod 600 *.dbf、tar -xf解包后未校验 md5 - 如果用了
RMAN CONVERT，目标文件名由 RMAN 控制，不要手动改；RMAN 输出的转换后文件，必须用impdp指定DATAFILES参数显式引用
真正容易被忽略的是：跨平台 TTS 不是“导出+拷贝+导入”三步完事，而是一连串原子性依赖 —— 字节序不对，后续全废；transport_tablespaces 拼错，等于白忙；文件头被 OS 层动过，报错不告诉你哪里坏了。每一步都得有对应验证动作，不能凭经验跳过。
