简介面向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.0RMAN命令模板。辅助脚本还有xttdriver.pl、xttprep.pl这些不同小版本可能略有差异。工作流程大致是先在源端服务器上配置xtt.properties指定要迁移的表空间、平台信息、备份目录、目标端连接信息等。用xttdriver.pl在源端执行RMAN脚本生成一个包含全量备份和增量备份的任务计划也就是xttplan.txt。源端RMAN执行LEVEL 0全量备份备份完把全备文件传到目标端。目标端执行restore把全量备份恢复成数据文件。源端开启增量循环每隔一段时间比如每天执行一次Level 1增量备份传到目标端目标端recover应用。最后切换前源端执行最后一次增量备份这一步需要业务停机传到目标端应用然后目标端表空间由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_id6 dst_platform_id13 # 要迁移的表空间列表逗号分隔 tablespacesUSERS,TOOLS,APPS_DATA # 源端RMAN备份集存储路径双方都能访问最好实际生产一般是先传到目标端 backup_location/xtts_backup # 目标端RMAN恢复目录 dest_datafile_location/oradata/orcl # 源端比目标端多出来的路径映射 env_keep_listORACLE_HOME,ORACLE_SID # 连接目标端的TNS别名或者连接串 target_connect_stringsystarget_db as sysdba这里面的坑主要在tablespaces参数上。我见过有人把临时表空间、UNDO表空间也写进去结果恢复时报错。记住xttconvert只处理应用表空间临时表和UNDO由目标库自己创建。还有如果源库用了OMFOracle Managed Files或者ASMdest_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_catrcat 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分多钟。如果走公网或者加密传输这个时间要翻倍或者翻三倍建议错开业务高峰。传到目标端之后在目标端执行restorerman target / EOF restore foreign tablespace USERS,TOOLS,APPS_DATA from backupset /xtts_backup/full_*.bkp; EOFrestore foreign tablespace是跨平台恢复的关键命令它会把AIX上的备份集转换成Linux格式的数据文件。这一步做完目标端的数据文件和源库全量备份时刻完全一致。3.4 增量备份循环与最后的切换全量恢复完成之后源库的业务一直没停数据还在不断变化。xttconvert的增量循环启动源端再执行一次Level 1增量备份这个增量备份只包含全量之后变化的数据块。好一点的场景一天的业务变化可能只有10GB增量包传输只要几十秒。把增量备份集传到目标端。目标端执行restore incremental...然后recover datafile应用增量。重复若干轮直到切换前最后一轮增量。我实际执行过程中增量频率从每天一次到每六小时一次都试过。原理上次数越频繁每轮增量越小最后一轮应用时间越短。但频繁备份也会增加源端I/O压力DBA要自己权衡。到了正式切换那一步业务停机应用断开数据库连接。源库存档日志切换ALTER SYSTEM ARCHIVE LOG CURRENT;再执行一次Level 1增量备份或者备份最后的归档日志。把最后这批增量传到目标端recover应用。目标端把所有数据文件置于 ONLINE表空间改为 READ WRITE。在目标端重建临时表空间、配置监听、验证应用连接。经验丰富的人还会提前准备好切换脚本把“停业务、备份、传文件、应用、打开”五步操作写成一个带检查点的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 statusINVALID;有失效对象先排查是版本差异导致的失效要在切换窗口内解决否则业务连上来一访问就直接报错。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 oracletarget_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阶段能提前暴露的。磨刀不误砍柴工这句话放在数据库迁移上永远成立。本文还有配套的精品资源点击获取