在国内“去IOE”浪潮的席卷之下，整个行业快速向前演进，小型机转眼已成昨日黄花。IDC的《刀片服务器推动企业基础架构走向新IT时代》白皮书中指出：10年间，刀片服务器出货量由2005年的49.1万台增长到99.4万台，年复合增长率达到7.4%；中国x86刀片服务器市场出货量由2005年的0.9万台快速增长到2015年的12.2万台，10年间翻了10倍之多，年复合增长率达到29.2%，在2014年和2015年均占据销售额市场份额第一的位置。
随着x86架构服务器的迅速发展，企业从RISC架构服务器向x86架构服务器的转型也成为了潮流，即Unix to Linux，在行业里被简称为U2L。
那么，在U2L如火如荼的今天，如何快捷、高效、平稳、安全地将Oracle数据库“小型机+集中式存储”环境迁移至“x86架构平台+分布式存储”，如何将这些单库容量达到10TB级，甚至30TB、50TB的数据库在有限的停机时间内平稳、安全地迁移至x86服务器中，如何利用好每一个数据迁移工具的优缺点来达到方便、快捷、高效地完成数据库管理工作，是每个数据库管理员（DBA）需要认真思考的问题。
6.1 XTTS 概述
XTTS（Cross Platform Transportable Tablespaces，跨平台传输表空间），是Oracle自10g推出的用来移动单个表空间数据，以及创建一个完整的数据库从一个平台到另一个平台的迁移备份方法。
- XTTS源自Oracle 8i引入的一种基于表空间传输的物理迁移方法——TTS，不过8i的表空间迁移仅支持相同平台、相同块大小之间的表空间传输，然而在那个年代还未像今天的技术日新月异，TTS的光芒一直被埋没在历史的尘埃里。图6-1所示为TTS和XTTS迁移对比图。
- 从Oracle 9i开始，TTS开始支持同平台中，不同块大小的表空间传输，这个时候很多数据库管理员就注意到了TTS在实际工作中的应用，不过由于每次移动表空间都需要停机、停业务，而9i的TTS只能在相同平台之间进行数据移动，相比Oracle RMAN本身的快捷、方便，更多人更愿意选择使用RMAN进行数据备份和数据移动。
基于这些原因，Oracle 10g时代引入了跨平台的表空间传输方案XTTS，标志着第一代XTTS的诞生。
图6-1
在Oracle 10.1中第一代XTTS是基于表空间的传输，到Oracle 11gR1后，跨平台数据的迁移可以支持传输表空间中的某个特定分区，不过在数据移动过程中，仍然需要将主库设置为只读状态、停机、停业务下才能进行数据迁移，对于业务不可间断的系统仍旧需要花费大量的停机时间才能达到跨平台物理迁移的效果，所以把11gR2以前的XTTS技术称作第一代XTTS技术。
从11gR2开始，为了应对越来越大的数据量，相对停机时间要求日益减少的情况，Oracle推出了新的解决方案——加强版XTTS，使用增量备份方式实现跨平台的数据迁移。从真正意义上讲，能够减少停机时间、进行增量备份的XTTS，才真正是今天所说的XTTS。
XTTS各版本的功能对比如表6-1所示。
表6-1 XTTS各版本功能比对表
| 版 本 说 明 | 跨 平 台 | 不 同 块 | 增 量 备 份 |
|---|---|---|---|
| Oracle 8i | |||
| Oracle 9i | √ | ||
| Oracle 10g | √ | √ | |
| Oracle 10gR2 | √ | √ | |
| Oracle 11gR1 | √ | √ | |
| Oracle 11gR2 | √ | √ | √ |
| Oracle 12c | √ | √ | √ |
6.2 XTTS技术迁移应用场景
6.2.1 应用场景一：全国“去IOE”战略实施
所谓“去IOE”，是对“去IBM、Oracle、EMC”的简称，其中，IBM代表硬件以及整体解决方案服务商，Oracle代表数据库，EMC代表数据存储。我国很多领域的核心业务系统都运行在“IOE”的软硬件架构之上。
另外随着x86平台市场份额的不断扩大，以英特尔至强系列处理器为主导的服务器，在传统行业数据中心中的应用越来越广泛，同时通过降低硬件采购及功耗和散热成本，采购性价比与同等 RISC架构相比总体拥有成本也大幅降低。至此，U2L数据库迁移，即把数据库服务器从小型机迁移到x86平台，从UNIX操作系统迁移到Linux操作系统，成为当前最热门的趋势。那么如何在保证有限的停机时间内，完成大量数据的迁移成为各行各业在去“IOE”的路上必须要迈过的一道坎。
而Oracle 在11.2.0.4中提出了XTTS增量备份表空间传输的U2L迁移方式，成为当前为止在面对大批量数据中最高效、最安全的解决方案之一。U2L迁移示意图如图6-2所示。
图6-2
6.2.2 应用场景二：“云平台”数据中心建设
随着技术的发展，传统数据中心在多方面都面临挑战，加上大数据时代的来临，对传统数据中心提出了新的挑战，为了解决这一问题，随之出现了云数据中心。同时随着x86虚拟化技术的成熟，以x86架构为基础的服务器计算资源通过虚拟化配置资源池，形成云化平台，完成统一调度、集中计算，而传统小型机数据库迁移到x86架构的云平台使用XTTS迁移也成为最直接、有效的方式之一，如图6-3所示。
图6-3
6.2.3 应用场景三：老旧环境淘汰改造
随着我国信息化建设程度的深入，一批又一批老旧物理硬件设备已经达到使用年限，甚至一些核心系统的服务器处于脱保状态。从配置层面来看，更是呈现服务器配置低下、内存不足、资源过度利用等情况。而随着应用模块的增加，数据量也呈几何增长，业务需求变化快过市场需求的今天，业务逻辑的复杂度也呈现倍数增长。在当前这种传统系统架构落后、设备陈旧、数据安全无法得到保障的情况下，购买新的设备进行更新和升级无疑是大家从物理上解决性能瓶颈的办法之一。可面对昂贵的UNIX服务器成本，是选择买还是不买同样成为摆在决策者面前的两难选择，而x86平台的强势崛起，低成本、高性能的表现无疑更符合用户长远利益的选择。使用XTTS跨平台迁移UNIX到新架构x86同样也更符合停机时间短、迁移周期短、回退简单等要求。
6.2.4 应用场景四：数据库分布式存储重构
随着越来越多业务功能的上线，在今天的数据中心环境下，Oracle RAC（Real Application Clusters）等企业数据库系统正在发展成为高度集成的中央系统。 而RAC也面临数据库性能优化这一巨大挑战，性能瓶颈可能出现在网络和处理器等多个领域中，但最常见的来自于缓慢的硬盘驱动器。随着应用对更快的随机输入/输出需求不断地增加，这些机械硬盘驱动器更难满足这些需求。构造一套灵活的纯软件解决方案，充分利用基于PC服务器的内部直连式存储来创建一个虚拟的、可扩展的SAN，性能或优于外部传统光纤通道SAN，而成本和复杂性大幅度降低的分布式存储架构成为当今数据库重构的新方向，在节省物理硬件成本的开支外还能提高性能，其中XTTS在进行分布式存储重构实施中也能起到良好的作用，分布式存储重构解决方案如图6-4所示。XTTS利用RMAN 直接路径复制数据文件的方式，速度更快、性能更好地完成传统集中存储向分布式存储数据迁移。
图6-4
6.2.5 应用场景五：其他应用场景
可能的其他应用场景还包括跨平台恢复数据永久保存、数据仓库搭建、历史数据跨平台归档、非结构化数据迁移、单独表空间跨平台备份恢复等。
6.3 XTTS 迁移步骤
说了那么多XTTS在U2L之中的迁移应用场景，下面就从XTTS的迁移步骤出发，一步一步来了解使用XTTS进行表空间传输的整个迁移步骤。
首先通过图6-5来看一下Oracle 11gR2以前版本的XTTS典型的迁移步骤。
通过图6-5可以看出，在Oracle 11gR2以前使用XTTS迁移数据中是没有增量前滚这一步，必须在源库表空间完全只读状态下才能进行数据迁移。由于数据传输又必须在数据库启动中只读状态下来读取，另外整个迁移数据的过程是一个串行的步骤，所以此过程所需要的时间同数据库数据量的大小成正比。如果数据量很大，数据传输和转换的时间可能会很长。因此在Oracle 11gR2以后，Oracle推出了通过前滚数据文件，复制数据后再进行多次增量备份的XTTS来完成迁移过程。在这个过程中通过开启块跟踪特性，根据SCN号来执行一系列的增量备份，并且通过对块跟踪文件的扫描，来完成增量数据的增量备份应用。最后再通过一定的停机时间，在源库Read Only的状态下进行最后一次增量备份转换应用，使得整个迁移过程的停机时间同源库数据块的变化率成正比，这样大大缩短了停机时间。
如图6-6所示，可以把Oracle 11gR2以后版本的整个迁移过程分为7个阶段。
图6-5 XTTS迁移典型步骤
图6-6 XTTS迁移步骤图
6.4 XTTS 迁移方式
XTTS基于一组rman-xttconvert的脚本文件包（参考MOS 1389592.1）来实现跨平台的数据迁移，主要文件是Perl 脚本 xttdriver。xttdriver.pl是备份、转换、应用的执行脚本，xtt.properties则是属性文件，其中包含XTTS配置的路径、参数。
采用XTTS迁移方式，具备跨平台字序转换和全量初始化加增量Merge的功能，非常适用于异构OS跨平台迁移，成为数据库实施人员中公认的大数据量跨平台迁移的最佳选择。
传统的XTTS要求数据由源端到目标端传输的整个过程中，表空间必须置于只读模式，严重影响业务可用性。XTTS方式可以在业务正常运行的情况下，进行物理全量初始化、增量数据块备份、数据高低字节序转换、增量数据块应用、保持目标端与源端数据的同步，整个过程不影响源端数据库使用。在最后的增量数据块应用完毕后，利用停机窗口进行数据库切换，显著地减少了停机时间。
rman-xttconvert包参数说明如表6-2所示。
表6-2 xtt.properties参数说明
| 参 数 范 例 | 意 义 |
|---|---|
| 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时的并行设置 |
6.4.1 方式一：dbms_file_transfer
DBMS_FILE_TRANSFER包是Oracle提供的一个用于复制二进制数据库文件或在数据库之间传输二进制文件的程序包。在XTTS迁移中，利用不同的参数进行数据文件传输转换完成迁移。dbms_file_transfer参数示例如表6-3所示。
表6-3 dbms_file_transfer参数示例
| Subprogram 参数 | Description 描述 |
|---|---|
| COPY_FILE | 从源目录中读取一个文件并创建一个在目标目录的副本，源和目标目录都可以是本地文件系统，或是自动存储管理（ASM）磁盘组，或本地文件系统和ASM之间复制 |
| GET_FILE | 从远程数据库读取远程文件，然后创建一个本地文件系统中的文件副本或ASM |
| PUT_FILE | 读取本地文件或ASM和从远程数据库创建一个远程文件系统中文件的副本 |
dbms_file_transfer语法示例如表6-4所示。
表6-4 dbms_file_transfer语法示例
| 参 数 | 示 例 |
|---|---|
| COPY_FILE | BEGIN DBMS_FILE_TRANSFER.COPY_FILE(‘SOURCEDIR’,‘t_xdbtmp.f’, ‘DGROUP’, ‘t_xdbtmp.f’); END; |
| GET_FILE | BEGIN DBMS_FILE_TRANSFER.GET_FILE ( ‘df’ , ‘a1’ , ‘dbs1’, ‘dsk_files’ , ‘oa5.dat’ ); DBMS_FILE_TRANSFER.GET_FILE ( ‘dsk_files’ , ‘a2.dat’ , ‘dbs1’, ‘dsk_files’ , ‘a2back.dat’ ); END ; |
| PUT_FILE | BEGIN DBMS_FILE_TRANSFER.PUT_FILE ( ‘ft1_1’ , ‘a2.dat’ , ‘df’ , ‘a4.dat’ , ‘dbs2’ ) ; END ; |
注：如果数据库存在大量的表空间文件，那么使用dbms_file_transfer包来进行迁移是速度最快的。
6.4.2 方式二：RMAN Backup
RMAN Backup 方式是基于RMAN备份原理，通过使用rman-xttconvert包提供的参数，对数据库进行基于表空间的备份，将备份生产的备份集写到本地或者NFS盘上，然后再通过rman-xttconvert包中包含的不同平台之间数据文件格式转换的包对数据文件格式进行转换，最后通过记录的表空间FILE_ID号生成元数据的导入脚本，通过db_link执行完成。rman方式XTTS执行步骤如表6-5所示。
表6-5 rman方式XTTS执行步骤
| 使用阶段 | 脚 本 名 字 | 用 途 |
|---|---|---|
| 准备 | perl xttdriver.pl -p （源端） | 为了生成下述文件 |
| rmanconvert.cmd | Rman数据文件转化格式的命令 | |
| xttplan.txt | 记录scn号 | |
| perl xttdriver.pl -c （目标端） | 转换文件格式，直接到最终目录 |
续表
| 使用阶段 | 脚 本 名 字 | 用 途 |
|---|---|---|
| 增量前滚 | perl xttdriver.pl -i （源端） | |
| tsbkupmap.txt | 表空间对应增备 | |
| incrbackups.txt | 增备的备份集的路径 | |
| xttplan.txt.new | 记录新的scn号 | |
| perl xttdriver.pl -s （源端） | 将xttplan.txt.new替换xttplan.txt | |
| perl xttdriver.pl –r （目标端） | 应用增备 | |
| 传输阶段 | perl xttdriver.pl -e | 生成导入元数据的脚本 |
6.4.3 方式三：手工XTTS迁移
在实践中，可以总结提炼割接的步骤，创建手工脚本执行XTTS迁移，以加强自动化和迁移速度。以下总结了迁移的过程，可以把需要进行迁移的工作根据任务以及子任务的方式固化，形成一套可重复执行的迁移技术方案。
如表6-6所示是手工XTTS迁移说明（以实际生产为例），实践中可以参考这些步骤组织适合自己的流程和方法。
表6-6 手工脚本方式迁移准备
| 操 作 对 象 | 操 作 说 明 |
|---|---|
| 目标数据库安装配置 | 根据标准数据库安装手册进行数据库软件，数据库实例创建，配置参数 |
| 源库新监听创建 | srvctl add listener -l listener_1523 -p 1523 源端数据库创建监听用于远程访问数据比对的监听，此处用于正式切换时，源库生产监听停止，启用此新建的监听，使得其他无业不能连接 |
| 源库Dblink创建 | create user enmoXTTStest identified by “xxxxxxx”; grant dba to enmoXTTStest; 创建迁移切换数据一致性比对用户、DBLINK连接用户，权限为DBA权限 |
| 目标库Dblink创建 | 创建基于DBA权限用户的DB_LINK连接到源端，使用listener_1523 |
| 目标库其他配置 | 安全规范、性能参数配置，删除USERS表空间，新建一个默认的表空间 |
| NFS存储准备 | 一期NFS存储挂载用于数据初始化工作，二期NFS存储挂载用于增量备份 |
| 源库开启块跟踪 | 源端开启块跟踪，需关注块跟踪大小 ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ‘+SATADATA/changetracking.chg’; |
| 源库表空间自包含 | SELECT * from sys.transport_set_violations; |
| 源库获取用户相关环境信息 | 用户，DBLINK，PROFILE，PRIV |
| 源库临时表信息 | select o.owner, object_name, created from dba_objects o, dba_tables t where o.object_name = t.table_name and o.owner = t.owner and t.TEMPORARY = ‘Y’ order by 1, 3; |
续表
| 操 作 对 象 | 操 作 说 明 |
|---|---|
| 排除系统表空间 | select to_char(wm_concat(TS#)) from v$tablespace where NAME not in (‘UNDOTBS1’,‘SYSTEM’,‘SYSAUX’,‘TEMP’,‘UNDOTBS2’,‘UNDOTBS3’,‘UNDOTBS4’,‘XDB’,‘BASE’) and name not in (select distinct TABLESPACE_NAME from DBA_TEMP_FILES); |
| 源库准备rman 备份脚本 | 根据生成的TS#号制订出RMAN COPY脚本 |
| 执行rman copy脚本 | 分别在源库多个RAC节点发起RMAN 数据文件到NFS存储 |
| 准备数据文件转换脚本 | 根据NFS磁盘上复制数据文件完成后的结果，通过脚本拉取convert转换时所需要的执行脚本 |
| 执行数据文件格式转换 | 在目标库多个节点执行：RMAN CONVERT 将数据文件转成Linux平台，并存放在ASM里面 |
| 准备增量备份脚本 | 根据第一次RMAN COPY 确认过的SCN进行增量同步备份 |
| 获取增量转换清单 | 增量备份文件转换成Linux平台生成转换清单，增量转换文件到/dump/enmo/incr目录，生成增量备份转换的结果集存放到执行脚本中 |
| 应用增量备份 | 先将asmcmd中转换好的文件名作为列表存放在列表文件中，使用for循环读取，list文件名为apply_list.txt |
XTTS迁移割接步骤，如表6-7所示。
表6-7 手工脚本方式迁移切割步骤
| 操 作 对 象 | 操 作 说 明 |
|---|---|
| 源库 | 在业务停业务时，清理回收站数据 purge dba_recyclebin |
| 在业务停业务时，创建验证用户 create user enmo_test identified by xxxxxxx; conn enmo_test/xxxxxxxx 在业务停止后，创建数据验证表并插入验收数据 create table enmo_test(enmo_a number) insert into select lenvel from dual connect by lenve <1000; | |
| 修改JOB参数 | 停服务与修改JOB参数 alter system set job_queue_processes=0; |
| 监听 | 源库和目标库监听停止 srvctl stop listener -l listener srvctl stop listener -l listener_scan1 |
| 查杀活动进程 | 查杀进程，确认无活动事务与死事务，包括分布式事务 ps -ef|grep LOCAL=NO|grep -v grep|awk ‘{print $2}’|xargs kill -9 select local_tran_id,state from dba_2pc_pending ; KILL JOB进程 |
| 表空间只读状态 | 源库表空间置为read only 状态 |
| 增量备份转换应用 | 根据上一次增量备份SCN号进行最后一次增量备份转换并应用 |
| 源库元数据、元对象导出 | 在做增量备份的同时，做元数据、元对象导出exp、expdp |
| 创建用户 | 根据XTTS执行前收集到的用户信息创建用户 |
| 创建 database link | 根据XTTS执行前收集到的用户信息创建dblink |
| 目标库全备 | 备份数据库，用于回退 |
续表
| 操 作 对 象 | 操 作 说 明 |
|---|---|
| 目标库表空间读写模式 | 修改目标库表空间read write |
| 元数据导入 | 目标库导入传输表空间的元数据（imp、impdp） |
| 数据库可用性、验证数据验证 | 查询测试表是否有数据 |
| 业务核心数据验证 | 验证核心表的数据是否一致，核心表验证由开发、应用进行 |
| 元对象导入 | 二次导入（存储过程、试图等信息）导入数据库的元对象 |
| 设置默认表空间 | 将用户的默认表空间修改成原来的值 |
| 用户权限 | 给角色及对象授权 |
| 对象对比 | 迁移对象比对 |
| 编译无效对象 | 开启并行进程，编译无效对象 DECLARE threads pls_integer := 150; BEGIN utl_recomp.recomp_parallel(threads); END; / |
| 验证数据清理 | 删除测试表、数据验证用户、迁移使用的DBLINK |
| 统计信息导入 | 导入表与索引的统计信息，可以按schema或者对象来导入 |
| 数据量比对 | 对象数、表记录数 |
| 迁移contab内容 | 提前将crontab里面的脚本迁移到目标数据库 |
| 开启服务 | 业务确认没有问题后开启监听与启动服务 srvctl start service -d orcl -s |
| 收集字典表统计信息 不影响业务 | EXEC DBMS_STATS.GATHER_DICTIONARY_STATS; EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS; |
| 新库：打开JOB | alter system set job_queue_processes=1000; |
6.5 XTTS 前置条件检查
如本章前文概述所示，传输表空间技术从Oracle 8i诞生，经过多个版本的改进完善，时至今日已经发展成为跨平台大数据量迁移的利器，尤其从Oracle 11.2.0.3以后XTTS推出使用跨平台增量备份的方式，通过迁移不同字节序格式系统之间的数据，大大地减少了停机的时间。在方便的同时，来看一看使用XTTS进行数据迁移需要具备的前置条件，具体如下所示。
- 源库的操作系统不能是 Windows。
- 源库的 COMPATIBLE 参数必须设置为 11.1.0 或更高。
- 源库的 COMPATIBLE 参数值不能大于目标库的 COMPATIBLE 参数值。
- 源和目标库时区、字符集保持一致。
- 目标端db_files参数大于源库。
- 源库必须处于 ARCHIVELOG 模式
- 源库的 RMAN 配置里 DEVICE TYPE DISK 不能设置为 COMPRESSED。
- 要迁移的表空间的数据文件必须都是 online 或者不包含 offline 的数据文件。
- 排除系统表空间，避免冲突，并且检查业务表空间是否存在自包含。
当然以上所说的目标端数据库版本均为11.2.0.4版本或者以上，如果在使用过程中，目标库的版本是11.2.0.3或者更低，那么需要创建一个单独的11.2.0.4版本数据库作为中间库来在目标端进行数据文件的格式转换，而使用DBMS_FILE_TRANSFER包目标端的数据库版本必须是11.2.0.4。
迁移检查
基于以上这些条件，在开始XTTS迁移之前，需对整个实施环境进行一次全面的检查，保证在实施之前环境满足迁移要求。
（1）数据库时区检查，保持源库和目标库时区一致性。
select dbtimezone from dual;
DBTIME
------
+08:00
（2）数据库字符集检查，保持源库和目标库字符集一致性。
select * from nls_database_parameters where parameter like ‘%CHARACTERSET%’;
PARAMETER VALUE
NLS_CHARACTERSET AL32UTF8
NLS_NCHAR_CHARACTERSET UTF8
（3）数据库目标端补丁情况检查。
目标端psu根据数据库安装配置最佳实践规范配置安装最新PSU。
select ‘opatch’,comments from dba_registry_history
'OPATC COMMENTS
opatch PSU 11.2.0.4.4
使用dbms_file_transfer方法，在11g中目标端建议安装的补丁如下：
- Patch 19023822，修复目标端使用dbms_file_transfer.get_file包获取源端数据文件出现ORA-03106的情况。
- Patch 22171097: MERGE REQUEST ON TOP OF DATABASE PSU 11.2.0.4.6 FOR BugS 17534365 19023822。
如果准备阶段使用rman方法，目标端没有小补丁安装需求。
（4）检查目标库端数据库组件安装情况，需包含且多于源库组件。
源端组件：
COMP_NAME
----------------------------------------------------
Oracle Application Express
Oracle Multimedia
Oracle XML Database
Oracle Expression Filter
Oracle Rules Manager
Oracle Workspace Manager
Oracle Database Catalog Views
Oracle Database Packages and Types
JServer JAVA Virtual Machine
Oracle XDK
Oracle Database Java Packages
目标端组件：
COMP_NAME
--------------------------
Oracle Enterprise Manager
Oracle Workspace Manager
Oracle Database Catalog Views
Oracle Database Packages and Types
注：组件不同，可能会导致一些特殊的业务受到影响，需同开发、应用进行确认。
（5）检查是否使用了key compression的索引组织表。
Select index_name,table_name from dba_indexes where compression=’ENABLED’;
Select owner,table_name from dba_tables where iot_type is not null;
如果存在key compression的索引组织表，目标端需要安装patch 14835322，否则索引组织表无法导入到目标端，需要手动重建，或者通过手工方式导入。
（6）检查源端数据文件、表空间异常情况。
Select name from v$datafile where instr(name,’ ‘) > 0;
如果存在空格或者换行符数据文件，需要将该数据文件rename，否则在传输过程中会报错终止。如果存在同名表空间，而且该表空间中的对象需要传输，建议将目标端中的表空间rename，以避免冲突。
（7）检查相同表空间下是否存在不同目录下的同名数据文件。
使用dbms_file_transfer方式进行XTTS数据迁移，需要通过修改准备阶段的getfile.SQL和xttnewdatafile文件来调整数据文件生成的路径。
select substr(file_name,-6,2) from dba_data_files where tablespace_name=‘TBS_NAME’ order by 1;
如果目标端有多个目录，指定数据文件生成在不同的目录，可以避免冲突。
如果准备阶段使用rman方式进行同步，则所有的数据文件会转换为xtf结尾的文件，文件名会重新命名，所以不需要提前修改。
（8）检查表空间自包含。
在传输阶段，可能因为目标端数据文件目录所限制，需要将各个表空间拆分进行传送。在导入元数据阶段，考虑到字包含特性，需要将所有的表空间汇总进行传送。检查表空间时，只检查业务表空间的自包含情况，系统表空间、临时表空间、undo表空间不在检查列。因为在XTTS数据迁移时，无需对系统表空间、temp、undo进行传输，需要在目标端重建。
SQL>execute dbms_tts.transport_set_check(TBS_NAME ,TRUE);
SQL> SELECT * from sys.transport_set_violations;
no rows selected
（9）检查源端compatible参数。
源端不可以是Windows，源端的compatible.rdbms必须大于10.2.0，且不大于目标端compatible.rdbms。
show parameter compatible
如果目标端数据库版本是11.2.0.3或更低。那么需要在目标端安装11.2.0.4 并创建实例，然后用来进行备份集转换。如果11.2.0.4中转实例使用ASM，那么ASM版本也必须是11.2.0.4，否则报错ORA-15295。
（10）启用block change tracking（块跟踪）功能。
块跟踪功能，在源端数据量较大，或者数据改变较大时启用，需要在源库安装补丁Bug 16850197。该补丁在11.2.0.3.9和11.2.0.4版本psu中提供。如果源库是在上述版本前，需要安装个别补丁，注意块跟踪设置的目录大小，避免因块跟踪目录满而导致源数据库hang。
（11）检查目标端的db_files参数。
在元数据导入阶段，如果目标端的db_files参数小于源端的db_files参数，会导致元数据因无法关联创建数据文件而导入出错，所以要确保目标端参数大于或者等于源端。
Show parameter db_files
6.6 XTTS 最佳实践方案论证
6.6.1 技术方案概况
在不影响现有生产环境的前提下，缩短业务停机时间，搭建一套同平台的data guard数据库为中间库，通过XTTS迁移技术来完成生产环境跨平台到新环境的数据迁移。
6.6.2 技术方案实施步骤
（1）目标环境准备。
（2）搭建中间data guard环境。
（3）挂载NFS存储到老生产环境减少传输时间。
（4）通过XTTS RMAN COPY 中间DG数据库的数据文件。
（5）通过中间环境DG数据库进行增量备份。
（6）新环境进行增量转换、应用。
（7）正式切割时生产环境表空间read only。
（8）最后一次增量备份。
（9）导入导出元数据。
（10）数据校验。
6.6.3 技术方案模型
技术方案模型如图6-7所示。
图6-7
6.6.4 方案可行性说明
（1）采用Data guard中间环境作为XTTS前期准备阶段的源库，因DG数据库作为生产环境的备库同生产环境数据库版本一致、数据实时同步一致、操作系统环境一致，从环境要求方面符合XTTS迁移条件。
（2）采用中间环境来作为数据文件复制的源库，中间环境因是备库，可以在不影响业务的情况下进行备库停机。
（3）待投产新环境为11.2.0.4版本满足增强版XTTS数据库版本要求。
6.6.5 方案优缺点论述
使用这一方案的优缺点简要概括如下要点。
优点：备库操作不影响生产环境业务；备库复制数据文件不影响生产环境IO性能；增量备份可以在中间库进行多次，缩短停机时间；数据一致性能得到保障。
缺点：需准备中间库环境资源。
6.6.6 技术方案论证结论
通过搭建Data guard数据库作为中间库环境来进行XTTS迁移的方案，经过实际测试效果良好，不影响生产环境业务，且实施安全可靠，对缩短停机时间进行大批量数据迁移具备最佳实践效果，方案可行。
6.7 XTTS RMAN Backup步骤
（1）环境检查参照XTTS前置条件检查第二项迁移检查。
（2）创建db_link。
create public database link ttslink connect to system identified by ******
using '(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.111.118.103)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)
)
)’;
（3）XTTS执行脚本配置。
存放转换脚本
/home/Oracle/enmotest/xtt
存放执行脚本
/home/Oracle/enmotest/xtt-scripts
配置必要脚本
SCZXB[/home/Oracle/enmotest/xtt-scripts]$more xtt.properties
tablespaces=ENMOTEST_TABS—表空间名称
platformid=4 —平台代号
dfcopydir=/dump2/enmotest/rman_copy—数据文件复制存放的路径
backupformat=/dump2/enmotest/rman_incr—增量备份集存放的路径
stageondest=/dump2/enmotest/rman_incr----目标端存放数据文件复制目录和存放增量备份的目录
storageondest=+FLASHDATA/orcl/DATAFILE—目标端数据文件转换后的最终目录
backupondest=/dump2/enmotest/rman_incr----备份文件转换后生成的目录
（4）源库发起rman copy。
–源端进行第一次rman copy数据文件
perl /home/Oracle/enmotest/xtt-scripts/xttdriver.pl -p
（5）目标库复制生成脚本。
在目标端，通过Oracle用户复制源端/home/Oracle/enmotest/xtt/rmanconvert.cmd到目标端的/home/Oracle/enmotest/xtt目录下。
scp source:/home/Oracle/enmotest/xtt/rmanconvert.cmd dest:/home/Oracle/enmotest/xtt
（6）目标端进行转换。
----目标端进行转换
perl /home/Oracle/enmotest/xtt-scripts/xttdriver.pl -c
（7）源端增量备份。
cd /home/Oracle/enmotest/xtt-scipts
perl xttdriver.pl -i
结束会生成一个新的记录scn的文件：xttplan.txt.new。
（8）复制生产文件后转换应用。
将tsbkupmap.txt xttplan.txt传到目标端/home/Oracle/enmotest/xtt，将incrbackups.txt传到目标端/dump2/enmotest/rman_incr。
cd /home/Oracle/xtt
cp incrbackups.txt /dump2/enmotest/rman_incr
cp xttplan.txt tsbkupmap.txt /dump2
目标端开始应用增量备份：
cd /home/Oracle/enmotest/xtt-scritps
perl xttdriver.pl -r
（9）确定新的scn。
perl xttdriver.pl -s
该步骤会将-i时生成的xttplan.txt.new改名为xttplan.txt，并将原来的xttplan.txt备份。
（10）源库read only 进行最后一次增量备份。
–源库表空间read only
alter tablespace ENMOTEST_TABS read only;
–最后一次增量备份
perl xttdriver.pl -i
将tsbkupmap.txt xttplan.txt传到目标端/home/Oracle/enmotest/xtt
将incrbackups.txt传到目标端/dump2/enmotest/rman_incr
cd /home/Oracle/xtt
cp incrbackups.txt /dump2/enmotest/rman_incr
cp xttplan.txt tsbkupmap.txt /dump2
cp xttplan.txt tsbkupmap.txt /home/Oracle/enmotest/xtt
（11）应用增量备份，完成最后一次增量恢复。
cd /home/Oracle/xtt-scripts
perl xttdriver.pl -r
（12）元数据导入脚本生成。
–目标端运行
cd /home/Oracle/xtt-scripts
perl xttdriver.pl -e
（13）目标端创建用户。
–目标库先创建用户，并且权限同源库一样
create user enmoXTTStest identified by ********* default tablespace USERS;
（14）导入元数据。
impdp ‘/ as sysdba’ directory=DATA_PUMP_DIR logfile=tts_imp.log network_link=ttslink transport_full_check=no transport_tablespaces=ENMOTEST_TABS transport_datafiles=’+ FLASHDATA/orcl/datafile/enmotest_tabs_1024.xtf’
（15）数据验证。
应当根据数据特点，定制脚本、程序，进行基本的数据验证。
6.8 XTTS 实战案例分享
实践是检验真理的唯一标志，下面通过一个跨平台迁移32TB数据库的XTTS实战案例，来解析在大数据量迁移过程中的手工脚本应用情况。以下案例从XTTS原理出发，涉及操作系统、NFS存储、RMAN备份、系统字节序转换、数据验证以及网络知识。
6.8.1 案例现状介绍
某省交管核心系统自上线运行6年以来，从最初GB为单位的数量级上升到今天32TB的业务数据量，其中照片信息的LOB字段占有27TB。随着近几年信息化行业深化改革发展，信息化、互联网+、大数据已经成为交管业务支撑不可或缺的组成元素，但该交管局核心系统却存在严重问题，已然不能满足现有业务的发展。为解决这套老旧的核心业务系统，通过调研，最终确定为客户采用zDATA分布式存储方案。组建一个高速、安全、稳定的高性能分布式存储数据库架构，通过去除老旧HP机器，采用高配置的X86 PC服务器作为计算和存储节点，不仅提供强大的CPU、I/O、Memory支持能力，还为后续的横向扩容存储提供不停机服务，可如何进行这大批量的数据迁移成为本项目的一个难点。
6.8.2 系统现状评估
系统资源配置如表6-8所示。系统现状评估如图6-8所示。
表6-8 系统资源配置表1
| 主 机 | 生产库主库为3节点集群，其中2台为HP 8640 |
|---|---|
| 存储 | HP XP24000 |
| 应用 | Websphere（约20台主机，14台为HP小机，其他为Windows环境） |
| 连接数 | 单节点连接数为260～300 |
| 容灾备份 | 无容灾环境 |
| 数据容量 | 约32TB，集中存储HP XP24000已经满了，无法扩容 |
图6-8
该系统存在的问题还包括以下情况：3节点RAC架构不合理；集中存储使用10年以上、计算节点服务器设备老旧；资源配置低，物理扩容到达瓶颈；数据爆发式增长；业务应用模块增多、数据库表存放LOB字段；基层业务人员反馈系统各种性能问题。
6.8.3 迁移需求分析
系统迁移面临的问题主要有如下情况：HP-UX跨平台迁移到Linux；数据库总量为32TB，LOB数据大小为27TB；单个数据库表空间为17TB；数据库版本为11.2.0.3（无任何补丁）；计划内停机切换时间为8小时；计划内完成时间为15天；数据库账号密码不能改变；无应用测试；无资源提供测试环境（存储、资源）。
如何设计方案，解决这些挑战，是项目实施中的重要内容。
6.8.4 迁移方案选型
如图6-9所示，通过需求调研分析后，因系统涉及30多TB数据量，并且业务停机时间只有8个小时，另外需要跨平台进行数据迁移。我方经过几次测试论证后，排除如下方案，在此也请各位思考一下，如果遇到此类需求作为DBA应该如何应对。
图6-9
最终选择了最具挑战的XTTS来完成这次32TB的跨平台迁移挑战。迁移前后的资源配置情况如表6-9所示。
表6-9 系统资源配置表2
| 配 置 类 型 | 源 库 | 目 标 库 |
|---|---|---|
| 数据库版本 | 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 | |
| 块大小 | 16384 | 16384 |
6.8.5 迁移的具体实施
在以下的描述中，我们再现了生产过程中的实战步骤，供读者在学习和实践中参考。
（1）XTTS环境检查，如表6-10所示。
表6-10 XTTS环境检查表
| 检 查 项 | 源 库 | 目 标 库 |
|---|---|---|
| 时区是否一致 | 时区为东八区 | 东八区 |
| 字符集是否一致 | 16GBK | 16GBK |
| 检查目标端补丁情况 | 无 | 需打最新PSU |
| 组件检查 | 包含源库组件 | |
| key compression索引组织表 | 存在 | 需手工重建 |
| 表空间规范检查 | 不同磁盘组下数据文件名称命名相同 | |
| TEMP表空检查 | 存在 | 需手导入 |
| 检查目标端的db_files参数 | 1 024 | 4 096 |
| 检查源端compatible参数 | 不可以是windows 且大于10.2.0 | 11.2.0.4 |
| 检查表空间自包含 | 存在自包含 需手工MOVE | |
| 用户 | DBLINK，PROFILE，PRIV | 需手工创建 |
（2）开启块跟踪。
Block change tracking进程记录自从上一次0级备份以来数据块的变化，并把这些信息记录在跟踪文件中。RMAN使用这个文件判断增量备份中需要备份的变更数据。这极大地提高了备份性能和速度，RMAN可以不再扫描整个文件以查找变更数据。
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ‘+SATADATA/changetracking.chg’;
Database altered.
（3）挂载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
源端、目标端需要挂载35TB存储用于存放所有数据文件的镜像文件，建议将存储远程从源端挂载到目标端，减少备份传送时间。图6-10所示为XTTS迁移工作示意图-NFS存储初始化挂载。
图6-10
（4）SCN确认记录。
SCN（System Chang Number）作为Oracle中的一个重要机制，在数据恢复、Data Guard、Streams复制、RAC节点间的同步等各个功能中起着重要作用，在此需确认SCN，且该SCN号用于后续增量备份的起始点。
alter system checkpoint;
select current_scn from v$database;
（5）开始RMAN Copy。
基于数据文件的RMAN COPY生成的文件存放于挂载的NFS目录下。
rman target / <<EOF
run{
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
rman backup工作示意图如图6-11所示。
（6）数据文件格式转换。
Convert 用于转换数据文件的字节序，转换后的新数据文件直接写入新环境的磁盘组，转换过程消耗目标端的CPU资源，此处需要关注目标端磁盘组的大小，避免造成磁盘组满引起转换失败，如图6-12所示。
convert from platform ‘HP-UX IA (64-bit)’ datafile ‘/dump1/ccm/vvstart_tabs.dbf’ format ‘+FLASHDATA/ORCL/DATAFILE/vvstart_new_01.dbf’;
图6-11
图6-12
（7）增量备份阶段。
开启块跟踪后基于块进行快速增量，增量备份前先查询并记录当前的SCN，根据全备时记录的SCN进行增备（假定记录的SCN是1000），增量备份文件存放于NFS存储上，增量备份后生成的字节序是HP-UX的需进一步转换。
set until scn=1850
backup incremental from scn 1000 datafile 18,19,20,21,22… format ‘/dump1/enmo/incr/ copy_%d_%T_%U’;3;
（8）增量转换应用。
增量备份的转换和应用是两个过程，首先是增量备份集从HP-UX平台转换成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 恢复的原理是一样的。
sys.dbms_backup_restore.restoreBackupPiece(done => done, params => null, outhandle => outhandle,outtag => outtag, failover => failover);
（9）循环进行增量备份。
循环进行增量备份操作在正式环境的切割之前进行，其目的是为了减少最后一次数据库表空间read only时生产环境的停机时间，需要特别注意的是，操作之前务必查询并记录当前SCN号。这个SCN号是下一次开始增量备份的起点，如图6-13所示。
（10）正式割接准备。
正式切换的准备阶段是整个XTTS迁移过程中最重要的一步。为保证数据的一致性，需要在源库停止业务后，对活动的数据库会话进行查杀处理，并且在read only表空间之前需要进行几次检查点，确保检查点成功完成才能进行下一步操作。另外，针对计划窗口任务的JOB需要提前关闭JOB避免因JOB执行、批处理等导致数据不一致，如图6-14所示。
图6-13
图6-14
（11）最后一次增量备份。
最后一次增量备份是在生产源库表空间全部read only的情况下进行的，需要根据前一次记录的SCN号进行最后一次增量备份、转换、应用。在转换应用之后建议把新环境做一个闪回点或者进行一次全备，作为下一步导入元数据失败的回退方案，如图6-15所示。
图6-15
注：转换应用之前建议先把新环境进行一次全备。
（12）元数据的导入和导出。
导出需在表空间read only下才能进行，应排除系统表空间。导入时可能会遇到type不存在的情况，建议使用数据泵进行。
如下所示，在源库导出表空间的元数据：
exp ‘/ as sysdba’
transport_tablespace=y
tablespaces=‘TBS_NAME’
STATISTICS=none
file=/dump1/enmo/exp/orcl_XTTS_0715.dmp
根据导出的dmp包导入元数据：
imp ‘/ as sysdba’
transport_tablespace=y
TABLESPACES=‘TBS_NAME’
file=/dump1/enmo/exp/orcl_XTTS0715.dmp
log=/dump1/enmo/exp/orcl_imp_XTTS0715.log
datafiles=(’+FLASHDATA/orcl/datafile/VIO_DATA_u01’,
‘+FLASHDATA/orcl/datafile/base_image_fno65’)
（13）元对象的导入和导出。
开始导入之前先把表空间read write，可以使用dblink进行远程不落地导入，指定需要的schemas，导入存在权限不足可进行手工授权，导入完毕后即可开始验证。如下所示：
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".log
2）临时表导入。
3）组织索引表创建。
4）其他手工导入用户。
（14）数据校验收尾阶段。
1）统计信息收集或者导入。
EXEC DBMS_STATS.gather_schema_stats(‘DRV_ZW’, estimate_percent => 10,degree => 64);
2）无效对象重新检查编译。
SQLplus / as sysdba <<EOF
DECLARE
threads pls_integer := 150;
BEGIN
utl_recomp.recomp_parallel(threads);
END;
/
3）对象数量比对
select owner,object_type,count (*) from dba_objects where owner =‘用户名称’
group by owner,object_type order by owner,object_type;
4）主键索引核对。
select count(1),a.status from dba_constraints a where a.owner='用户名称
and a.constraint_type=‘P’ GROUP BY A.status;
5）大表数据校验。
–num_rows行数验证
select table_name,num_rows from all_tables where owner=‘用户名称’
group by table_name,num_rows
having num_rows>500 order by table_name;
–大小验证
select owner, segment_name, bytes / 1024 / 1024
from dba_segments where segment_type = ‘TABLE’ and owner = ‘用户名称’;
6）账号权限、同义词验证。
Set lines 180
Col object_name for a40
select object_name,object_type,status from dba_objects
where owner in (‘账号名称’) and status<>‘VALID’;
7）数据文件头状态。
select STATUS,ERROR,TABLESPACE_NAME from V$DATAFILE_HEADER;
8）表空间校验。
确认owner用户的DEFAULT_TABLESPACE、TEMPORARY_TABLESPACE 以及所有用户在相关表空间上的配额情况，将之前创建的owner用户的默认表空间改为正确的默认表空间。
9）启动数据库。
启动监听，应用开始连接测试：
srvctl start scan_listener
删除测试用户信息：
drop user enmoXTTStest cascade;
drop public database link enmo_test;
验证结果比对表如表6-11所示。
表6-11 数据校验检查表
| 数据校对项 | 结 果 |
|---|---|
| 测试数据比对 | True |
| 迁移列表的表空间数量比对 | True |
| Schema数量比对 | True |
| 对象数比对 | True |
| 表记录数比对 | True |
| 包、函数、存储过程、索引等状态比对 | True |
| 权限比对 | True |
| 同义词比对 | True |
| 临时表数量比对 | True |
（15）回退方案。
一个完整的方案还需要包括回退方案，迁移切换失败进行回退。
1）前提条件：在不影响现有生产环境后续的可用性的情况下进行切换。
2）回退条件：仅需把源生产数据库表空间置换为read write 、源库JOB进程调整为1000、源库监听启动。
3）回退时间：执行回退方案可保证在5分钟之内完成。
4）回退影响：本次切换失败。
6.9 XTTS 风险预估
在执行迁移时需要充分估计项目的风险点，在关键的环节要加强测试、把关，规避可能的风险，以下是在各个阶段可能出现的问题点，需要特别关注。
（1）第一次全量备份消耗源生产库资源需关注。
（2）全量备份挂载NFS会占用网络流量。
（3）筛选排除系统表空间需认真仔细。
（4）自包含检查需排除系统表空间。
（5）使用exp导元数据可能会遇到Bug。
（6）最后一次增量备份只读源库表空间可能会因活动会话占用，表空间read only过慢。
（7）切换之前一定要先对目标库做一个rman 全备，避免失败无法回退。
（8）每次增量备份之前都需记录SCN。
6.10 XTTS 总结
对于数据库的跨平台迁移，大家所熟悉的方法有很多，每种方法都各有利弊，关键还要看实际需求再来决定使用哪一种方式更能切合业务，提高工作效率。物理迁移的方式具备很多优势，这样减少了很多繁琐的数据校验过程，尤其是面对超过10TB的数据库时，物理迁移能在一定程度上提高迁移速度，节省大量的时间。
本章节向大家推荐的XTTS在面对U2L大数量迁移中更能发挥其优势，不过也有很多不为人知的陷阱。我们建议如果想使用好这个方法，需要对XTTS的原理非常熟悉，尽量采用手工脚本的方式来进行数据迁移。官方推出的DBMS_FILE_TRANSFER包由于Bug太多，在同步过程中经常会遇到很多莫名其妙的错误而中断，所以并不建议大家使用。对于RMAN 备份的方式，因为本身rman_xttconvert包是通过执行不同参数来自动进行数据文件的复制、转换、应用以及增量等，需要大家对它的执行过程非常熟悉才不容易造成混乱。如果当您面对需要传输的表空间非常多时，建议还是采用手工的方式会比较保险。
在国内“去IOE”浪潮的席卷之下，整个行业快速向前演进，小型机转眼已成昨日黄花。IDC的《刀片服务器推动企业基础架构走向新IT时代》白皮书中指出：10年间，刀片服务器出货量由2005年的49.1万台增长到99.4万台，年复合增长率达到7.4%；中国x86刀片服务器市场出货量由2005年的0.9万台快速增长到2015年的12.2万台，10年间翻了10倍之多，年复合增长率达到29.2%，在2014年和2015年均占据销售额市场份额第一的位置。
随着x86架构服务器的迅速发展，企业从RISC架构服务器向x86架构服务器的转型也成为了潮流，即Unix to Linux，在行业里被简称为U2L。
那么，在U2L如火如荼的今天，如何快捷、高效、平稳、安全地将Oracle数据库“小型机+集中式存储”环境迁移至“x86架构平台+分布式存储”，如何将这些单库容量达到10TB级，甚至30TB、50TB的数据库在有限的停机时间内平稳、安全地迁移至x86服务器中，如何利用好每一个数据迁移工具的优缺点来达到方便、快捷、高效地完成数据库管理工作，是每个数据库管理员（DBA）需要认真思考的问题。
6.1 XTTS 概述
XTTS（Cross Platform Transportable Tablespaces，跨平台传输表空间），是Oracle自10g推出的用来移动单个表空间数据，以及创建一个完整的数据库从一个平台到另一个平台的迁移备份方法。
 XTTS源自Oracle 8i引入的一种基于表空间传输的物理迁移方法——TTS，不过8i的表空间迁移仅支持相同平台、相同块大小之间的表空间传输，然而在那个年代还未像今天的技术日新月异，TTS的光芒一直被埋没在历史的尘埃里。图6-1所示为TTS和XTTS迁移对比图。
 从Oracle 9i开始，TTS开始支持同平台中，不同块大小的表空间传输，这个时候很多数据库管理员就注意到了TTS在实际工作中的应用，不过由于每次移动表空间都需要停机、停业务，而9i的TTS只能在相同平台之间进行数据移动，相比Oracle RMAN本身的快捷、方便，更多人更愿意选择使用RMAN进行数据备份和数据移动。
 基于这些原因，Oracle 10g时代引入了跨平台的表空间传输方案XTTS，标志着第一代XTTS的诞生。
图6-1
在Oracle 10.1中第一代XTTS是基于表空间的传输，到Oracle 11gR1后，跨平台数据的迁移可以支持传输表空间中的某个特定分区，不过在数据移动过程中，仍然需要将主库设置为只读状态、停机、停业务下才能进行数据迁移，对于业务不可间断的系统仍旧需要花费大量的停机时间才能达到跨平台物理迁移的效果，所以把11gR2以前的XTTS技术称作第一代XTTS技术。
从11gR2开始，为了应对越来越大的数据量，相对停机时间要求日益减少的情况，Oracle推出了新的解决方案——加强版XTTS，使用增量备份方式实现跨平台的数据迁移。从真正意义上讲，能够减少停机时间、进行增量备份的XTTS，才真正是今天所说的XTTS。
XTTS各版本的功能对比如表6-1所示。
表6-1 XTTS各版本功能比对表
| 版 本 说 明 | 跨 平 台 | 不 同 块 | 增 量 备 份 |
|---|---|---|---|
| Oracle 8i | |||
| Oracle 9i | √ | ||
| Oracle 10g | √ | √ | |
| Oracle 10gR2 | √ | √ | |
| Oracle 11gR1 | √ | √ | |
| Oracle 11gR2 | √ | √ | √ |
| Oracle 12c | √ | √ | √ |
6.2 XTTS技术迁移应用场景
6.2.1 应用场景一：全国“去IOE”战略实施
所谓“去IOE”，是对“去IBM、Oracle、EMC”的简称，其中，IBM代表硬件以及整体解决方案服务商，Oracle代表数据库，EMC代表数据存储。我国很多领域的核心业务系统都运行在“IOE”的软硬件架构之上。
另外随着x86平台市场份额的不断扩大，以英特尔至强系列处理器为主导的服务器，在传统行业数据中心中的应用越来越广泛，同时通过降低硬件采购及功耗和散热成本，采购性价比与同等 RISC架构相比总体拥有成本也大幅降低。至此，U2L数据库迁移，即把数据库服务器从小型机迁移到x86平台，从UNIX操作系统迁移到Linux操作系统，成为当前最热门的趋势。那么如何在保证有限的停机时间内，完成大量数据的迁移成为各行各业在去“IOE”的路上必须要迈过的一道坎。
而Oracle 在11.2.0.4中提出了XTTS增量备份表空间传输的U2L迁移方式，成为当前为止在面对大批量数据中最高效、最安全的解决方案之一。U2L迁移示意图如图6-2所示。
图6-2
6.2.2 应用场景二：“云平台”数据中心建设
随着技术的发展，传统数据中心在多方面都面临挑战，加上大数据时代的来临，对传统数据中心提出了新的挑战，为了解决这一问题，随之出现了云数据中心。同时随着x86虚拟化技术的成熟，以x86架构为基础的服务器计算资源通过虚拟化配置资源池，形成云化平台，完成统一调度、集中计算，而传统小型机数据库迁移到x86架构的云平台使用XTTS迁移也成为最直接、有效的方式之一，如图6-3所示。
图6-3
6.2.3 应用场景三：老旧环境淘汰改造
随着我国信息化建设程度的深入，一批又一批老旧物理硬件设备已经达到使用年限，甚至一些核心系统的服务器处于脱保状态。从配置层面来看，更是呈现服务器配置低下、内存不足、资源过度利用等情况。而随着应用模块的增加，数据量也呈几何增长，业务需求变化快过市场需求的今天，业务逻辑的复杂度也呈现倍数增长。在当前这种传统系统架构落后、设备陈旧、数据安全无法得到保障的情况下，购买新的设备进行更新和升级无疑是大家从物理上解决性能瓶颈的办法之一。可面对昂贵的UNIX服务器成本，是选择买还是不买同样成为摆在决策者面前的两难选择，而x86平台的强势崛起，低成本、高性能的表现无疑更符合用户长远利益的选择。使用XTTS跨平台迁移UNIX到新架构x86同样也更符合停机时间短、迁移周期短、回退简单等要求。
6.2.4 应用场景四：数据库分布式存储重构
随着越来越多业务功能的上线，在今天的数据中心环境下，Oracle RAC（Real Application Clusters）等企业数据库系统正在发展成为高度集成的中央系统。 而RAC也面临数据库性能优化这一巨大挑战，性能瓶颈可能出现在网络和处理器等多个领域中，但最常见的来自于缓慢的硬盘驱动器。随着应用对更快的随机输入/输出需求不断地增加，这些机械硬盘驱动器更难满足这些需求。构造一套灵活的纯软件解决方案，充分利用基于PC服务器的内部直连式存储来创建一个虚拟的、可扩展的SAN，性能或优于外部传统光纤通道SAN，而成本和复杂性大幅度降低的分布式存储架构成为当今数据库重构的新方向，在节省物理硬件成本的开支外还能提高性能，其中XTTS在进行分布式存储重构实施中也能起到良好的作用，分布式存储重构解决方案如图6-4所示。XTTS利用RMAN 直接路径复制数据文件的方式，速度更快、性能更好地完成传统集中存储向分布式存储数据迁移。
图6-4
6.2.5 应用场景五：其他应用场景
可能的其他应用场景还包括跨平台恢复数据永久保存、数据仓库搭建、历史数据跨平台归档、非结构化数据迁移、单独表空间跨平台备份恢复等。
6.3 XTTS 迁移步骤
说了那么多XTTS在U2L之中的迁移应用场景，下面就从XTTS的迁移步骤出发，一步一步来了解使用XTTS进行表空间传输的整个迁移步骤。
首先通过图6-5来看一下Oracle 11gR2以前版本的XTTS典型的迁移步骤。
通过图6-5可以看出，在Oracle 11gR2以前使用XTTS迁移数据中是没有增量前滚这一步，必须在源库表空间完全只读状态下才能进行数据迁移。由于数据传输又必须在数据库启动中只读状态下来读取，另外整个迁移数据的过程是一个串行的步骤，所以此过程所需要的时间同数据库数据量的大小成正比。如果数据量很大，数据传输和转换的时间可能会很长。因此在Oracle 11gR2以后，Oracle推出了通过前滚数据文件，复制数据后再进行多次增量备份的XTTS来完成迁移过程。在这个过程中通过开启块跟踪特性，根据SCN号来执行一系列的增量备份，并且通过对块跟踪文件的扫描，来完成增量数据的增量备份应用。最后再通过一定的停机时间，在源库Read Only的状态下进行最后一次增量备份转换应用，使得整个迁移过程的停机时间同源库数据块的变化率成正比，这样大大缩短了停机时间。
如图6-6所示，可以把Oracle 11gR2以后版本的整个迁移过程分为7个阶段。
 
图6-5 XTTS迁移典型步骤 图6-6 XTTS迁移步骤图
6.4 XTTS 迁移方式
XTTS基于一组rman-xttconvert的脚本文件包（参考MOS 1389592.1）来实现跨平台的数据迁移，主要文件是Perl 脚本 xttdriver。xttdriver.pl是备份、转换、应用的执行脚本，xtt.properties则是属性文件，其中包含XTTS配置的路径、参数。
采用XTTS迁移方式，具备跨平台字序转换和全量初始化加增量Merge的功能，非常适用于异构OS跨平台迁移，成为数据库实施人员中公认的大数据量跨平台迁移的最佳选择。
传统的XTTS要求数据由源端到目标端传输的整个过程中，表空间必须置于只读模式，严重影响业务可用性。XTTS方式可以在业务正常运行的情况下，进行物理全量初始化、增量数据块备份、数据高低字节序转换、增量数据块应用、保持目标端与源端数据的同步，整个过程不影响源端数据库使用。在最后的增量数据块应用完毕后，利用停机窗口进行数据库切换，显著地减少了停机时间。
rman-xttconvert包参数说明如表6-2所示。
表6-2 xtt.properties参数说明
| 参 数 范 例 | 意 义 |
|---|---|
| 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时的并行设置 |
6.4.1 方式一：dbms_file_transfer
DBMS_FILE_TRANSFER包是Oracle提供的一个用于复制二进制数据库文件或在数据库之间传输二进制文件的程序包。在XTTS迁移中，利用不同的参数进行数据文件传输转换完成迁移。dbms_file_transfer参数示例如表6-3所示。
表6-3 dbms_file_transfer参数示例
| Subprogram 参数 | Description 描述 |
|---|---|
| COPY_FILE | 从源目录中读取一个文件并创建一个在目标目录的副本，源和目标目录都可以是本地文件系统，或是自动存储管理（ASM）磁盘组，或本地文件系统和ASM之间复制 |
| GET_FILE | 从远程数据库读取远程文件，然后创建一个本地文件系统中的文件副本或ASM |
| PUT_FILE | 读取本地文件或ASM和从远程数据库创建一个远程文件系统中文件的副本 |
dbms_file_transfer语法示例如表6-4所示。
表6-4 dbms_file_transfer语法示例
| 参 数 | 示 例 |
|---|---|
| COPY_FILE | BEGIN DBMS_FILE_TRANSFER.COPY_FILE(‘SOURCEDIR’,‘t_xdbtmp.f’, ‘DGROUP’, ‘t_xdbtmp.f’); END; |
| GET_FILE | BEGIN DBMS_FILE_TRANSFER.GET_FILE ( ‘df’ , ‘a1’ , ‘dbs1’, ‘dsk_files’ , ‘oa5.dat’ ); DBMS_FILE_TRANSFER.GET_FILE ( ‘dsk_files’ , ‘a2.dat’ , ‘dbs1’, ‘dsk_files’ , ‘a2back.dat’ ); END ; |
| PUT_FILE | BEGIN DBMS_FILE_TRANSFER.PUT_FILE ( ‘ft1_1’ , ‘a2.dat’ , ‘df’ , ‘a4.dat’ , ‘dbs2’ ) ; END ; |
注：如果数据库存在大量的表空间文件，那么使用dbms_file_transfer包来进行迁移是速度最快的。
6.4.2 方式二：RMAN Backup
RMAN Backup 方式是基于RMAN备份原理，通过使用rman-xttconvert包提供的参数，对数据库进行基于表空间的备份，将备份生产的备份集写到本地或者NFS盘上，然后再通过rman-xttconvert包中包含的不同平台之间数据文件格式转换的包对数据文件格式进行转换，最后通过记录的表空间FILE_ID号生成元数据的导入脚本，通过db_link执行完成。rman方式XTTS执行步骤如表6-5所示。
表6-5 rman方式XTTS执行步骤
| 使用阶段 | 脚 本 名 字 | 用 途 |
|---|---|---|
| 准备 | perl xttdriver.pl -p （源端） | 为了生成下述文件 |
| rmanconvert.cmd | Rman数据文件转化格式的命令 | |
| xttplan.txt | 记录scn号 | |
| perl xttdriver.pl -c （目标端） | 转换文件格式，直接到最终目录 |
续表
| 使用阶段 | 脚 本 名 字 | 用 途 |
|---|---|---|
| 增量前滚 | perl xttdriver.pl -i （源端） | |
| tsbkupmap.txt | 表空间对应增备 | |
| incrbackups.txt | 增备的备份集的路径 | |
| xttplan.txt.new | 记录新的scn号 | |
| perl xttdriver.pl -s （源端） | 将xttplan.txt.new替换xttplan.txt | |
| perl xttdriver.pl –r （目标端） | 应用增备 | |
| 传输阶段 | perl xttdriver.pl -e | 生成导入元数据的脚本 |
6.4.3 方式三：手工XTTS迁移
在实践中，可以总结提炼割接的步骤，创建手工脚本执行XTTS迁移，以加强自动化和迁移速度。以下总结了迁移的过程，可以把需要进行迁移的工作根据任务以及子任务的方式固化，形成一套可重复执行的迁移技术方案。
如表6-6所示是手工XTTS迁移说明（以实际生产为例），实践中可以参考这些步骤组织适合自己的流程和方法。
表6-6 手工脚本方式迁移准备
| 操 作 对 象 | 操 作 说 明 |
|---|---|
| 目标数据库安装配置 | 根据标准数据库安装手册进行数据库软件，数据库实例创建，配置参数 |
| 源库新监听创建 | srvctl add listener -l listener_1523 -p 1523 源端数据库创建监听用于远程访问数据比对的监听，此处用于正式切换时，源库生产监听停止，启用此新建的监听，使得其他无业不能连接 |
| 源库Dblink创建 | create user enmoXTTStest identified by “xxxxxxx”; grant dba to enmoXTTStest; 创建迁移切换数据一致性比对用户、DBLINK连接用户，权限为DBA权限 |
| 目标库Dblink创建 | 创建基于DBA权限用户的DB_LINK连接到源端，使用listener_1523 |
| 目标库其他配置 | 安全规范、性能参数配置，删除USERS表空间，新建一个默认的表空间 |
| NFS存储准备 | 一期NFS存储挂载用于数据初始化工作，二期NFS存储挂载用于增量备份 |
| 源库开启块跟踪 | 源端开启块跟踪，需关注块跟踪大小 ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ‘+SATADATA/changetracking.chg’; |
| 源库表空间自包含 | SELECT * from sys.transport_set_violations; |
| 源库获取用户相关环境信息 | 用户，DBLINK，PROFILE，PRIV |
| 源库临时表信息 | select o.owner, object_name, created from dba_objects o, dba_tables t where o.object_name = t.table_name and o.owner = t.owner and t.TEMPORARY = ‘Y’ order by 1, 3; |
续表
| 操 作 对 象 | 操 作 说 明 |
|---|---|
| 排除系统表空间 | select to_char(wm_concat(TS#)) from v$tablespace where NAME not in (‘UNDOTBS1’,‘SYSTEM’,‘SYSAUX’,‘TEMP’,‘UNDOTBS2’,‘UNDOTBS3’,‘UNDOTBS4’,‘XDB’,‘BASE’) and name not in (select distinct TABLESPACE_NAME from DBA_TEMP_FILES); |
| 源库准备rman 备份脚本 | 根据生成的TS#号制订出RMAN COPY脚本 |
| 执行rman copy脚本 | 分别在源库多个RAC节点发起RMAN 数据文件到NFS存储 |
| 准备数据文件转换脚本 | 根据NFS磁盘上复制数据文件完成后的结果，通过脚本拉取convert转换时所需要的执行脚本 |
| 执行数据文件格式转换 | 在目标库多个节点执行：RMAN CONVERT 将数据文件转成Linux平台，并存放在ASM里面 |
| 准备增量备份脚本 | 根据第一次RMAN COPY 确认过的SCN进行增量同步备份 |
| 获取增量转换清单 | 增量备份文件转换成Linux平台生成转换清单，增量转换文件到/dump/enmo/incr目录，生成增量备份转换的结果集存放到执行脚本中 |
| 应用增量备份 | 先将asmcmd中转换好的文件名作为列表存放在列表文件中，使用for循环读取，list文件名为apply_list.txt |
XTTS迁移割接步骤，如表6-7所示。
表6-7 手工脚本方式迁移切割步骤
| 操 作 对 象 | 操 作 说 明 |
|---|---|
| 源库 | 在业务停业务时，清理回收站数据 purge dba_recyclebin |
| 在业务停业务时，创建验证用户 create user enmo_test identified by xxxxxxx; conn enmo_test/xxxxxxxx 在业务停止后，创建数据验证表并插入验收数据 create table enmo_test(enmo_a number) insert into select lenvel from dual connect by lenve <1000; | |
| 修改JOB参数 | 停服务与修改JOB参数 alter system set job_queue_processes=0; |
| 监听 | 源库和目标库监听停止 srvctl stop listener -l listener srvctl stop listener -l listener_scan1 |
| 查杀活动进程 | 查杀进程，确认无活动事务与死事务，包括分布式事务 ps -ef|grep LOCAL=NO|grep -v grep|awk ‘{print $2}’|xargs kill -9 select local_tran_id,state from dba_2pc_pending ; KILL JOB进程 |
| 表空间只读状态 | 源库表空间置为read only 状态 |
| 增量备份转换应用 | 根据上一次增量备份SCN号进行最后一次增量备份转换并应用 |
| 源库元数据、元对象导出 | 在做增量备份的同时，做元数据、元对象导出exp、expdp |
| 创建用户 | 根据XTTS执行前收集到的用户信息创建用户 |
| 创建 database link | 根据XTTS执行前收集到的用户信息创建dblink |
| 目标库全备 | 备份数据库，用于回退 |
续表
| 操 作 对 象 | 操 作 说 明 |
|---|---|
| 目标库表空间读写模式 | 修改目标库表空间read write |
| 元数据导入 | 目标库导入传输表空间的元数据（imp、impdp） |
| 数据库可用性、验证数据验证 | 查询测试表是否有数据 |
| 业务核心数据验证 | 验证核心表的数据是否一致，核心表验证由开发、应用进行 |
| 元对象导入 | 二次导入（存储过程、试图等信息）导入数据库的元对象 |
| 设置默认表空间 | 将用户的默认表空间修改成原来的值 |
| 用户权限 | 给角色及对象授权 |
| 对象对比 | 迁移对象比对 |
| 编译无效对象 | 开启并行进程，编译无效对象 DECLARE threads pls_integer := 150; BEGIN utl_recomp.recomp_parallel(threads); END; / |
| 验证数据清理 | 删除测试表、数据验证用户、迁移使用的DBLINK |
| 统计信息导入 | 导入表与索引的统计信息，可以按schema或者对象来导入 |
| 数据量比对 | 对象数、表记录数 |
| 迁移contab内容 | 提前将crontab里面的脚本迁移到目标数据库 |
| 开启服务 | 业务确认没有问题后开启监听与启动服务 srvctl start service -d orcl -s |
| 收集字典表统计信息 不影响业务 | EXEC DBMS_STATS.GATHER_DICTIONARY_STATS; EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS; |
| 新库：打开JOB | alter system set job_queue_processes=1000; |
6.5 XTTS 前置条件检查
如本章前文概述所示，传输表空间技术从Oracle 8i诞生，经过多个版本的改进完善，时至今日已经发展成为跨平台大数据量迁移的利器，尤其从Oracle 11.2.0.3以后XTTS推出使用跨平台增量备份的方式，通过迁移不同字节序格式系统之间的数据，大大地减少了停机的时间。在方便的同时，来看一看使用XTTS进行数据迁移需要具备的前置条件，具体如下所示。
 源库的操作系统不能是 Windows。
 源库的 COMPATIBLE 参数必须设置为 11.1.0 或更高。
 源库的 COMPATIBLE 参数值不能大于目标库的 COMPATIBLE 参数值。
 源和目标库时区、字符集保持一致。
 目标端db_files参数大于源库。
 源库必须处于 ARCHIVELOG 模式。
 源库的 RMAN 配置里 DEVICE TYPE DISK 不能设置为 COMPRESSED。
 要迁移的表空间的数据文件必须都是 online 或者不包含 offline 的数据文件。
 排除系统表空间，避免冲突，并且检查业务表空间是否存在自包含。
当然以上所说的目标端数据库版本均为11.2.0.4版本或者以上，如果在使用过程中，目标库的版本是11.2.0.3或者更低，那么需要创建一个单独的11.2.0.4版本数据库作为中间库来在目标端进行数据文件的格式转换，而使用DBMS_FILE_TRANSFER包目标端的数据库版本必须是11.2.0.4。
迁移检查
基于以上这些条件，在开始XTTS迁移之前，需对整个实施环境进行一次全面的检查，保证在实施之前环境满足迁移要求。
（1）数据库时区检查，保持源库和目标库时区一致性。
select dbtimezone from dual;
DBTIME
------
+08:00
（2）数据库字符集检查，保持源库和目标库字符集一致性。
select * from nls_database_parameters where parameter like ‘%CHARACTERSET%’;
PARAMETER VALUE
NLS_CHARACTERSET AL32UTF8
NLS_NCHAR_CHARACTERSET UTF8
（3）数据库目标端补丁情况检查。
目标端psu根据数据库安装配置最佳实践规范配置安装最新PSU。
select ‘opatch’,comments from dba_registry_history
'OPATC COMMENTS
opatch PSU 11.2.0.4.4
使用dbms_file_transfer方法，在11g中目标端建议安装的补丁如下：
 Patch 19023822，修复目标端使用dbms_file_transfer.get_file包获取源端数据文件出现ORA-03106的情况。
 Patch 22171097: MERGE REQUEST ON TOP OF DATABASE PSU 11.2.0.4.6 FOR BugS 17534365 19023822。
如果准备阶段使用rman方法，目标端没有小补丁安装需求。
（4）检查目标库端数据库组件安装情况，需包含且多于源库组件。
源端组件：
COMP_NAME
----------------------------------------------------
Oracle Application Express
Oracle Multimedia
Oracle XML Database
Oracle Expression Filter
Oracle Rules Manager
Oracle Workspace Manager
Oracle Database Catalog Views
Oracle Database Packages and Types
JServer JAVA Virtual Machine
Oracle XDK
Oracle Database Java Packages
目标端组件：
COMP_NAME
--------------------------
Oracle Enterprise Manager
Oracle Workspace Manager
Oracle Database Catalog Views
Oracle Database Packages and Types
注：组件不同，可能会导致一些特殊的业务受到影响，需同开发、应用进行确认。
（5）检查是否使用了key compression的索引组织表。
Select index_name,table_name from dba_indexes where compression=’ENABLED’;
Select owner,table_name from dba_tables where iot_type is not null;
如果存在key compression的索引组织表，目标端需要安装patch 14835322，否则索引组织表无法导入到目标端，需要手动重建，或者通过手工方式导入。
（6）检查源端数据文件、表空间异常情况。
Select name from v$datafile where instr(name,’ ‘) > 0;
如果存在空格或者换行符数据文件，需要将该数据文件rename，否则在传输过程中会报错终止。如果存在同名表空间，而且该表空间中的对象需要传输，建议将目标端中的表空间rename，以避免冲突。
（7）检查相同表空间下是否存在不同目录下的同名数据文件。
使用dbms_file_transfer方式进行XTTS数据迁移，需要通过修改准备阶段的getfile.SQL和xttnewdatafile文件来调整数据文件生成的路径。
select substr(file_name,-6,2) from dba_data_files where tablespace_name=‘TBS_NAME’ order by 1;
如果目标端有多个目录，指定数据文件生成在不同的目录，可以避免冲突。
如果准备阶段使用rman方式进行同步，则所有的数据文件会转换为xtf结尾的文件，文件名会重新命名，所以不需要提前修改。
（8）检查表空间自包含。
在传输阶段，可能因为目标端数据文件目录所限制，需要将各个表空间拆分进行传送。在导入元数据阶段，考虑到字包含特性，需要将所有的表空间汇总进行传送。检查表空间时，只检查业务表空间的自包含情况，系统表空间、临时表空间、undo表空间不在检查列。因为在XTTS数据迁移时，无需对系统表空间、temp、undo进行传输，需要在目标端重建。
SQL>execute dbms_tts.transport_set_check(TBS_NAME ,TRUE);
SQL> SELECT * from sys.transport_set_violations;
no rows selected
（9）检查源端compatible参数。
源端不可以是Windows，源端的compatible.rdbms必须大于10.2.0，且不大于目标端compatible.rdbms。
show parameter compatible
如果目标端数据库版本是11.2.0.3或更低。那么需要在目标端安装11.2.0.4 并创建实例，然后用来进行备份集转换。如果11.2.0.4中转实例使用ASM，那么ASM版本也必须是11.2.0.4，否则报错ORA-15295。
（10）启用block change tracking（块跟踪）功能。
块跟踪功能，在源端数据量较大，或者数据改变较大时启用，需要在源库安装补丁Bug 16850197。该补丁在11.2.0.3.9和11.2.0.4版本psu中提供。如果源库是在上述版本前，需要安装个别补丁，注意块跟踪设置的目录大小，避免因块跟踪目录满而导致源数据库hang。
（11）检查目标端的db_files参数。
在元数据导入阶段，如果目标端的db_files参数小于源端的db_files参数，会导致元数据因无法关联创建数据文件而导入出错，所以要确保目标端参数大于或者等于源端。
Show parameter db_files
6.6 XTTS 最佳实践方案论证
6.6.1 技术方案概况
在不影响现有生产环境的前提下，缩短业务停机时间，搭建一套同平台的data guard数据库为中间库，通过XTTS迁移技术来完成生产环境跨平台到新环境的数据迁移。
6.6.2 技术方案实施步骤
（1）目标环境准备。
（2）搭建中间data guard环境。
（3）挂载NFS存储到老生产环境减少传输时间。
（4）通过XTTS RMAN COPY 中间DG数据库的数据文件。
（5）通过中间环境DG数据库进行增量备份。
（6）新环境进行增量转换、应用。
（7）正式切割时生产环境表空间read only。
（8）最后一次增量备份。
（9）导入导出元数据。
（10）数据校验。
6.6.3 技术方案模型
技术方案模型如图6-7所示。
图6-7
6.6.4 方案可行性说明
（1）采用Data guard中间环境作为XTTS前期准备阶段的源库，因DG数据库作为生产环境的备库同生产环境数据库版本一致、数据实时同步一致、操作系统环境一致，从环境要求方面符合XTTS迁移条件。
（2）采用中间环境来作为数据文件复制的源库，中间环境因是备库，可以在不影响业务的情况下进行备库停机。
（3）待投产新环境为11.2.0.4版本满足增强版XTTS数据库版本要求。
6.6.5 方案优缺点论述
使用这一方案的优缺点简要概括如下要点。
优点：备库操作不影响生产环境业务；备库复制数据文件不影响生产环境IO性能；增量备份可以在中间库进行多次，缩短停机时间；数据一致性能得到保障。
缺点：需准备中间库环境资源。
6.6.6 技术方案论证结论
通过搭建Data guard数据库作为中间库环境来进行XTTS迁移的方案，经过实际测试效果良好，不影响生产环境业务，且实施安全可靠，对缩短停机时间进行大批量数据迁移具备最佳实践效果，方案可行。
6.7 XTTS RMAN Backup步骤
（1）环境检查参照XTTS前置条件检查第二项迁移检查。
（2）创建db_link。
create public database link ttslink connect to system identified by ******
using '(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.111.118.103)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)
)
)’;
（3）XTTS执行脚本配置。
存放转换脚本
/home/Oracle/enmotest/xtt
存放执行脚本
/home/Oracle/enmotest/xtt-scripts
配置必要脚本
SCZXB[/home/Oracle/enmotest/xtt-scripts]$more xtt.properties
tablespaces=ENMOTEST_TABS—表空间名称
platformid=4 —平台代号
dfcopydir=/dump2/enmotest/rman_copy—数据文件复制存放的路径
backupformat=/dump2/enmotest/rman_incr—增量备份集存放的路径
stageondest=/dump2/enmotest/rman_incr----目标端存放数据文件复制目录和存放增量备份的目录
storageondest=+FLASHDATA/orcl/DATAFILE—目标端数据文件转换后的最终目录
backupondest=/dump2/enmotest/rman_incr----备份文件转换后生成的目录
（4）源库发起rman copy。
–源端进行第一次rman copy数据文件
perl /home/Oracle/enmotest/xtt-scripts/xttdriver.pl -p
（5）目标库复制生成脚本。
在目标端，通过Oracle用户复制源端/home/Oracle/enmotest/xtt/rmanconvert.cmd到目标端的/home/Oracle/enmotest/xtt目录下。
scp source:/home/Oracle/enmotest/xtt/rmanconvert.cmd dest:/home/Oracle/enmotest/xtt
（6）目标端进行转换。
----目标端进行转换
perl /home/Oracle/enmotest/xtt-scripts/xttdriver.pl -c
（7）源端增量备份。
cd /home/Oracle/enmotest/xtt-scipts
perl xttdriver.pl -i
结束会生成一个新的记录scn的文件：xttplan.txt.new。
（8）复制生产文件后转换应用。
将tsbkupmap.txt xttplan.txt传到目标端/home/Oracle/enmotest/xtt，将incrbackups.txt传到目标端/dump2/enmotest/rman_incr。
cd /home/Oracle/xtt
cp incrbackups.txt /dump2/enmotest/rman_incr
cp xttplan.txt tsbkupmap.txt /dump2
目标端开始应用增量备份：
cd /home/Oracle/enmotest/xtt-scritps
perl xttdriver.pl -r
（9）确定新的scn。
perl xttdriver.pl -s
该步骤会将-i时生成的xttplan.txt.new改名为xttplan.txt，并将原来的xttplan.txt备份。
（10）源库read only 进行最后一次增量备份。
–源库表空间read only
alter tablespace ENMOTEST_TABS read only;
–最后一次增量备份
perl xttdriver.pl -i
将tsbkupmap.txt xttplan.txt传到目标端/home/Oracle/enmotest/xtt
将incrbackups.txt传到目标端/dump2/enmotest/rman_incr
cd /home/Oracle/xtt
cp incrbackups.txt /dump2/enmotest/rman_incr
cp xttplan.txt tsbkupmap.txt /dump2
cp xttplan.txt tsbkupmap.txt /home/Oracle/enmotest/xtt
（11）应用增量备份，完成最后一次增量恢复。
cd /home/Oracle/xtt-scripts
perl xttdriver.pl -r
（12）元数据导入脚本生成。
–目标端运行
cd /home/Oracle/xtt-scripts
perl xttdriver.pl -e
（13）目标端创建用户。
–目标库先创建用户，并且权限同源库一样
create user enmoXTTStest identified by ********* default tablespace USERS;
（14）导入元数据。
impdp ‘/ as sysdba’ directory=DATA_PUMP_DIR logfile=tts_imp.log network_link=ttslink transport_full_check=no transport_tablespaces=ENMOTEST_TABS transport_datafiles=’+ FLASHDATA/orcl/datafile/enmotest_tabs_1024.xtf’
（15）数据验证。
应当根据数据特点，定制脚本、程序，进行基本的数据验证。
6.8 XTTS 实战案例分享
实践是检验真理的唯一标志，下面通过一个跨平台迁移32TB数据库的XTTS实战案例，来解析在大数据量迁移过程中的手工脚本应用情况。以下案例从XTTS原理出发，涉及操作系统、NFS存储、RMAN备份、系统字节序转换、数据验证以及网络知识。
6.8.1 案例现状介绍
某省交管核心系统自上线运行6年以来，从最初GB为单位的数量级上升到今天32TB的业务数据量，其中照片信息的LOB字段占有27TB。随着近几年信息化行业深化改革发展，信息化、互联网+、大数据已经成为交管业务支撑不可或缺的组成元素，但该交管局核心系统却存在严重问题，已然不能满足现有业务的发展。为解决这套老旧的核心业务系统，通过调研，最终确定为客户采用zDATA分布式存储方案。组建一个高速、安全、稳定的高性能分布式存储数据库架构，通过去除老旧HP机器，采用高配置的X86 PC服务器作为计算和存储节点，不仅提供强大的CPU、I/O、Memory支持能力，还为后续的横向扩容存储提供不停机服务，可如何进行这大批量的数据迁移成为本项目的一个难点。
6.8.2 系统现状评估
系统资源配置如表6-8所示。系统现状评估如图6-8所示。
表6-8 系统资源配置表1
| 主 机 | 生产库主库为3节点集群，其中2台为HP 8640 |
|---|---|
| 存储 | HP XP24000 |
| 应用 | Websphere（约20台主机，14台为HP小机，其他为Windows环境） |
| 连接数 | 单节点连接数为260～300 |
| 容灾备份 | 无容灾环境 |
| 数据容量 | 约32TB，集中存储HP XP24000已经满了，无法扩容 |
图6-8
该系统存在的问题还包括以下情况：3节点RAC架构不合理；集中存储使用10年以上、计算节点服务器设备老旧；资源配置低，物理扩容到达瓶颈；数据爆发式增长；业务应用模块增多、数据库表存放LOB字段；基层业务人员反馈系统各种性能问题。
6.8.3 迁移需求分析
系统迁移面临的问题主要有如下情况：HP-UX跨平台迁移到Linux；数据库总量为32TB，LOB数据大小为27TB；单个数据库表空间为17TB；数据库版本为11.2.0.3（无任何补丁）；计划内停机切换时间为8小时；计划内完成时间为15天；数据库账号密码不能改变；无应用测试；无资源提供测试环境（存储、资源）。
如何设计方案，解决这些挑战，是项目实施中的重要内容。
6.8.4 迁移方案选型
如图6-9所示，通过需求调研分析后，因系统涉及30多TB数据量，并且业务停机时间只有8个小时，另外需要跨平台进行数据迁移。我方经过几次测试论证后，排除如下方案，在此也请各位思考一下，如果遇到此类需求作为DBA应该如何应对。
图6-9
最终选择了最具挑战的XTTS来完成这次32TB的跨平台迁移挑战。迁移前后的资源配置情况如表6-9所示。
表6-9 系统资源配置表2
| 配 置 类 型 | 源 库 | 目 标 库 |
|---|---|---|
| 数据库版本 | 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 | |
| 块大小 | 16384 | 16384 |
6.8.5 迁移的具体实施
在以下的描述中，我们再现了生产过程中的实战步骤，供读者在学习和实践中参考。
（1）XTTS环境检查，如表6-10所示。
表6-10 XTTS环境检查表
| 检 查 项 | 源 库 | 目 标 库 |
|---|---|---|
| 时区是否一致 | 时区为东八区 | 东八区 |
| 字符集是否一致 | 16GBK | 16GBK |
| 检查目标端补丁情况 | 无 | 需打最新PSU |
| 组件检查 | 包含源库组件 | |
| key compression索引组织表 | 存在 | 需手工重建 |
| 表空间规范检查 | 不同磁盘组下数据文件名称命名相同 | |
| TEMP表空检查 | 存在 | 需手导入 |
| 检查目标端的db_files参数 | 1 024 | 4 096 |
| 检查源端compatible参数 | 不可以是windows 且大于10.2.0 | 11.2.0.4 |
| 检查表空间自包含 | 存在自包含 需手工MOVE | |
| 用户 | DBLINK，PROFILE，PRIV | 需手工创建 |
（2）开启块跟踪。
Block change tracking进程记录自从上一次0级备份以来数据块的变化，并把这些信息记录在跟踪文件中。RMAN使用这个文件判断增量备份中需要备份的变更数据。这极大地提高了备份性能和速度，RMAN可以不再扫描整个文件以查找变更数据。
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ‘+SATADATA/changetracking.chg’;
Database altered.
（3）挂载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
源端、目标端需要挂载35TB存储用于存放所有数据文件的镜像文件，建议将存储远程从源端挂载到目标端，减少备份传送时间。图6-10所示为XTTS迁移工作示意图-NFS存储初始化挂载。
图6-10
（4）SCN确认记录。
SCN（System Chang Number）作为Oracle中的一个重要机制，在数据恢复、Data Guard、Streams复制、RAC节点间的同步等各个功能中起着重要作用，在此需确认SCN，且该SCN号用于后续增量备份的起始点。
alter system checkpoint;
select current_scn from v$database;
（5）开始RMAN Copy。
基于数据文件的RMAN COPY生成的文件存放于挂载的NFS目录下。
rman target / <<EOF
run{
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
rman backup工作示意图如图6-11所示。
（6）数据文件格式转换。
Convert 用于转换数据文件的字节序，转换后的新数据文件直接写入新环境的磁盘组，转换过程消耗目标端的CPU资源，此处需要关注目标端磁盘组的大小，避免造成磁盘组满引起转换失败，如图6-12所示。
convert from platform ‘HP-UX IA (64-bit)’ datafile ‘/dump1/ccm/vvstart_tabs.dbf’ format ‘+FLASHDATA/ORCL/DATAFILE/vvstart_new_01.dbf’;
 
图6-11 图6-12
（7）增量备份阶段。
开启块跟踪后基于块进行快速增量，增量备份前先查询并记录当前的SCN，根据全备时记录的SCN进行增备（假定记录的SCN是1000），增量备份文件存放于NFS存储上，增量备份后生成的字节序是HP-UX的需进一步转换。
set until scn=1850
backup incremental from scn 1000 datafile 18,19,20,21,22… format ‘/dump1/enmo/incr/ copy_%d_%T_%U’;3;
（8）增量转换应用。
增量备份的转换和应用是两个过程，首先是增量备份集从HP-UX平台转换成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 恢复的原理是一样的。
sys.dbms_backup_restore.restoreBackupPiece(done => done, params => null, outhandle => outhandle,outtag => outtag, failover => failover);
（9）循环进行增量备份。
循环进行增量备份操作在正式环境的切割之前进行，其目的是为了减少最后一次数据库表空间read only时生产环境的停机时间，需要特别注意的是，操作之前务必查询并记录当前SCN号。这个SCN号是下一次开始增量备份的起点，如图6-13所示。
（10）正式割接准备。
正式切换的准备阶段是整个XTTS迁移过程中最重要的一步。为保证数据的一致性，需要在源库停止业务后，对活动的数据库会话进行查杀处理，并且在read only表空间之前需要进行几次检查点，确保检查点成功完成才能进行下一步操作。另外，针对计划窗口任务的JOB需要提前关闭JOB避免因JOB执行、批处理等导致数据不一致，如图6-14所示。
图6-13
图6-14
（11）最后一次增量备份。
最后一次增量备份是在生产源库表空间全部read only的情况下进行的，需要根据前一次记录的SCN号进行最后一次增量备份、转换、应用。在转换应用之后建议把新环境做一个闪回点或者进行一次全备，作为下一步导入元数据失败的回退方案，如图6-15所示。
图6-15
注：转换应用之前建议先把新环境进行一次全备。
（12）元数据的导入和导出。
导出需在表空间read only下才能进行，应排除系统表空间。导入时可能会遇到type不存在的情况，建议使用数据泵进行。
如下所示，在源库导出表空间的元数据：
exp ‘/ as sysdba’
transport_tablespace=y
tablespaces=‘TBS_NAME’
STATISTICS=none
file=/dump1/enmo/exp/orcl_XTTS_0715.dmp
根据导出的dmp包导入元数据：
imp ‘/ as sysdba’
transport_tablespace=y
TABLESPACES=‘TBS_NAME’
file=/dump1/enmo/exp/orcl_XTTS0715.dmp
log=/dump1/enmo/exp/orcl_imp_XTTS0715.log
datafiles=(’+FLASHDATA/orcl/datafile/VIO_DATA_u01’,
‘+FLASHDATA/orcl/datafile/base_image_fno65’)
（13）元对象的导入和导出。
开始导入之前先把表空间read write，可以使用dblink进行远程不落地导入，指定需要的schemas，导入存在权限不足可进行手工授权，导入完毕后即可开始验证。如下所示：
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".log
2）临时表导入。
3）组织索引表创建。
4）其他手工导入用户。
（14）数据校验收尾阶段。
1）统计信息收集或者导入。
EXEC DBMS_STATS.gather_schema_stats(‘DRV_ZW’, estimate_percent => 10,degree => 64);
2）无效对象重新检查编译。
SQLplus / as sysdba <<EOF
DECLARE
threads pls_integer := 150;
BEGIN
utl_recomp.recomp_parallel(threads);
END;
/
3）对象数量比对
select owner,object_type,count (*) from dba_objects where owner =‘用户名称’
group by owner,object_type order by owner,object_type;
4）主键索引核对。
select count(1),a.status from dba_constraints a where a.owner='用户名称
and a.constraint_type=‘P’ GROUP BY A.status;
5）大表数据校验。
–num_rows行数验证
select table_name,num_rows from all_tables where owner=‘用户名称’
group by table_name,num_rows
having num_rows>500 order by table_name;
–大小验证
select owner, segment_name, bytes / 1024 / 1024
from dba_segments where segment_type = ‘TABLE’ and owner = ‘用户名称’;
6）账号权限、同义词验证。
Set lines 180
Col object_name for a40
select object_name,object_type,status from dba_objects
where owner in (‘账号名称’) and status<>‘VALID’;
7）数据文件头状态。
select STATUS,ERROR,TABLESPACE_NAME from V$DATAFILE_HEADER;
8）表空间校验。
确认owner用户的DEFAULT_TABLESPACE、TEMPORARY_TABLESPACE 以及所有用户在相关表空间上的配额情况，将之前创建的owner用户的默认表空间改为正确的默认表空间。
9）启动数据库。
启动监听，应用开始连接测试：
srvctl start scan_listener
删除测试用户信息：
drop user enmoXTTStest cascade;
drop public database link enmo_test;
验证结果比对表如表6-11所示。
表6-11 数据校验检查表
| 数据校对项 | 结 果 |
|---|---|
| 测试数据比对 | True |
| 迁移列表的表空间数量比对 | True |
| Schema数量比对 | True |
| 对象数比对 | True |
| 表记录数比对 | True |
| 包、函数、存储过程、索引等状态比对 | True |
| 权限比对 | True |
| 同义词比对 | True |
| 临时表数量比对 | True |
（15）回退方案。
一个完整的方案还需要包括回退方案，迁移切换失败进行回退。
1）前提条件：在不影响现有生产环境后续的可用性的情况下进行切换。
2）回退条件：仅需把源生产数据库表空间置换为read write 、源库JOB进程调整为1000、源库监听启动。
3）回退时间：执行回退方案可保证在5分钟之内完成。
4）回退影响：本次切换失败。
6.9 XTTS 风险预估
在执行迁移时需要充分估计项目的风险点，在关键的环节要加强测试、把关，规避可能的风险，以下是在各个阶段可能出现的问题点，需要特别关注。
（1）第一次全量备份消耗源生产库资源需关注。
（2）全量备份挂载NFS会占用网络流量。
（3）筛选排除系统表空间需认真仔细。
（4）自包含检查需排除系统表空间。
（5）使用exp导元数据可能会遇到Bug。
（6）最后一次增量备份只读源库表空间可能会因活动会话占用，表空间read only过慢。
（7）切换之前一定要先对目标库做一个rman 全备，避免失败无法回退。
（8）每次增量备份之前都需记录SCN。
6.10 XTTS 总结
对于数据库的跨平台迁移，大家所熟悉的方法有很多，每种方法都各有利弊，关键还要看实际需求再来决定使用哪一种方式更能切合业务，提高工作效率。物理迁移的方式具备很多优势，这样减少了很多繁琐的数据校验过程，尤其是面对超过10TB的数据库时，物理迁移能在一定程度上提高迁移速度，节省大量的时间。
本章节向大家推荐的XTTS在面对U2L大数量迁移中更能发挥其优势，不过也有很多不为人知的陷阱。我们建议如果想使用好这个方法，需要对XTTS的原理非常熟悉，尽量采用手工脚本的方式来进行数据迁移。官方推出的DBMS_FILE_TRANSFER包由于Bug太多，在同步过程中经常会遇到很多莫名其妙的错误而中断，所以并不建议大家使用。对于RMAN 备份的方式，因为本身rman_xttconvert包是通过执行不同参数来自动进行数据文件的复制、转换、应用以及增量等，需要大家对它的执行过程非常熟悉才不容易造成混乱。如果当您面对需要传输的表空间非常多时，建议还是采用手工的方式会比较保险。
