【实战案例分享】使用XTTS技术进行U2L跨平台数据迁移

下面通过一个跨平台迁移32TB数据库的XTTS实战案例，来解析在大数据量迁移过程中的手工脚本应用情况。以下案例从XTTS原理出发，涉及操作系统、NFS存储、RMAN备份、系统字节序转换、数据验证以及网络知识。

1 案例现状介绍

某省交管核心系统自上线运行6年以来，从最初GB为单位的数量级上升到今天32TB的业务数据量，其中照片信息的LOB字段占有27TB。随着近几年信息化行业深化改革发展，信息化、互联网+、大数据已经成为交管业务支撑不可或缺的组成元素，但该交管局核心系统却存在严重问题，已然不能满足现有业务的发展。

为解决这套老旧的核心业务系统，通过调研，最终确定为客户采用zDATA分布式存储方案。组建一个高速、安全、稳定的高性能分布式存储数据库架构，通过去除老旧HP机器，采用高配置的X86 PC服务器作为计算和存储节点，不仅提供强大的CPU、I/O、Memory支持能力，还为后续的横向扩容存储提供不停机服务，可如何进行这大批量的数据迁移成为本项目的一个难点。

2 系统现状评估

系统资源配置如表6-8所示。系统现状评估如图6-8所示。

该系统存在的问题还包括以下情况：3节点RAC架构不合理；集中存储使用10年以上、计算节点服务器设备老旧；资源配置低，物理扩容到达瓶颈；数据爆发式增长；业务应用模块增多、数据库表存放LOB字段；基层业务人员反馈系统各种性能问题。

3 迁移需求分析

系统迁移面临的问题主要有如下情况：HP-UX跨平台迁移到Linux；数据库总量为32TB，LOB数据大小为27TB；单个数据库表空间为17TB；数据库版本为11.2.0.3（无任何补丁）；计划内停机切换时间为8小时；计划内完成时间为15天；数据库账号密码不能改变；无应用测试；无资源提供测试环境（存储、资源）。

如何设计方案，解决这些挑战，是项目实施中的重要内容。

4 迁移方案选型

如图6-9所示，通过需求调研分析后，因系统涉及30多TB数据量，并且业务停机时间只有8个小时，另外需要跨平台进行数据迁移。我方经过几次测试论证后，排除如下方案，在此也请各位思考一下，如果遇到此类需求作为DBA应该如何应对。

最终选择了最具挑战的XTTS来完成这次32TB的跨平台迁移挑战。迁移前后的资源配置情况如表6-9所示。

5 迁移的具体实施

在以下的描述中，我们再现了生产过程中的实战步骤，供读者在学习和实践中参考。

（1）XTTS环境检查，如表6-10所示。

（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存储初始化挂载。

（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';

（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所示。

（11）最后一次增量备份。
最后一次增量备份是在生产源库表空间全部read only的情况下进行的，需要根据前一次记录的SCN号进行最后一次增量备份、转换、应用。在转换应用之后建议把新环境做一个闪回点或者进行一次全备，作为下一步导入元数据失败的回退方案，如图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 数据校验检查表

（15）回退方案。

一个完整的方案还需要包括回退方案，迁移切换失败进行回退。

1）前提条件：在不影响现有生产环境后续的可用性的情况下进行切换。

2）回退条件：仅需把源生产数据库表空间置换为read write 、源库JOB进程调整为1000、源库监听启动。

3）回退时间：执行回退方案可保证在5分钟之内完成。

4）回退影响：本次切换失败。

XTTS 风险预估

在执行迁移时需要充分估计项目的风险点，在关键的环节要加强测试、把关，规避可能的风险，以下是在各个阶段可能出现的问题点，需要特别关注。

（1）第一次全量备份消耗源生产库资源需关注。
（2）全量备份挂载NFS会占用网络流量。
（3）筛选排除系统表空间需认真仔细。
（4）自包含检查需排除系统表空间。
（5）使用exp导元数据可能会遇到Bug。
（6）最后一次增量备份只读源库表空间可能会因活动会话占用，表空间read only过慢。
（7）切换之前一定要先对目标库做一个rman 全备，避免失败无法回退。
（8）每次增量备份之前都需记录SCN。

XTTS 总结

对于数据库的跨平台迁移，大家所熟悉的方法有很多，每种方法都各有利弊，关键还要看实际需求再来决定使用哪一种方式更能切合业务，提高工作效率。物理迁移的方式具备很多优势，这样减少了很多繁琐的数据校验过程，尤其是面对超过10TB的数据库时，物理迁移能在一定程度上提高迁移速度，节省大量的时间。

本章节向大家推荐的XTTS在面对U2L大数量迁移中更能发挥其优势，不过也有很多不为人知的陷阱。我们建议如果想使用好这个方法，需要对XTTS的原理非常熟悉，尽量采用手工脚本的方式来进行数据迁移。官方推出的DBMS_FILE_TRANSFER包由于Bug太多，在同步过程中经常会遇到很多莫名其妙的错误而中断，所以并不建议大家使用。

对于RMAN 备份的方式，因为本身rman_xttconvert包是通过执行不同参数来自动进行数据文件的复制、转换、应用以及增量等，需要大家对它的执行过程非常熟悉才不容易造成混乱。如果当您面对需要传输的表空间非常多时，建议还是采用手工的方式会比较保险。