企业官网建设流程全解析

简介：面向Oracle数据库管理员的RMAN与XTTConvert工具资源包，专注解决XML表空间备份与恢复场景下的效率问题；该工具组合了RMAN的备份恢复能力与XTTConvert的XML表空间转换优势，适合DBA在运维中快速上手。压缩包共6个文件，包含SQL脚本、PL/SQL驱动、配置模板与属性文件，整体仅25KB，轻量易用。已有379人学习，适合需要处理大量XML数据并希望优化RMAN备份策略的DBA。通过研究这些脚本与模板，读者可掌握XTTConvert的预处理模板、备份目的地设置、数据库启动与打开等关键环节的脚本组织方式；资源包内脚本分工清晰，预处理脚本负责环境准备，驱动脚本调度执行流程，SQL脚本则在数据库不同状态下完成备份与恢复操作，直接修改复用配置可减少重复工作，与现有RMAN体系互补，能高效融入XML表空间支持，保障业务连续性。

1. 项目概述：rman-xttconvert_2.0.rar 到底是什么

1.1 一句话说清楚这个东西

看到这个文件名，老Oracle DBA应该秒懂——这又是一份xttconvert脚本压缩包，版本号2.0。xttconvert是Oracle提供的一套Perl脚本集合，全称是Cross Platform Transportable Tablespaces using RMAN Incremental Backup，配合MOS文档Doc ID 1389592.1使用。它解决的问题非常具体：跨平台、跨字节序的数据库迁移，迁移过程中停机窗口还特别短。

这套东西和平时大家用的expdp/impdp不是一回事，也跟RMAN DUPLICATE搭备库完全两码事。它走的是可传输表空间（Transportable Tablespaces，简称TTS）路线，但比传统TTS进步的地方在于：传统TTS只能做全量传输，源库在传输期间必须保持只读；xttconvert则允许源库持续读写，先用RMAN做一次全量备份传输到目标端，之后每隔一段时间再传增量，最后一轮增量应用完成后，才真正切断业务、做最终切换。停机时间大幅缩短，从普通的“拷贝几十GB数据要停几个小时”缩短到“最后应用一次增量可能就十来分钟”。

1.2 它解决了什么痛点

我举一个典型的场景：源库跑在AIX小机上，Oracle版本还是11.2.0.4，因为硬件维保到期或者机房要整合，需要迁移到Linux x86-64的新环境。这种迁移有几个绕不开的难点：

第一，字节序不同。AIX是大端，Linux是小端，普通的数据文件直接拷贝过去根本起不来，RMAN的BACKUP FOR TRANSPORTABLE FORMAT命令能处理跨字节序转换，但它要求表空间先置为只读。业务不能停怎么办？就只能靠xttconvert这种增量方案。

第二，数据量大。几十TB的库，用expdp逻辑导出根本不现实，单表导出时间就够喝一壶。

第三，停机窗口短。很多系统是7x24小时在线，业务部门最多给你批一个周六凌晨两小时的窗口，全量拷贝肯定来不及。

xttconvert的核心思路就是把这个大迁移拆成三段：全量阶段跑很久没关系，增量阶段继续跑也没关系，只有最后一轮应用到目标库的时候才真正需要停业务。整个过程的停机窗口里，真正要做的事情其实已经非常少了。

1.3 适合谁用、谁不该用

这套方案最适合以下几类场景：

• 从旧硬件（AIX、HP-UX、Solaris）迁移到Linux或云端虚拟机
• 数据库版本从11g/12c迁移到同版本或更高版本
• 数据量大、停机窗口有限的正式环境
• 无法使用DataGuard物理备库的场景（比如源端硬件太老装不了同版本备库，或者需要跨字节序）

谁不该用？如果你的源库和目标库字节序一致，而且可以接受较长停机，普通RMAN整库恢复（RMAN restore）、DataGuard备库切换、或者传统TTS就能搞定，没必要引入xttconvert的复杂度。还有，如果业务表上有不支持的列类型（比如基于用户自定义类型），这套方案也会卡壳。

2. 迁移原理拆解：为什么是全量加增量而不是传归档日志

2.1 传统TTS和xttconvert的差别到底在哪

传统TTS的操作，本质上就是“把表空间变成只读”和“恢复表空间”两个动作。流程是：源库把要迁移的表空间改成READ ONLY，用RMAN备份成跨平台格式，传到目标端，目标端rman convert把数据文件转换好，再在目标库做restore和recovery，最后两边表空间改回READ WRITE。这个方案的毛病一眼就能看出来——源库表空间从设置为只读那一刻起，到目标端正式恢复之前，业务应用根本无法写入。

xttconvert把“只读”这个硬性要求改成“只读一瞬间”。它利用的是Oracle的增量备份机制：数据库正常运行的时候，RMAN可以连续做Level 0全量备份和Level 1增量备份，增量备份记录的是数据文件里变化的数据块。xttconvert把这些增量备份先传到目标端，在目标端对已经restore的全量备份不断应用增量，最终让目标端的表空间“追上”源库某个时间点，最后一次增量应用完，两边数据一致，切换业务。源库表空间整个过程中大部分时间都是READ WRITE状态，只有最后一轮增量备份完成、应用过程中才需要短暂冻结或者停业务。

这里有个关键机制值得多说一点：增量备份不是备份日志归档，而是备份数据块映像。RMAN增量备份会扫描数据文件，把自上次备份以来修改过的块提取出来，所以每一轮增量包其实不大，传输压力远小于全量。这也是为什么xttconvert能做到“每天传一轮增量，最后只停很短时间”，而不是像Log Shipping那样必须依赖连续的网络传输。

2.2 xttconvert脚本的工作机制

压缩包里一般包含这么几个核心文件：xttconvert.pl（主调度脚本）、xtt.properties（配置文件）、xttplan.txt（迁移计划文件）、rman-xttconvert_2.0（RMAN命令模板）。辅助脚本还有xttdriver.pl、xttprep.pl这些，不同小版本可能略有差异。

工作流程大致是：

1. 先在源端服务器上配置xtt.properties，指定要迁移的表空间、平台信息、备份目录、目标端连接信息等。
2. 用xttdriver.pl在源端执行RMAN脚本，生成一个包含全量备份和增量备份的任务计划，也就是xttplan.txt。
3. 源端RMAN执行LEVEL 0全量备份，备份完把全备文件传到目标端。
4. 目标端执行restore，把全量备份恢复成数据文件。
5. 源端开启增量循环：每隔一段时间（比如每天）执行一次Level 1增量备份，传到目标端，目标端recover应用。
6. 最后切换前，源端执行最后一次增量备份（这一步需要业务停机），传到目标端应用，然后目标端表空间由READ ONLY改为READ WRITE，完成迁移。

整个过程中，xttconvert.pl扮演的是编排调度角色，真正的数据搬家还是RMAN在干活。RMAN负责备份、restore、convert跨平台数据文件，xttconvert只是把“什么时候该干什么”串了起来。

2.3 为什么不用RMAN DUPLICATE或者DataGuard

很多朋友会问：现在都有RMAN DUPLICATE，还有DataGuard，为什么不直接用？答案是：这些方案在不同平台、不同字节序之间迁移数据时并不适用。

RMAN DUPLICATE搭建备库的文档（Doc ID 1617946.1）确实很火，它适用于同平台或者能反卷日志的平台。但跨字节序的情况下，源库的归档日志在目标端根本没法apply，因为日志里的redo记录与字节序强相关，数据块在内存和磁盘上的格式都不一样。DataGuard也同理，物理备库要求字节序和操作系统类型一致。

PostgreSQL有没有类似Oracle这种方案？热词里提到了“postgresql 有没有像oracle一样的rman备份”。说实话，PostgreSQL生态里没有能完全对标xttconvert的官方工具。PG的物理备份主要靠pg_basebackup加WAL归档，跨平台迁移要么用pg_dump/pg_dumpall逻辑导出，要么用物理流复制在同平台之间复制。真要跨平台还得小心字节序和数据对齐问题。Oracle这套xttconvert方案是因为有“可传输表空间”这个独特架构做基础，别的数据库想抄也抄不了。

3. 完整实操流程：从准备工作到最终切换

3.1 迁移前必须完成的检查项

我用一个11.2.0.4从AIX迁到Linux的实战案例来走一遍真实流程。动手之前，先挨个确认这些事：

源库环境检查：

• 确认字节序和平台：SELECT tp.platform_id, tp.platform_name FROM v$transportable_platform tp; 得能看到AIX和Linux两边的平台信息都在允许列表里。
• 确认要迁移的表空间清单：SELECT tablespace_name, status FROM dba_tablespaces; 系统表空间SYSTEM、SYSAUX、UNDO不参与，只迁移应用表空间，UNDO和临时表空间在目标端重新创建。
• 确认没有不支持的列类型：dba_objects里有基于用户自定义类型（UDT）的表，或者XMLType表用了非标准存储的，可能有问题。提前查：SELECT DISTINCT owner, type_name FROM dba_object_tables; 有自定义类型的先处理。
• 确认所有表空间都是SELF CONTAINED：用DBMS_TTS.TRANSPORT_SET_CHECK检查，有外键引用、分区表跨表空间之类的会报错。
• 确认源库RMAN配置正常，备份目录空间充足。备份集要暂存再传输，至少准备全量备份两倍大小的空间。

目标端环境准备：

• 安装和源库同版本或更高版本的Oracle，补丁级别尽量对齐。
• 创建好实例：指定db_name、db_block_size要和源库一致、字符集一致。
• 创建好目录结构：数据文件目录、监听等。
• 准备一台中转机器或者直接用目标端目录保存从源端传来的备份集。

3.2 配置xtt.properties参数

这是我最想展开的部分，因为大部分人第一次跑不通过都是配置文件写错了。xtt.properties是一个键值对形式的文本文件，我只说几个最重要的参数：

# 源平台（AIX）和目标平台（Linux）的ID，从v$transportable_platform查询 src_platform_id=6 dst_platform_id=13 # 要迁移的表空间列表，逗号分隔 tablespaces=USERS,TOOLS,APPS_DATA # 源端RMAN备份集存储路径，双方都能访问最好，实际生产一般是先传到目标端 backup_location=/xtts_backup # 目标端RMAN恢复目录 dest_datafile_location=/oradata/orcl # 源端比目标端多出来的路径映射 env_keep_list=ORACLE_HOME,ORACLE_SID # 连接目标端的TNS别名或者连接串 target_connect_string=sys@target_db as sysdba

这里面的坑主要在tablespaces参数上。我见过有人把临时表空间、UNDO表空间也写进去，结果恢复时报错。记住，xttconvert只处理应用表空间，临时表和UNDO由目标库自己创建。还有，如果源库用了OMF（Oracle Managed Files）或者ASM，dest_datafile_location那边要提前规划好路径，目标端路径结构和源库可以不一样，但迁移后的数据文件位置要能对上。

配置完先用xttdriver.pl -p xtt.properties -l /tmp/xttlogs试跑一下，它会生成一个计划文件xttplan.txt，一眼能看到哪些表空间、哪些数据文件会被安排成什么顺序迁移。这个文件很关键，相当于整个迁移的作战地图，建议先人工检查一遍再往下走。

3.3 执行全量备份与传输

XTTS的官方流程中，全量阶段通常是一个core backup加若干次增量。2.0版本默认会用RMAN的BACKUP INCREMENTAL LEVEL 0命令来完成首次全量，这个命令支持跨平台转换。

实际操作中，我习惯手动分两步：

# 在源端执行全量备份 rman target / catalog rman_cat/rman_cat@rcat <<EOF backup incremental level 0 tablespace USERS,TOOLS,APPS_DATA format '/xtts_backup/full_%U.bkp' include current controlfile; EOF

备份集传目标端之前，先算一下文件大小和传输时间：

• 假设全量备份集300GB，万兆网络理论传输速度约1GB/s，实际按600MB/s算，大概要8分多钟。
• 如果走公网或者加密传输，这个时间要翻倍或者翻三倍，建议错开业务高峰。

传到目标端之后，在目标端执行restore：

rman target / <<EOF restore foreign tablespace USERS,TOOLS,APPS_DATA from backupset '/xtts_backup/full_*.bkp'; EOF

restore foreign tablespace是跨平台恢复的关键命令，它会把AIX上的备份集转换成Linux格式的数据文件。这一步做完，目标端的数据文件和源库全量备份时刻完全一致。

3.4 增量备份循环与最后的切换

全量恢复完成之后，源库的业务一直没停，数据还在不断变化。xttconvert的增量循环启动：

1. 源端再执行一次Level 1增量备份，这个增量备份只包含全量之后变化的数据块。好一点的场景，一天的业务变化可能只有10GB，增量包传输只要几十秒。
2. 把增量备份集传到目标端。
3. 目标端执行restore incremental...然后recover datafile，应用增量。
4. 重复若干轮，直到切换前最后一轮增量。

我实际执行过程中，增量频率从每天一次到每六小时一次都试过。原理上次数越频繁，每轮增量越小，最后一轮应用时间越短。但频繁备份也会增加源端I/O压力，DBA要自己权衡。

到了正式切换那一步：

1. 业务停机，应用断开数据库连接。
2. 源库存档日志切换：ALTER SYSTEM ARCHIVE LOG CURRENT;再执行一次Level 1增量备份或者备份最后的归档日志。
3. 把最后这批增量传到目标端，recover应用。
4. 目标端把所有数据文件置于 ONLINE，表空间改为 READ WRITE。
5. 在目标端重建临时表空间、配置监听、验证应用连接。

经验丰富的人还会提前准备好切换脚本，把“停业务、备份、传文件、应用、打开”五步操作写成一个带检查点的shell脚本，每个步骤完成之后都做一次校验，避免切换窗口里手忙脚乱。

4. 常见问题与排查技巧实录

4.1 宽表超过32列时的ORA-14037

我最早跑xttconvert时就栽过这个跟头。表空间里有一张表有40多个字段，全量restore完成后，一recover增量就报ORA-14037——partitioning column type mismatch或者类似的错误，其实根因是源库那条表跨了表空间或者分区键类型在convert之后出了问题。

排查方法很简单：先把报错抛出来的表找出来，看它的分区策略和列类型。如果是三个字节字符集与大字节序组合的问题，最直接的解法是先把那张表重建为目标端可识别的结构。另一种情况是表和索引跨不同的表空间，导致TTS自包含校验的时候没通过。提前用DBMS_TTS.TRANSPORT_SET_CHECK把表空间组检查了，能省很多麻烦。

4.2 增量备份传输时间超出预期

增量循环跑了一段时间之后，有几次增量备份集异常地大。查了才发现，源库有大量的临时表操作和频繁的索引重建，这些操作产生大量块修改，全算进增量里了。还有一次是因为一个批量任务更新了几张千万行的表，一次性改了20%的数据块。

应对手段有两层。第一层是优化业务侧：把大事务拆小，避开增量备份窗口执行批量更新。第二层是优化备份侧：增量备份之前手动做一次索引rebuild online并更新统计信息，减少冗余块变化。如果源库开启补充日志或者存在大量延迟块清除（Delayed Block Cleanout），增量备份扫描到的变化块也可能多于预期，这时可以考虑调大DBWR进程数，加速脏块写出。

4.3 目标端recover应用速度慢

恢复增量的时候，目标端apply速度跟不上源库产生增量的速度，最典型的原因是目标端I/O配置不行——机械盘和SSD的恢复性能差距可能在一个数量级。还有可能是归档日志没有及时清理导致空间紧张，RMAN恢复过程被迫等待磁盘空间释放。

遇到这种情况，检查几个方向：

• 目标端的datafile是不是落在SSD或者足够快的存储上
• 恢复时并行度有没有调高：recover datafile默认串行，可以加PARALLEL 8
• 目标端redo日志和临时表空间是否够大，避免恢复过程中频繁的checkpoint引起IO抖动

4.4 完成迁移之后，源库还能不能退回去

这是业务方最爱问的问题。xttconvert本身的切换是不可逆的——目标端接替了业务之后，源库通常就不再维护。但实际运维中为了保险，可以保留一套完整的数据泵逻辑导出或者RMAN整库备份在异地，确保万一目标端有问题还能倒回去。我一般会做两层保险：目标端切换成功运行一周之后再清理源库备份，这个周期足够发现大部分隐性兼容问题。

注意，目标端恢复之后，表空间还是READ ONLY状态，别急着直接改成READ WRITE。先查一下所有对象的有效性：SELECT COUNT(*) FROM dba_objects WHERE status='INVALID';有失效对象先排查，是版本差异导致的失效要在切换窗口内解决，否则业务连上来一访问就直接报错。

4.5 关于1617946.1的误读

热词里提到“creating a standby using rman duplicate (rac or non-rac) (doc id 1617946.1)”——有些朋友会把xttconvert和这个文档混为一谈。这两个其实是完全不同的东西。1617946.1讲的是RMAN DUPLICATE搭建备库，适用于同平台、日志可以apply的环境；xttconvert是跨平台跨字节序的迁移，靠的是可传输表空间加增量备份。真把xttconvert理解成“跨平台版duplicate”也能抓住一部分精神，但实操时千万别把两套文档的命令混着用，否则会栽得很惨。

5. 备份传输脚本的一个小套路

分享一个我在实际迁移中常用的传输脚本模板。全量阶段和增量阶段都要传文件，用rsync比scp靠谱，自带断点续传和校验，大文件传输失败不用从零开始：

# 源端执行增量备份后，传输到目标端 rsync -avzP --partial /xtts_backup/incre_*.bkp oracle@target_host:/xtts_recv/

我的习惯是每次传输完成后做一次校验和对比，确保备份集完整：

# 源端生成校验值 md5sum /xtts_backup/incre_*.bkp > /xtts_backup/incre_md5.txt # 目标端校验 cd /xtts_recv && md5sum -c /xtts_backup/incre_md5.txt

数据传输这一步看着简单，却是整个迁移链条里最容易出幺蛾子的环节。网络抖动、磁盘空间不够、一时疏忽传错了文件，都可能让前面几小时的增量工作白干。

6. 一点个人体会

xttconvert这套东西虽然已经有年头了，但它的设计思路到现在仍然值得学习——把大而重的迁移动作拆成“无感知的全量”加“轻量的增量”，最后用一个极短的停机窗口收尾。现在云厂商鼓吹的数据库迁移服务，很多核心策略和它一个路数。

我最后再分享一个经验：在用xttconvert前，先小范围做一次POC，挑一个几十GB的测试表空间完整跑一遍全流程。不要嫌麻烦，因为正式环境的数据量往往会让所有问题都放大——全量阶段还行，增量循环的节奏、目标端的恢复性能、传输链路的稳定性，全都是POC阶段能提前暴露的。磨刀不误砍柴工，这句话放在数据库迁移上永远成立。

本文还有配套的精品资源，点击获取