经验分享:XTTS迁移遇到过的坑

我们的文章会在微信公众号“Oracle恢复实录”和博客网站“www.htz.pw” 同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！ 由于博客中有大量代码，通过页面浏览效果更佳。

XTTS技术为Oracle 11.2.0.4版本中引入的新技术，此技术是在原来的TTS的技术之上通过扩展而来的。此技术为曾经的去I立下了汗马功劳，成为2015、2016年中跨平台迁移时常使用的技术。此技术也成为当时晋级或者面试时常常会问的一个。

上周跟一同事聊到XTTS遇到过的一些坑，下面把自己过去XTTS迁移时遇到的一些坑分享给大家。建议大家在使用XTTS前，先搜一下MOS，看看有哪些BUG，特别是一些BCT不生效、元数据导入慢、NFS写入异常等问题，有一些MOS能找到的BUG或者问题，就不在这次分享中了，比如:官方提供的pl报错这些。

• 1.表空间read only的时候，表空间上面不能存在事务，包括死事务，非常read only会一直hang着，等待锁。
• 2.增量备份时突然不使用BCT文件，比如之前增量备份都使用BCT文件，最后一次生成正式割接时，未使用BCT文件，导致增量备份做全库扫描，搜搜Mos是否存在BUG，如果不存在，可以采用将表空间read write，在read only，此时可能会解决问题（曾经遇到过一个案例这样解决的）。
• 3.导表元数据的时候，TEMP表是不导出的，需要后期手动导出。
• 4.导入表空间元数据时，表、索引、物化视图等有段的对象的定义最重要，其它信息可以排除，加快表空间元数据库导入的效率，因为其它的元数据可以在后期做数据校验过程中再导入。
• 5.注意索引状态，如果存在异常索引状态可能会跳过此索引。
• 6.源端如果没有安装xdb组件，导致xtts源数据无法导出报错大致如下，可以通过在导出parfile中增加exclude=xmlschema绕过该问题。

ORA-39126: Worker unexpected fatal error in KUPW$WORKER.UNLOAD_METADATA [PLUGTS_BLK]
ORA-00904: "Q"."TABOBJ_NUM": invalid identifier
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPW$WORKER", line 8358
 参考文档：Data Pump TTS Export Fails With ORA-39126 & ORA-904 (文档 ID 1273450.1)；

• 7.通常建议关闭延迟段创建特性，但需要在xtts迁移之后关闭，就算源端已经关闭延迟段创建，但是依然可能存在在关闭该功能之前创建的表，导致目标端导入源数据时部分table缺失无法正常创建，最终缺失部分table及index；在exp/imp来导入导出源数据不存在这个问题。或者通过allocte extend来手动分配段

• 8.源端与目标端延迟段创建特性均为缺省未关闭状态，依然可能出现部分索引缺失无法正常创建,，索引ddl语句中出现指定的tablespace名称为"_ 14 deleted 0"，最终导致索引无法正常创建

• 9.元数据导入，通过网络导入比写入本地dump文件的速度大概慢30%，建议采用落盘的方式。

• 10.目标端导入元数据测试时，不要使用闪回功能来闪回到导入之前的状态，因为闪回时，控制文件里面存在的数据文件全部都会被删除，所以这里建议采用使用备份与还原的方式来恢复目标库。

• 11.19c支持并行的元数据导入，但是在传输表空间时，network_link模式不支持并行。

• 12.导入dblink的时候需要注意，public的dblink不会导入。同时dblink在导入过程中，可能会报权限不足的错误，需要提前授权。

• 13.元数据导入过程中，可能会遇到跟dblink相关的对象创建时报对方服务器不存在或者无法连接，并且需要等待网络超时后才触发会报错，建议将超时时间从2分钟改到1秒。

• 14.在备库端做测试，当备库发生角色转换时，下一次的rman备份时不会使用BCT，自动使用全备，比如从physical standby转到snapshot standby时，下一次的rman backup scn 的备份是全备，不是增量备份。

• 15.在主库上增量备份时，可以继续使用前期在备库端做增量备份或者全量备份生成的相关配置文件，无需在主库做全量的备份，但是要求主库开启BCT功能的时间早于上次XTTS全备（可以在备库上）的时间。