XTTS(Cross Platform TransportableTablespaces) 跨平台迁移表空间，它是 Oracle 8i开始就引入的一种基于表空间传输的物理迁移方法，命名为 TTS，经历各个版本的不断演进，从 11gR2 开始，在相对停机时间要求日益减少的情况，为了应对越来越大的数据量跨平台迁移，Oracle 推出了新的解决方案—加强版 XTTS（以下简称 XTTS），XTTS 使用增量备份的方式实现跨平台的数据迁移，从真正意义上大大缩短停机时间。在 U2L 如火如荼的今天，通过 XTTS 快捷、高效、平稳、安全的将 Oracle 数据库“小型机+集中式存储”环境迁移至“X86 架构平台+分布式存储”已然成为一大神技。
案例介绍
某省交管核心系统自上线运行6年以来，从最初 GB 为单位的数量级上升到今天 32TB 的业务数据量，其中照片信息的 LOB 字段占有 27TB，随着近几年信息化行业深化改革发展，信息化、互联网+、大数据已经成为交管业务支撑不可或缺的组成元素，但该系统却存在严重问题，已然不能满足现有业务的发展。为解决这套老旧的核心业务系统，通过调研，最终云和恩墨为客户采用 ZDATA 分布式存储方案，组建一个高速、安全、稳定的高性能分布式存储数据库架构，通过去除10年老旧 HPUX 机器，采用高配置的 X86 PC 服务器作为计算和存储节点，不仅提供强大的 CPU、IO、Memory 支持能力，还为后续的横向扩容存储提供不停机服务，可如何在有限的停机时间内进行这大批量的数据迁移成为本项目的一个难点。
1XTTS 概述
XTTS (CrossPlatform Transportable Tablespaces) 跨平台迁移表空间，是 Oracle 自10g推出的一个用来移动单个表空间数据以及创建一个完整的数据库从一个平台移动到另一个平台的迁移备份方法。它是 Oracle 8i 开始就引入的一种基于表空间传输的物理迁移方法，命名为 TTS，不过8i的表空间迁移仅支持相同平台、相同块大小之间的表空间传输，然而在那个年代还未像今天一样技术日新月异，TTS 的光芒一直被埋没在历史的尘埃里，从 Oracle 9i 开始，TTS 开始支持同平台中，不同块大小的表空间传输，这个时候很多数据库管理员就注意到了 TTS 在实际工作中的应用，不过由于每次移动表空间都需要停机、停业务，而9i的 TTS 只能在相同平台之间进行数据移动，相比 Oracle RMAN 本身的快捷方便，更多人更愿意选择使用 RMAN 进行数据备份、数据移动，基于这些原因，Oracle 10g 时代引入了跨平台的表空间传输方案 XTTS，标志着第一代 XTTS 的诞生。
如图一：TTS 和 XTTS 迁移对比图
在 Oracle10.1 中第一代 XTTS 是基于表空间的传输，到 Oracle 11gR1 后，跨平台数据的迁移可以支持传输表空间中的某个特定分区，不过在数据移动过程中，仍然需要将主库设置为 read only 只读状态、停机、停业务下才能进行数据迁移，对于业务不可间断的系统仍旧需要花费大量的停机时间才能达到跨平台物理迁移的效果，所以把 11gR2 以前的 XTTS 技术称作第一代 XTTS 技术。从 11gR2 开始，为了应对越来越大的数据量，相对停机时间要求日益减少的情况，Oracle 推出了新的解决方案—加强版 XTTS（以下简称 XTTS），使用增量备份方式的实现跨平台的数据迁移。从真正意义上讲，能够减少停机时间、进行增量备份的 XTTS，才真正是今天所说的 XTTS。
XTTS 各版本的功能比对如下，表一：XTTS 各版本功能比对表
| 版本说明 | 跨平台 | 不同块 | 增量备份 |
| Oracle 8i | |||
| Oracle 9i | √ | ||
| Oracle 10g | √ | √ | |
| Oracle 10gR2 | √ | √ | |
| Oracle 11gR1 | √ | √ | |
| Oracle 11gR2 | √ | √ | √ |
| Oracle 12c | √ | √ | √ |
2XTTS 迁移步骤
在 Oracle11gR2 以后，Oracle 推出了通过前滚数据文件，拷贝数据后再进行多次增量备份的 XTTS 来完成迁移过程，在这个过程中通过开启块跟踪特性，根据 SCN 号来执行一系列的增量备份，并且通过对块跟踪文件的扫描，来完成增量数据的增量备份应用，最后在通过一定的停机时间，在源库 read only 的状态下进行最后一次增量备份转换应用，使得整个迁移过程的停机时间同源库数据块的变化率成正比。这样大大的缩短了停机时间。
3XTTS 迁移方式
XTTS 是基于一组 rman-xttconvert_2.0 的脚本文件包来实现跨平台的数据迁移，主要包含 Perl script xttdriver 和 xttdriver Perl 脚本。Perl script xttdriver.pl 是备份、转换、应用的执行脚本，xtt.properties 是属性文件,其中包含XTTS配置的路径、参数。
采用 XTTS 迁移方式，具备跨平台字序转换和全量初始化加增量 merge 的功能，非常适用于异构 OS 跨平台迁移，成为数据库实施人员中公认的大数据量跨平台迁移的最佳选择。
传统的 TTS 传输表空间要求数据由源端到目标端传输的整个过程中，表空间必须置于 read only 模式，严重影响业务可用性。XTTS 方式可以在业务正常运行的情况下，进行物理全量初始化，增量 block 备份，数据高低字节序转码，增量 block 应用，保持目标端与源端数据的同步，整个过程不影响源端数据库使用。在最后的增量 block 应用完毕后，利用停机窗口进行数据库切换，显著地减少了停机时间。
rman-xttconvert_2.0 包参数说明如下表：
| 参数 | 意义 |
| tablespaces=TS1,TS2 | 需要传输的表空间 |
| platformid=2 | 源库的 platform_id，v$database 中得到 |
| srcdir=src1,src2 | 当使用 dbms_file_transfer 时使用，表示源库存放数据文件的路径 |
| dstdir=dst1,dst2 | 当使用 dbms_file_transfer 时使用，表示目标库存放数据文件的路径 |
| srclink=ttslink | 从目标端指向源端的 dblink，当使用 dbms_file_transfer 时使用 |
| dfcopydir=/storage | 源端用于存放数据文件的 copy，使用 rman 时使用 |
| backupformat=/storage | 源端用于存放增量备份的目录，无论哪种方式都需要设置 |
| stageondest=/storage | 目标端存放数据文件 copy 目录，和存放增量备份的目录 |
| storageondest=/oradata/prod/%U | 数据文件的最终存放点 |
| backupondest=/storage | 增量备份格式转换后的输出目录 |
| cnvinst_home= | 不同的增量转换目录使用的时候设置该参数 |
| cnvinst_sid | 不同中转 sid 使用的时候使用 |
| parallel=3 | 默认为3 |
| rollparallel=2 | |
| Getfileparallel=8 | 默认8，使用 rman 时的并行设置 |
方式一：dbms_file_transfer
DBMS_FILE_TRANSFER 包是 Oracle 提供的一个用于复制二进制数据库文件或在数据库之间传输二进制文件的程序包，在 XTTS 迁移中，利用不同的参数进行数据文件传输转换完成迁移。
方式二：RMANBackup
RMAN Backup 方式是基于 RMAN 备份原理，通过使用 rman-xttconvert_2.0 包提供的参数，对数据库进行基于表空间的备份，将备份生产的备份集写到本地或者 NFS 盘上，然后在通过 rman-xttconvert_2.0 包中包含的不同平台之间数据文件格式转换的包对进行数据文件格式转换，最后通过记录的表空间 FILE_ID 号生产元数据的导入脚本，通过 db_link 执行完成。
方式三：手工 XTTS 迁移
手工脚本执行 XTTS 迁移是云和恩墨根据 Oracle 提供的 rman-xttconvert_2.0 包迁移步骤从原理入手结合 dbms_file_transfer 和 rman backup 方式集合实际工作需求，手工编写的一套专门用于大数据量跨平台的表空间传输迁移脚本，整套脚本从源库、中间库、目标库三个方面详细的通过手工脚本的方式，把需要进行的迁移工作根据任务以及子任务的方式固化，形成一套可执行的迁移技术方案。
4XTTS 前置条件检查
前置条件
如前面概述所示，传输表空间技术从 Oracle8i 诞生，甲骨文公司经过多个版本的不停的改进完善，时至今日已经发展成为跨平台大数据量迁移的一大利器，尤其从 Oracle11.2.0.3 以后 XTTS 推出使用跨平台增量备份的方式，通过迁移不同字节序格式系统之间的数据，大大的减少了停机的时间，在方便的同时，看一看，使用 XTTS 进行数据迁移需要具备的那些前置条件？
如下表所示：
当然以上所说的目标端数据库版本均为11.2.0.4版本或者以上，如果在使用过程中，目标库的版本是11.2.0.3或者更低，那么需要创建一个单独的11.2.0.4版本数据库作为中间库来在目标端进行数据文件的格式转换，而使用 DBMS_FILE_TRANSFER 包目标端的数据库版本必须是11.2.0.4。
5XTTS 32TB 实战案例分享
实践是检验真理的唯一标志，为贴近实际，下面通过一个跨平台迁移32TB数据库的 XTTS 实战案例，来解析 XTTS 在大数据量迁移过程中的手工脚本应用情况，以下案例从 XTTS 原理出发，涉及操作系统、NFS 存储、rman 备份、系统字节序转换、数据验证以及网络知识。
系统现状评估
| 主机 | 生产库主库为3节点集群，其中2台为 HP 8640 |
| 存储 | HP XP24000 |
| 应用 | Websphere(大约20台主机，其中14台为HP小机环境，其他为 Windows 环境) |
| 数据库连接数 | 单节点连接数约为260-300 |
| 容灾备份 | 无容灾环境 |
| 数据容量 | 约32TB、使用的集中存储 XP24000 已经满了 无法扩容 |
A. 3节点 RAC 架构不合理
B. 集中存储使用10年以上、计算节点服务器设备老旧
C. 资源配置低
D. 数据爆发式增长
E. 业务应用模块增多、数据库表存放 LOB 字段
F. 物理扩容到达瓶颈
G. 基层业务人员反馈系统各种不好用
迁移需求分析
A. HPUX11.31 迁移到 Linux
B. 数据库总量 32TB
C. LOB 字段大小 27TB
D. 单个数据库表空间 17TB
E. 数据库版本11.2.0.3（无任何补丁）
F. 计划内停机切换时间8小时
G. 计划内完成时间15天
H. 数据库账号密码不能改变
I. 无应用测试(根本没有应用程序)
J. 无资源提供测试环境（存储、资源）
迁移方案选型
通过需求调研分析后，因系统涉及到30多 TB 数据量，并且业务停机时间只有8个小时，另外需要跨平台进行数据迁移，我方经过几次测试论证后，排除如下方案，在此也请各位思考一下，如果遇到此类需求作为 DBA 应该如何应对？
最终选择了最具挑战的 XTTS 来完成这次 32TB 的跨平台迁移挑战。
资源配置情况
| 配置类型 | 源 库 | 目标库 |
| 数据库版本 | 11.2.0.3 | 11.2.0.4.160419 |
| 数据库名称 | orcl | orcl |
| 数据库字符集 | AMERICAN_AMERICA.ZHS16GBK | AMERICAN_AMERICA.ZHS16GBK |
| 数据库节点 | RAC 3节点 | RAC 4节点 |
| 操作系统版本 | HPUX11.31 | Linux6.5 |
| 磁盘组大小 | 35TB | 80TB |
| 数据库大小 | 32TB | |
| Block size | 16384 | 16384 |
第一步：XTTS 环境检查
| 检查项 | 源 库 | 目标库 |
| 时区是否一致 | 时区为东八区 | 东八区 |
| 字符集是否一致 | 16GBK | 16GBK |
| 检查目标端补丁情况 | 无 | 需打最新PSU |
| 组件检查 | 包含源库组件 | |
| key compression索引组织表 | 存在 | 需手工重建 |
| 表空间规范检查 | 不同磁盘组下数据文件名称命名相同 | |
| TEMP表空检查 | 存在 | 需手导入 |
| 检查目标端的db_files参数 | 1024 | 4096 |
| 检查源端compatible参数 | 不可以是windows 且大于10.2.0 | 11.2.0.4 |
| 检查表空间自包含 | 存在自包含 需手工MOVE | |
| 用户， | DBLINK，PROFILE，PRIV | 需手工创建 |
第二歩：开启块跟踪
Block change tracking 进程记录自从上一次0级备份以来数据块的变化，并把这些信息记录在跟踪文件中。RMAN 使用这个文件判断增量备份中需要备份的变更数据。这极大的提高了备份性能和速度，RMAN 可以不再扫描整个文件以查找变更数据。
| SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ‘+SATADATA/changetracking.chg’;Database altered. |
第三歩：挂载 NFS 存储
NFS 存储挂载在源库和目标库之间，用于传输数据文件和增量备份节省数据文件的传输时间。
| mount -o llock,rw,bg,vers=3,proto=tcp,noac,forcedirectio,hard,nointr,timeo=600,rsize=32768,wsize=32768,suid 10.160.118.236:/dump1 /dump1 |
NFS 共享存储挂载说明:
源端，目标端需要挂载 35T 存储用于存放所有数据文件的镜像文件，建议使用 ntp 的方式将存储远程从源端挂载到目标端，减少备份传送时间，如下图 XTTS 迁移工作示意图—— NFS 存储初始化挂载
第四歩：SCN 确认记录
SCN（System Chang Number）作为 Oracle 中的一个重要机制，在数据恢复、Data Guard、Streams 复制、RAC 节点间的同步等各个功能中起着重要作用，在此需确认 SCN，且该 SCN 号用于后续增量备份的起始点。
| alter system checkpoint;select current_scn from v$database; |
第五歩：开始 RMAN Copy
基于数据文件的 RMAN COPY 生成的文件存放于挂载的 NFS 目录下。
| rman target / <<EOFrun{allocate channel c1 type disk;allocate channel c2 type disk;backup as copy datafile 18,19,20,21,22…….. format ‘/dump1/enmo/copy/enmo_%U’;release channel c1;release channel c2;}EOF |
第六歩：数据文件格式转换
A. Convert 用于转换数据文件的字节序
B. 转换后的新数据文件直接写入新环境的磁盘组
C. 转换过程消耗目标端的 CPU 资源
D. 此处需要关注目标端磁盘组的大小，避免造成磁盘组满引起转换失败
| convert from platform ‘HP-UX IA (64-bit)’ datafile ‘/dump1/ccm/vvstart_tabs.dbf’ format ‘+FLASHDATA/ORCL/DATAFILE/vvstart_new_01.dbf’; |
第七歩：增量备份阶段
A. 开启块跟踪后基于块进行快速增量
B. 增量备份前先查询并记录当前的 SCN
C. 根据全备时记录的 SCN1000 进行增备
D. 增量备份文件存放于 NFS 存储上
E. 增量备份后生成的字节序是 HPUX 的需进一步转换
| set until scn=1850backup incremental from scn 1000 datafile 18,19,20,21,22…… format ‘/dump1/enmo/incr/copy_%d_%T_%U’;3; |
| set until scn=1850backup incremental from scn 1000 datafile 18,19,20,21,22…… format ‘/dump1/enmo/incr/copy_%d_%T_%U’;3; |
第八步：增量转换应用
增量备份的转换和应用是两个过程，首先是增量备份集从 HPUX 平台转换成 Linux 平台格式，转换完毕后的备份集在 Linux 平台数据库才能识别。
| sys.dbms_backup_restore.backupBackupPiece(bpname => ‘/dump1/enmo/incr/copy_ORCL_20160707_78ra40o7_1_1’,fname => ‘/dump1/enmo/incr/copy_ORCL_20160707_78ra40o7_1_1_conv’,handle => handle,media=> media,comment=> comment, concur=> concur,recid=> recid,stamp => stamp, check_logical => FALSE,copyno=> 1,deffmt=> 0, copy_recid=> 0,copy_stamp => 0,npieces=> 1,dest=> 0,pltfrmfr=> 4); |
其次是增量备份集的应用，这个过程和 rman recover 的原理是一样的。
| sys.dbms_backup_restore.restoreBackupPiece(done => done, params => null, outhandle => outhandle,outtag => outtag, failover => failover); |
第九歩：循环进行增量备份
循环进行增量备份操作在正式环境的切割之前进行，其目的是为了减少最后一次数据库表空间 readonly 时生产环境的停机时间，需要特别注意的是操作之前务必查询并记录当前 SCN 号。这个 SCN 号是下一次开始增量备份的起点。
如图所示：
图十三：循环增量备份图
第十步：正式切割准备
正式切换的准备阶段是整个 XTTS 迁移过程中最重要的一步，为保证数据的一致性，需要在源库停止业务后，对活动的数据库会话进行查杀处理，并且在 read only 表空间之前需要进行几次检查点检查和 redo log 日志切换保证在无数据在内存的情况下才能进行下一步操作，另外针对计划窗口任务的 JOB 需要提前关闭 JOB 避免因 JOB 执行、批处理等导致数据不一致。
图十四：切割准备工作示意图
第十一歩：最后一次增量备份
最后一次增量备份是在生产源库表空间全部 read only 的情况下进行的，需要根据前一次记录的 SCN 号进行最后一次增量备份、转换、应用，在转换应用之后建议把新环境做一个闪回点或者进行一次全备。作为下一步导入元数据失败的回退方案。
如图所示：
图十五：最后一次增量备份示意图
第十二歩：元数据导入导出
A. 导出时排除系统表空间
B. 导出需在表空间 read only 下才能进行
C. 导入报错及终止
D. 导入可能会遇到 type 不存在的情况
E. 建议使用数据泵进行
如下表所示，在源库导出表空间的元数据
| exp \’/ as sysdba\’transport_tablespace=ytablespaces=’TBS_NAME’STATISTICS=nonefile=/dump1/enmo/exp/orcl_XTTS_0715.dmp |
根据导出的 dmp 包导入元数据
| imp \’/ as sysdba\’transport_tablespace=yTABLESPACES=’TBS_NAME’file=/dump1/enmo/exp/orcl_XTTS0715.dmplog=/dump1/enmo/exp/orcl_imp_XTTS0715.logdatafiles=(‘+FLASHDATA/orcl/datafile/VIO_DATA_u01′,’+FLASHDATA/orcl/datafile/base_image_fno65’) |
第十三歩：元对象导入导出
A. 开始导入之前先把表空间 read write
B. 可以使用 dblink 进行远程不落地导入
C. 指定需要的 schemas
D. 导入存在权限不足可进行手工授权
E. 导入完毕后即可开始验证
如下表所示：
| 1、迁移列表 schema 对象导入impdp “‘/ as sysdba'” metrics=yes network_link=ENMO_TEST schemas=VIO EXCLUDE=table,index content=metadata_only directory=enmo_exp logfile=imp_full_metadata_`date +”%d%H%M”`.log2、临时表导入3、组织索引表创建4、其他手工导入用户 |
第十四歩：数据校验收尾阶段
A. 统计信息收集或者导入
| EXEC DBMS_STATS.gather_schema_stats(‘DRV_ZW’, estimate_percent => 10,degree => 64); |
B. 无效对象重新检查编译
| sqlplus / as sysdba <<EOFDECLARE threads pls_integer := 150;BEGIN utl_recomp.recomp_parallel(threads);END;/ |
C. 对象数量比对
| select owner,object_type,count (*) from dba_objectswhere owner =’用户名称’group by owner,object_typeorder by owner,object_type; |
D. 主键索引核对
| select count(1),a.status from dba_constraints a where a.owner=’用户名称and a.constraint_type=’P’ GROUP BY A.status; |
E. 大表数据校验
| –num_rows行数验证select table_name,num_rows from all_tables where owner=’用户名称’ group by table_name,num_rowshaving num_rows>500 order by table_name;–大小验证 select owner, segment_name, bytes / 1024 / 1024 from dba_segments where segment_type = ‘TABLE’ and owner = ‘用户名称’; |
F. 账号权限、同义词验证
| Set lines 180Col object_name for a40select object_name,object_type,status from dba_objects where owner in (‘账号名称’) and status<>’VALID’; |
G. 数据文件头状态
| select STATUS,ERROR,TABLESPACE_NAME from V$DATAFILE_HEADER; |
H. 表空间校验
| 确认owner用户的DEFAULT_TABLESPACE, TEMPORARY_TABLESPACE 以及所有用户在相关表空间上的配额情况将之前创建的owner用户的默认表空间改为正确的默认表空间 |
I. 启动数据库
| 启动监听，应用开始连接测试srvctl start scan_listener删除测试用户信息：drop user enmoXTTStest cascade;drop public database link enmo_test; |
验证结果比对表如下：
| 数据校对项 | 结果 |
| 测试数据比对 | True |
| 迁移列表的表空间数量比对 | True |
| Schema数量比对 | True |
| 对象数比对 | True |
| 表记录数比对 | True |
| 包、函数、存储过程、索引等状态比对 | True |
| 权限比对 | True |
| 同义词比对 | True |
| 临时表数量比对 | True |
第十五歩：回退方案
触发条件：迁移切换失败进行
A. 前提条件：在不影响现有生产环境后续的可用性的情况下进行切换
B. 回退条件：仅需把源生产数据库表空间置换为 read write 、源库 JOB 进程调整为1000、源库监听启动
C. 回退时间：执行回退方案可保证在5分钟之内完成
D. 回退影响：本次切换失败
6XTTS 风险预估
A. 第一次全量备份消耗源生产库资源需关注
B. 全量备份挂载 NFS 会占用网络流量
C. 筛选排除系统表空间需认真仔细
D. 自包含检查需排除系统表空间
E. 使用exp导元数据可能会遇到 BUG 然后遇到 BUG 大神也救不了
F. 最后一次增量备份 read only 源库表空间可能会因活动会话占用 表空间 read only 过慢
G. 切换之前一定要先对目标库做一个 rman 全备 避免失败无法回退
H. 每次增量备份之前都需记录 SCN
7XTTS 总结
对于数据库的跨平台迁移，大家所熟悉的方法有很多，每种方法都各有利弊，关键还要看实际需求再来决定使用哪一种方式更能切合业务，提高工作效率，作为我个人而言，我比较喜欢采用物理迁移的方式，这样少了很多繁琐的数据校验过程，而且物理迁移或多或少能提高迁移速度，节省不少时间，尤其是面对超过十多个 TB 的数据库时，而这一章节向大家推荐的 XTTS 在面对 U2L 大数量迁移中更能发挥其优势，不过 XTTS 也是有很多不为人知的坑的，个人建议如果想使用好 XTTS 这个方法，需要对 XTTS 的原理非常熟悉，尽量采用手工脚本的方式来进行数据迁移，官方推出的 DBMS_FILE_TRANSFER 包由于 BUG 太多，在同步过程中经常会遇到很多莫名其妙的错误而中断，所以我不建议大家使用。对于 RMAN backup 的方式，因为本身 rman_xttconvert_2.0.zip 包是通过执行不同参数来自动的方式进行数据文件的拷贝、转换、应用以及增量等，需要大家对它的执行过程非常熟悉才不容易造成混乱，如果当您面对需要传输的表空间非常多的时候，建议还是采用手工的方式进行会比较保险。