xtts迁移需分阶段手工驱动，tb级效率取决于前期检查、增量轮次设计及传输并行化；表空间自包含检查（dbms_tts.transport_set_check）是硬门槛，必须通过且修复所有transport_set_violations错误，否则导致失败或数据不一致。
XTTS 不是“一键迁移”工具，而是需要分阶段手工驱动的增量物理迁移流程；TB级迁移能否高效，取决于前期检查是否扎实、增量轮次是否合理、文件传输与转换是否并行化。
表空间自包含检查必须通过 dbms_tts.transport_set_check
这是所有 XTTS 迁移的硬门槛。哪怕只有一条违反记录，后续步骤都会失败或导致数据不一致。
-
transport_set_violations视图里出现ORA-39921（如分区表部分在 SYSTEM）、ORA-39906（跨表空间外键）、ORA-39908（索引在 SYSTEM）等错误，必须先修复：把 SYSTEM/SYSAUX 中的业务对象迁出，重建索引、调整分区默认表空间、解除跨表空间约束 - 检查时务必用
TRUE参数（EXEC dbms_tts.transport_set_check('TBS1,TBS2', TRUE)），否则不会检测依赖关系 - 不要跳过
dba_segments查询非系统用户在 SYSTEM/SYSAUX 的段，这类对象常被忽略，但会直接卡死元数据导入
XTTS 增量轮次不是越多越好，关键看 FROM_SCN 与归档压力
每次 xttdriver.pl -i 都会生成一个增量备份集，但频繁执行会导致源库归档暴增、RMAN 通道争抢、网络传输排队——反而拖慢整体进度。
- 首轮全量后，建议按业务低峰期做 2–3 轮增量：第 1 轮间隔 24 小时，第 2 轮间隔 8 小时，最后一次前滚前 1 小时内完成
- 每次增量前必须用
SELECT CURRENT_SCN FROM V$DATABASE记录当前 SCN，并确保下一轮xtt.properties中的scn值严格等于上一轮输出的TO_SCN（由xttplan.txt提供） - 如果源库归档生成速率 > 50 MB/s，建议调大 RMAN
MAXPIECESIZE（但注意：XTTS 要求DEVICE TYPE DISK不能启用压缩，所以增大单片大小比增加片数更稳妥）
目标端字节序转换和 ASM 写入必须分离路径与权限
XTTS 最容易卡在目标端：rmanconvert.cmd 执行失败、ORA-27054、ASM 文件写入超时，90% 源于路径配置或挂载问题。
-
stageondest和storageondest必须指向不同路径：stageondest是 NFS 或本地磁盘临时区（用于接收和转换），storageondest是 ASM 磁盘组路径（如+DATA），二者不可混用 - NFS 挂载必须带参数
rw,hard,intr,tcp,rsize=65536,wsize=65536,acregmin=0,acregmax=0；缺acregmin=0会导致文件属性缓存不刷新，rmanconvert.cmd读不到刚传入的文件 - 运行
xttdriver.pl的用户（通常是oracle）必须对stageondest有读写权限，且对 ASM 实例（如+ASM1）有 SYSASM 权限；否则RMAN CONVERT会报ORA-17628或连接 ASM 失败
xtt.properties 中的 parallel 和 rollparallel 不是越大越好
这两个参数控制 RMAN 并行度，但盲目设高会引发资源争抢，尤其在共享存储或 CPU 密集型环境里，实际吞吐可能下降。
-
parallel（全量导出）建议设为min(可用CPU核心数 × 0.7, 8)；超过 8 通常收益递减，还可能触发ORA-04030（内存耗尽） -
rollparallel（增量转换）建议 ≤ 4；因为增量文件小、数量多，高并行反而导致 I/O 随机化严重，NFS 或 ASM 写入延迟上升 - 必须同步检查 RMAN 配置：
SHOW CHANNEL DEVICE TYPE DISK应返回MAXOPENFILES 32以上，否则并行任务会被阻塞在等待文件句柄阶段
真正卡住 TB 级 XTTS 的，往往不是某个命令报错，而是某次增量后 xttplan.txt 里 TO_SCN 和目标端 V$DATABASE.CURRENT_SCN 差了 10 万以上——说明归档没传全或某次 rmanconvert.cmd 静默失败了。这种问题只能靠每轮后手动校验 SCN 对齐，没法靠脚本自动兜底。
