内容来源：2017年3月11日，新炬网络高级工程师杨光在“DBAplus北京数据库技术沙龙”进行《深入浅出XTTS：Oracle数据库迁移升级利器》演讲分享。IT 大咖说（ID：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。
阅读字数：1781 | 4分钟阅读
获取嘉宾演讲视频回放及PPT，请点击：http://t.cn/EvLMeM3
摘要
通常我们要进行数据迁移，可以使用的方案有很多，比如数据泵、RMAN、GoldenGate，甚至是第三方同步软件DSG、DDS等。但是对于传统的迁移方式来说，数据量越大，需要的停机时间越长。增强版的XTTS支持了跨平台增量备份，使用增量备份的方式，可以将前期的数据文件传输、数据文件转换等操作在不中断业务的下操作。然后通过多次增量备份恢复，使源端和目标端的数据差异降到最小，最后业务停机时间只需要申请增量备份和恢复的时间即可。
XTTS是什么？
TTS是一种传输数据的手段，传输表空间，把表空间从一个库移到另一个库。但是对于传统的TTS来说，数据量越大，需要的停机时间越长。因此Oracle提供了一个加强版的XTTS，XTTS可以提供跨平台的增量备份，两者结合大缩减迁移时所需要停机时间。
适用场景
我们在做数据迁移的时候使用了三种手段。
第一种是数据泵。我们要做数据迁移的时候需要停止应用，数据没有更新才能保证所有业务表的一致性。在这个情况下使用数据泵进行导出，导出后进行传输，最后灌入。这种方式操作起来是最简单的，它适用的场景是在数据量比较小的情况下。
第二种方式是我们在做一些大型系统时，对它进行迁移的时候往往会使用Goldengate。Goldengate有一个好处就是停用时间很短。它在前期准备的时候做了数据的初始化，然后做数据的同步。在准备阶段数据是一直在传输的，只有当业务可以停机的时候，才会停止业务，切换到新的库上。
XTTS和Goldengate的方式比较像，它的前期也是要有一个准备，有数据初始化。后续是做增量的恢复，把初始化之后变更的数据使用增量的备份和恢复把之前的数据补上，到最后割接的时候把最后一次小增量补回来，这样来保证割接的时间比较短暂。
最短停机时间和最少的数据丢失是每个业务人员的诉求，上图是前面三种方式的对比。这三种方式都支持跨版本和跨平台，但不同的数据量会导致它们的停机时间不同。Goldengate的停机时间是最短的，因为它一直在不停地传输数据；数据泵的停机时间最长，它需要在停止业务之后再开始传输数据，其中有备份的时间、传输数据文件的时间和恢复的时间。而XTTS的停机时间则是介于Goldengate和数据泵之间。
TTS的基础操作步骤
A、将源端数据库表空间设置为READ ONLY模式。
B、传输数据文件到目标系统。
C、转换数据文件为目标系统的字节序。
D、在源端导出元数据，并在目标端导入。
E、将目标端的数据库表空间设置为READ WRITE。
XTTS的基础操作步骤
A、将源端数据文件传输到目标系统。
B、转换数据文件为目标系统的字节序。
C、在源端创建增量备份，并传输到目标端。
D、在目标端恢复增量备份。
E、重复多次操作C和D步骤。
F、将源端数据库表空间设置为READ ONLY模式。
G、最后一次执行C和D步骤。
H、在源端导出元数据，并在目标端导入。
I、将目标端的数据库表空间设置为READ WRITE。
XTTS每次恢复都需要重启？
pfile.ora
*.audit_file_dest='/home/u02/app/oracle/admin/xtt/adump'
*.db_name='xtt'
*.compatible='11.2.0.4.0'
*.db_block_size=16384
*.db_file_multiblock_read_count=64
*.db_files=8000
*.memory_target=21474836480
*.open_cursors=3000
*.processes=8000
*.undo_tablespace='UNDOTBS1'
如何加速XTTS
我们要考虑的是如何把最后增量的备份和恢复可控时间缩短到3个小时之内。
在停止业务的这段时间，要做的是表空间只读、增量备份恢复、元数据导入，最后是数据校验。表空间只读和数据校验的时间是固定的，关键的时间点是增量备份恢复和元数据的导入时间。
增量备份提速6小时→小时
alterdatabase enable block change tracking using file'/oradata/Oracle_change.trace';
selectstatus, filename fromv$block_change_tracking;
incrementalbackup的目的是只备份那些自上次备份以来发生过改变的block。然而，即使只有一小部分发生改变，incremental backup也要读取完整的数据文件。block change tracking功能解决了这个问题。它使用change tracking writer（CTWR）后台进程，在change tracking file文件中，记录所有数据库中变化的物理位置。启动block change tracking功能后，level 0级的incremental backup依然要扫描整个数据文件，因为change tracking file还没有映射到block的状态。对于后续级别的incremental backups，RMAN使用change tracking data决定哪些需要读取。通过消除对整个数据文件的read，提高了性能。
元数据导入加速
第一次导入
impdpdirectory=DESTDIR1logfile=tts_imp.lognetwork_link=ttslinktransport_full_check=yestransport_tablespaces=XXX
transport_datafiles='/XXX/xxx.dbf‘
exclude=statistics
第二次导入
impdpdirectory=DESTDIR1logfile=tts_imp_2.lognetwork_link=ttslinkschemas=XXX
content=metadata_onlyexclude=index,table,constraintparallel=8
将过程，视图，包，触发器，统计信息导入，开启并行。
迁移前的准备
迁移对象统计；
数据库字符集检查；
检查原环境是否存在空段；
失效对象检查；
基于XMLSchema的XMLType对象检查；
目标端创建检查用dblink；
检查源数据库和目标库具有重复名称的表空间；
检查是否存在应用用户建在system，sysaux，users上的情况；
表空间自包含检查；
比对新旧环境role；
比对新旧环境profile；
在新环境中比对并创建用户；
生成恢复用户默认表空间和临时表空间的脚本；
创建非默认的temp表空间；
生成为应用用户赋对象权限脚本；
软件包上传。
总结
XTTS支持扩字节序迁移，操作灵活简便，停机时间较短。迁移时尽量减少批次，操作越多越容易出错。
我今天的分享就到这里，谢谢大家！
