简介本资源是Oracle数据库管理员及高级DBA用于高效处理XML表空间备份与恢复的RMAN增强工具包聚焦XTTConvert 2.0版本在RMAN框架下的实战集成。针对含大量XML数据的生产库迁移、灾备演练或跨平台升级场景该工具通过逻辑化转换机制显著提升XML表空间的备份速度与恢复可靠性。压缩包共6个文件25KB包含3个核心SQL脚本如xttcnvrtbkupdest.sql用于定制备份路径、xttdbopen.sql保障恢复后库状态、1个Perl驱动脚本xttdriver.pl协调执行流程、1个模板文件xttprep.tmpl生成适配环境的配置及1个属性配置文件xtt.properties定义源/目标实例参数结构精简、即装即用。目前已有379人学习下载提供开箱可用的XTTConvert v2.0全组件覆盖备份准备、驱动执行、恢复验证等关键环节的脚本支撑助读者快速落地RMANXTTConvert联合方案规避手动转换风险强化XML数据生命周期管理能力。1. RMAN XTTCONVERT 2.0不是“一键迁移”而是 Oracle 跨平台迁移中那个被反复拷贝、手动改参数、凌晨三点还在查 trace 的黑匣子工具包你手头有一套运行在 AIX 上的 Oracle 11g 生产库老板说“下季度必须迁到 Linux x86-64”DBA 小组翻遍 MOS 文档发现官方推荐路径是 Data Pump 手动重建但 3TB 数据78个表空间归档日志连续性要求让导出导入周期预估超 96 小时——业务方直接否决。这时有人甩出一个压缩包rman-xttconvert_2.0.rar。它不是 Oracle 官方安装介质没有 OPatch 验证解压后只有 5 个脚本、2 个配置模板和一份潦草的 README.txt。但它确实在多个金融客户现场跑通了跨平台、跨字节序、零停机窗口的物理块级迁移——核心就是用 RMAN 做增量备份用 XTTCross Platform Transportable Tablespaces机制做元数据缝合而xttconvert_2.0是把这套流程封装成可重复调用的 shell PL/SQL 组合体。它解决的不是“能不能迁”而是“怎么让 RMAN 在源端打快照、在目标端精准 apply 增量、且不因 block checksum、endian mismatch 或 tempfile 路径错位而报 ORA-19909 / ORA-19913”。适合已有 RMAN 备份习惯、熟悉 transportable tablespace 限制条件、能直连 ASM 或文件系统、并愿意为每个表空间单独调试的中级以上 DBA。别指望它替代 ADG也别想用它迁 SYSTEM 表空间——那是它的硬边界。2. 从解压到首次 runXTTCONVERT 2.0 的最小可行执行链与 RMAN 增量链路对齐XTTCONVERT 2.0 不是独立工具它是 RMAN 备份策略的“胶水层”。它的价值不在代码多炫酷而在把backup for transport、convert datafile、incremental level 1这三类 RMAN 操作用固定命名规则、可控时间戳、可重入的脚本逻辑串起来。下面带你走通最简路径源库AIX Oracle 11.2.0.4→ 目标库Linux x86-64 Oracle 12.1.0.2仅迁移 USERS 表空间。2.1 解压即用看清目录结构与关键文件职责unrar x rman-xttconvert_2.0.rar ls -l # 输出 # drwxr-xr-x 2 oracle oinstall 4096 Jun 15 2022 backup/ # -rw-r--r-- 1 oracle oinstall 2345 Jun 15 2022 xtt.properties # -rwxr-xr-x 1 oracle oinstall 5678 Jun 15 2022 xttconvert.sh # -rwxr-xr-x 1 oracle oinstall 3210 Jun 15 2022 xttdriver.pl # -rwxr-xr-x 1 oracle oinstall 1890 Jun 15 2022 xttpreparesrc.sql # -rwxr-xr-x 1 oracle oinstall 2045 Jun 15 2022 xttpreparedest.sql提示xtt.properties是唯一需人工编辑的配置文件xttconvert.sh是主入口它会按顺序调用xttpreparesrc.sql源端准备、xttdriver.pl驱动 RMAN 备份与传输、xttpreparedest.sql目标端元数据注入。backup/目录是输出区所有生成的.bkp、.df、.inc文件都落在此处。2.2 配置 xtt.properties6 个必填字段决定迁移成败xtt.properties中以下字段必须严格匹配你的环境漏填或格式错将导致xttdriver.pl启动即退出参数名示例值说明关键约束src_dbid1234567890源库 DBID查SELECT dbid FROM v$database;必须数字不能带空格或逗号dest_dbid9876543210目标库 DBID同上两库 DBID 绝对不可相同否则增量无法识别tablespaceUSERS待迁移表空间名区分大小写只支持单表空间多表空间需多次运行platformAIX-Based Systems (64-bit)源平台名必须与 v$database.platform_name 完全一致错写成AIX或IBM/AIX会导致 convert 失败dest_platformLinux x86 64-bit目标平台名查SELECT platform_name FROM v$database;同上大小写、空格、括号缺一不可backup_format/u01/backup/%URMAN 备份片路径模板%U为必需占位符必须有写权限且目标端能通过 NFS 或 scp 访问该路径# xtt.properties 示例仅关键行 src_dbid1234567890 dest_dbid9876543210 tablespaceUSERS platformAIX-Based Systems (64-bit) dest_platformLinux x86 64-bit backup_format/u01/backup/%U参数说明backup_format不是最终备份路径而是 RMANbackup as compressed backupset for transport命令中的format子句。XTTCONVERT 会自动在该路径下生成形如0123456789ABCDEF0123456789ABCDEF_1_1.bkp的文件并同步生成USERS_1.bkp符号链接。目标端xttdriver.pl会根据此路径拉取文件因此该路径必须对源库 Oracle 用户可写、对目标库 Oracle 用户可读通常通过 NFS 共享或提前 scp。2.3 源端执行 xttconvert.sh触发 RMAN 全量 增量备份链进入解压目录以源库 Oracle 用户身份执行./xttconvert.sh --prepare该命令实际执行三步运行xttpreparesrc.sql检查表空间状态必须READ ONLY、生成xttplan.txt记录数据文件绝对路径与 block size、创建xttnewdatafiles.sql目标端创建数据文件的 DDL调用xttdriver.pl启动 RMAN执行backup for transport全量备份并立即打一个level 1 cumulative增量备份用于后续追增量生成xttplan.txt和xttnewdatafiles.sql到backup/目录。# 执行后关键输出示例 # INFO: Starting prepare phase for tablespace USERS # INFO: Source database platform: AIX-Based Systems (64-bit) # INFO: Backup piece generated: /u01/backup/0123456789ABCDEF0123456789ABCDEF_1_1.bkp # INFO: Incremental backup piece generated: /u01/backup/0123456789ABCDEF0123456789ABCDEF_2_1.bkp # INFO: xttplan.txt and xttnewdatafiles.sql written to backup/逻辑说明--prepare并非真正迁移而是建立“基线”。它要求源表空间在备份期间保持READ ONLY因此业务停写窗口从此刻开始计算。xttplan.txt是后续所有步骤的“地图”里面每行包含datafile_id,file_name,block_size,bytes目标端xttpreparedest.sql会逐行解析它来校验文件完整性。3. 目标端接收与注入如何让 Linux 上的 Oracle “认出” AIX 的数据文件源端--prepare完成后backup/目录下已有USERS_1.bkp全量、USERS_1.inc首个增量、xttplan.txt、xttnewdatafiles.sql。这四件套必须完整传到目标端同一目录如/u01/xtt/backup/然后启动目标端流程。3.1 传输文件scp vs NFS选哪个更稳# 推荐方式源端打包目标端解压避免单文件传输中断 # 源端 cd /path/to/xtt/ tar -cf xtt_backup.tar backup/ gzip xtt_backup.tar # 目标端 scp oraclesource:/path/to/xtt/xtt_backup.tar.gz /u01/xtt/ cd /u01/xtt/ gunzip xtt_backup.tar.gz tar -xf xtt_backup.tar为什么不用 NFSNFS 在跨平台AIX→Linux挂载时若未显式设置nfsvers3和hard,intrRMAN 读取.bkp文件可能因 inode 缓存不一致报ORA-19505: failed to identify file。而scp保证字节级一致且xttdriver.pl内部对本地文件路径做了硬编码校验stat检查 mtime/sizeNFS 的缓存延迟易触发误判。3.2 目标端执行 xttconvert.shconvert restore switch# 确保目标库已启动到 MOUNT 状态非 OPEN sqlplus / as sysdba EOF SHUTDOWN IMMEDIATE; STARTUP MOUNT; EXIT; EOF # 进入目标端 XTT 目录执行 ./xttconvert.sh --restore该命令执行运行xttpreparedest.sql创建临时表空间XTT_TEMP校验xttplan.txt中每个数据文件的block_size是否与目标库db_block_size匹配调用xttdriver.pl启动 RMAN执行convert from platform将 AIX 的 big-endian 块转为 Linux little-endian再restore到目标路径最后switch datafile all更新控制文件中数据文件指针。# 关键日志片段 # INFO: Converting datafile /u01/backup/USERS_1.bkp to /u01/oradata/PROD/users01.dbf # INFO: RMAN CONVERT DATAFILE /u01/backup/USERS_1.bkp # FROM PLATFORM AIX-Based Systems (64-bit) # DB_FILE_NAME_CONVERT /u01/backup/,/u01/oradata/PROD/ # INFO: Switching datafile 5 to /u01/oradata/PROD/users01.dbf参数说明DB_FILE_NAME_CONVERT是xttdriver.pl自动拼接的其值来自xtt.properties中backup_format的路径前缀与目标数据文件路径的映射。若你的目标路径是 ASM需提前在xtt.properties中设dest_asm_diskgroupDATA脚本会自动替换为DATA/PROD/DATAFILE/USERS.256.12345。3.3 手动注入元数据绕过impdp的 schema-level 陷阱XTTCONVERT 2.0 不调用 Data Pump。它用xttpreparedest.sql中的DBMS_TTS.TRANSPORT_SET_CHECK和CREATE TABLESPACE ... DATAFILEDDL 注入元数据。但注意xttnewdatafiles.sql生成的 DDL 默认指向文件系统路径若目标用 ASM必须手动修改-- 原始 xttnewdatafiles.sql文件系统 CREATE TABLESPACE USERS DATAFILE /u01/oradata/PROD/users01.dbf SIZE 1G; -- 修改为 ASM需先查 ASM alias SELECT name FROM v$asm_alias WHERE system_createdN AND name LIKE %USERS%; -- 返回 DATA/PROD/DATAFILE/USERS.256.12345 -- 则改为 CREATE TABLESPACE USERS DATAFILE DATA/PROD/DATAFILE/USERS.256.12345 SIZE 1G;为什么必须手动xttconvert.sh --restore只负责物理文件转换与 restore元数据创建由xttpreparedest.sql执行而该 SQL 是静态生成的不感知 ASM。跳过此步直接ALTER DATABASE OPEN会报ORA-01157: cannot identify/lock data file—— 控制文件里记录了文件路径但实际文件在 ASM路径不匹配。4. 增量同步与回退用 RMAN 实现分钟级精度的“按需回退”rman-xttconvert_2.0.rar的核心价值不在首次迁移而在后续增量同步。当源库在--prepare后继续写入你需要定期追增量直到割接窗口。XTTCONVERT 2.0 支持--incremental模式它利用 RMAN 的incremental level 1备份实现比archive log应用更细粒度的恢复点。4.1 源端追增量--incremental的三次调用节奏# 第一次增量距 --prepare 2 小时后 ./xttconvert.sh --incremental # 第二次增量再过 1 小时 ./xttconvert.sh --incremental # 第三次增量割接前 5 分钟 ./xttconvert.sh --incremental每次执行生成一个USERS_N.incN 为序号并更新xttplan.txt中的checkpoint_scn。xttdriver.pl会自动识别上次增量的 SCN只备份该 SCN 之后的 block change。RMAN 增量原理--incremental调用的是backup incremental level 1 for transport它依赖源库的block change trackingBCT文件。若未启用 BCTRMAN 会全扫描数据文件耗时剧增。务必在源库执行ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE /u01/oracle/bct.f;4.2 目标端应用增量--apply的原子性保障目标端收到新USERS_2.inc后执行./xttconvert.sh --apply该命令等价于-- 在目标库 MOUNT 状态下 RECOVER DATAFILE /u01/oradata/PROD/users01.dbf OF TABLESPACE USERS FROM /u01/xtt/backup/USERS_2.inc;关键约束--apply必须在--restore之后、ALTER DATABASE OPEN之前执行。若已 OPEN则需先SHUTDOWN IMMEDIATE→STARTUP MOUNT否则报ORA-01126: database must be mounted in exclusive mode。4.3 “按分钟回退”的实操用 SCN 锚定精确恢复点标题中“rman备份 按分钟回退”并非虚言。XTTCONVERT 2.0 的--incremental生成的.inc文件自带 SCN 时间戳。你可在割接前 1 分钟在源库查当前 SCNSELECT CURRENT_SCN, TO_CHAR(SYSDATE, YYYY-MM-DD HH24:MI:SS) FROM v$database; -- 返回1234567890123, 2024-06-15 23:59:59然后在目标端--apply时指定 SCN# 修改 xtt.properties添加 apply_until_scn1234567890123 # 再执行 ./xttconvert.sh --applyxttdriver.pl会解析.inc文件只应用 SCN ≤apply_until_scn的块变更跳过之后的。这比recover database until time更精准——后者受 NLS_DATE_FORMAT 影响而 SCN 是绝对数字。血泪经验apply_until_scn必须小于等于.inc文件中记录的最大 SCN否则--apply报ORA-19907: datafile was not found。可用strings USERS_2.inc | grep SCN快速查看文件内嵌 SCN 范围。5. 避坑指南XTTCONVERT 2.0 的 4 个真实翻车现场与后悔药XTTCONVERT 2.0 的文档稀烂错误信息晦涩以下是你大概率会踩的坑按现象→原因→解决结构整理每条都来自真实生产事件。5.1 现象xttdriver.pl报Cant locate DBD/Oracle.pm脚本直接退出原因xttdriver.pl是 Perl 脚本依赖DBD::Oracle模块连接数据库。目标端若未装 Oracle Instant Client Perl DBI/DBD模块缺失。解决# 目标端Linux安装 yum install perl-DBI perl-DBD-Oracle # 确保 ORACLE_HOME、LD_LIBRARY_PATH 已设 export ORACLE_HOME/u01/app/oracle/product/12.1.0/dbhome_1 export LD_LIBRARY_PATH$ORACLE_HOME/lib:$LD_LIBRARY_PATH # 验证 perl -MDBD::Oracle -e print OK\n5.2 现象--restore时 RMAN 报ORA-19505: failed to identify file但文件明明存在原因.bkp文件被unzip或tar解压时损坏尤其 Windows 传过来的 rar 包。XTTCONVERT 对文件 CRC 校验极严xttplan.txt中记录的bytes与实际文件 size 不符即失败。解决源端重新rar a -md5打包强制 MD5 校验目标端用cksum对比cksum /u01/xtt/backup/USERS_1.bkp # 与源端输出对比必须完全一致5.3 现象--apply后ALTER DATABASE OPEN报ORA-01157: cannot identify data file原因xttnewdatafiles.sql创建表空间时DATAFILE路径写死为文件系统但实际文件在 ASM或路径权限不对Oracle 用户无读权限。解决检查v$datafile中该数据文件路径是否与xttnewdatafiles.sql一致若用 ASM手动ALTER DATABASE CREATE DATAFILE /u01/oradata/PROD/users01.dbf AS DATA/...;chmod 640确保.dbf文件属组为oinstall。5.4 现象--incremental生成的.inc文件体积异常小1MB但源库写入量很大原因源库未启用block change trackingRMANincremental level 1变成全量扫描但 XTTCONVERT 脚本默认只保留最近 1 个.inc旧文件被覆盖。解决立即启用 BCT见 4.1 节修改xttconvert.sh注释掉清理旧.inc的rm命令手动保留所有.inc按时间顺序--apply。注意rman delete archive类操作与 XTT 无关切勿在源库执行DELETE ARCHIVELOG否则--incremental依赖的归档日志丢失增量链断裂。6. 进阶技巧用 RMAN LIST BACKUP 做增量链健康度验证与故障定位XTTCONVERT 2.0 不提供增量链可视化但 RMAN 自带LIST BACKUP命令可成为你的“后悔药探测器”。当--apply失败别急着重跑先用以下三步定位是哪一环断了。6.1 查源库增量链完整性确认 level 1 备份连续性在源库 RMAN 中执行RMAN LIST BACKUP BY FILE WHERE COMPLETION_TIME SYSDATE-7 AND BACKUP_TYPE I ORDER BY COMPLETION_TIME;输出应类似List of Datafile Backups File Key Thrd Seq S Completion Time #Pieces #Copies Compressed Tag ---- ---- ----- ----- - ---------------- ------- ------- ---------- --- 5 1 123 1 A 2024-06-15 22:00:00 1 1 YES XTT_INC_1 5 1 124 1 A 2024-06-15 23:00:00 1 1 YES XTT_INC_2 5 1 125 1 A 2024-06-15 23:55:00 1 1 YES XTT_INC_3关键看Thrd Seq列它表示该增量备份覆盖的归档日志序列号范围。若123后直接125说明124序列归档丢失--incremental生成的USERS_2.inc将不完整。此时需从源库ARCHIVE LOG LIST查Oldest online log sequence确认归档是否被rman delete archive清理。6.2 查目标端已应用 SCN反向推导最后一次成功增量在目标库MOUNT 状态查SELECT file#, checkpoint_change#, last_change# FROM v$datafile WHERE name LIKE %USERS%;返回checkpoint_change# 1234567890123则说明USERS_2.inc含 SCN 1234567890123已成功应用。若last_change#为空说明数据文件仍为READ ONLY状态--apply未执行或失败。6.3 用 RMAN VALIDATE 检验 .inc 文件有效性避免传输损坏在目标端 RMAN 中对.inc文件做块级校验RMAN VALIDATE BACKUPSET /u01/xtt/backup/USERS_2.inc;若返回validation complete说明文件未损坏若报ORA-19624: operation failed with error ORA-19625则文件 CRC 错必须重传。6.4 表格XTTCONVERT 2.0 各阶段 RMAN 命令映射与可调试参数XTT 阶段等效 RMAN 命令可调试关键参数调试方法--prepareBACKUP FOR TRANSPORT FORMAT /u01/backup/%U TABLESPACE USERSFORMAT,MAXSETSIZE,DEVICE TYPE DISK PARALLELISM 4在xttdriver.pl中搜索backup for transport修改$rman_cmd变量--incrementalBACKUP INCREMENTAL LEVEL 1 FOR TRANSPORT FORMAT /u01/backup/%U TABLESPACE USERSLEVEL 1 CUMULATIVE,TAG XTT_INC_N修改xtt.properties中incremental_tagXTT_INC_2--restoreCONVERT DATAFILE /u01/backup/USERS_1.bkp FROM PLATFORM AIX... DB_FILE_NAME_CONVERT ...CONVERT,DB_FILE_NAME_CONVERT,NOFILENAMECHECK在xttpreparedest.sql中添加SET NOFILENAMECHECK--applyRECOVER DATAFILE /u01/oradata/PROD/users01.dbf FROM /u01/xtt/backup/USERS_2.incUNTIL SCN,AUXILIARY DESTINATION手动执行RECOVER ... UNTIL SCN 1234567890123测试我干这活五年最深的教训是永远在--prepare前用rman backup validate check logical database扫一遍源库数据文件——XTTCONVERT 不做逻辑坏块检查它只信 RMAN 的物理块。一个隐藏的ORA-01578会在--apply时让你凌晨三点对着ORA-19913发呆。希望帮到你。本文还有配套的精品资源点击获取
Oracle跨平台迁移：RMAN+XTTCONVERT 2.0实战指南
简介本资源是Oracle数据库管理员及高级DBA用于高效处理XML表空间备份与恢复的RMAN增强工具包聚焦XTTConvert 2.0版本在RMAN框架下的实战集成。针对含大量XML数据的生产库迁移、灾备演练或跨平台升级场景该工具通过逻辑化转换机制显著提升XML表空间的备份速度与恢复可靠性。压缩包共6个文件25KB包含3个核心SQL脚本如xttcnvrtbkupdest.sql用于定制备份路径、xttdbopen.sql保障恢复后库状态、1个Perl驱动脚本xttdriver.pl协调执行流程、1个模板文件xttprep.tmpl生成适配环境的配置及1个属性配置文件xtt.properties定义源/目标实例参数结构精简、即装即用。目前已有379人学习下载提供开箱可用的XTTConvert v2.0全组件覆盖备份准备、驱动执行、恢复验证等关键环节的脚本支撑助读者快速落地RMANXTTConvert联合方案规避手动转换风险强化XML数据生命周期管理能力。1. RMAN XTTCONVERT 2.0不是“一键迁移”而是 Oracle 跨平台迁移中那个被反复拷贝、手动改参数、凌晨三点还在查 trace 的黑匣子工具包你手头有一套运行在 AIX 上的 Oracle 11g 生产库老板说“下季度必须迁到 Linux x86-64”DBA 小组翻遍 MOS 文档发现官方推荐路径是 Data Pump 手动重建但 3TB 数据78个表空间归档日志连续性要求让导出导入周期预估超 96 小时——业务方直接否决。这时有人甩出一个压缩包rman-xttconvert_2.0.rar。它不是 Oracle 官方安装介质没有 OPatch 验证解压后只有 5 个脚本、2 个配置模板和一份潦草的 README.txt。但它确实在多个金融客户现场跑通了跨平台、跨字节序、零停机窗口的物理块级迁移——核心就是用 RMAN 做增量备份用 XTTCross Platform Transportable Tablespaces机制做元数据缝合而xttconvert_2.0是把这套流程封装成可重复调用的 shell PL/SQL 组合体。它解决的不是“能不能迁”而是“怎么让 RMAN 在源端打快照、在目标端精准 apply 增量、且不因 block checksum、endian mismatch 或 tempfile 路径错位而报 ORA-19909 / ORA-19913”。适合已有 RMAN 备份习惯、熟悉 transportable tablespace 限制条件、能直连 ASM 或文件系统、并愿意为每个表空间单独调试的中级以上 DBA。别指望它替代 ADG也别想用它迁 SYSTEM 表空间——那是它的硬边界。2. 从解压到首次 runXTTCONVERT 2.0 的最小可行执行链与 RMAN 增量链路对齐XTTCONVERT 2.0 不是独立工具它是 RMAN 备份策略的“胶水层”。它的价值不在代码多炫酷而在把backup for transport、convert datafile、incremental level 1这三类 RMAN 操作用固定命名规则、可控时间戳、可重入的脚本逻辑串起来。下面带你走通最简路径源库AIX Oracle 11.2.0.4→ 目标库Linux x86-64 Oracle 12.1.0.2仅迁移 USERS 表空间。2.1 解压即用看清目录结构与关键文件职责unrar x rman-xttconvert_2.0.rar ls -l # 输出 # drwxr-xr-x 2 oracle oinstall 4096 Jun 15 2022 backup/ # -rw-r--r-- 1 oracle oinstall 2345 Jun 15 2022 xtt.properties # -rwxr-xr-x 1 oracle oinstall 5678 Jun 15 2022 xttconvert.sh # -rwxr-xr-x 1 oracle oinstall 3210 Jun 15 2022 xttdriver.pl # -rwxr-xr-x 1 oracle oinstall 1890 Jun 15 2022 xttpreparesrc.sql # -rwxr-xr-x 1 oracle oinstall 2045 Jun 15 2022 xttpreparedest.sql提示xtt.properties是唯一需人工编辑的配置文件xttconvert.sh是主入口它会按顺序调用xttpreparesrc.sql源端准备、xttdriver.pl驱动 RMAN 备份与传输、xttpreparedest.sql目标端元数据注入。backup/目录是输出区所有生成的.bkp、.df、.inc文件都落在此处。2.2 配置 xtt.properties6 个必填字段决定迁移成败xtt.properties中以下字段必须严格匹配你的环境漏填或格式错将导致xttdriver.pl启动即退出参数名示例值说明关键约束src_dbid1234567890源库 DBID查SELECT dbid FROM v$database;必须数字不能带空格或逗号dest_dbid9876543210目标库 DBID同上两库 DBID 绝对不可相同否则增量无法识别tablespaceUSERS待迁移表空间名区分大小写只支持单表空间多表空间需多次运行platformAIX-Based Systems (64-bit)源平台名必须与 v$database.platform_name 完全一致错写成AIX或IBM/AIX会导致 convert 失败dest_platformLinux x86 64-bit目标平台名查SELECT platform_name FROM v$database;同上大小写、空格、括号缺一不可backup_format/u01/backup/%URMAN 备份片路径模板%U为必需占位符必须有写权限且目标端能通过 NFS 或 scp 访问该路径# xtt.properties 示例仅关键行 src_dbid1234567890 dest_dbid9876543210 tablespaceUSERS platformAIX-Based Systems (64-bit) dest_platformLinux x86 64-bit backup_format/u01/backup/%U参数说明backup_format不是最终备份路径而是 RMANbackup as compressed backupset for transport命令中的format子句。XTTCONVERT 会自动在该路径下生成形如0123456789ABCDEF0123456789ABCDEF_1_1.bkp的文件并同步生成USERS_1.bkp符号链接。目标端xttdriver.pl会根据此路径拉取文件因此该路径必须对源库 Oracle 用户可写、对目标库 Oracle 用户可读通常通过 NFS 共享或提前 scp。2.3 源端执行 xttconvert.sh触发 RMAN 全量 增量备份链进入解压目录以源库 Oracle 用户身份执行./xttconvert.sh --prepare该命令实际执行三步运行xttpreparesrc.sql检查表空间状态必须READ ONLY、生成xttplan.txt记录数据文件绝对路径与 block size、创建xttnewdatafiles.sql目标端创建数据文件的 DDL调用xttdriver.pl启动 RMAN执行backup for transport全量备份并立即打一个level 1 cumulative增量备份用于后续追增量生成xttplan.txt和xttnewdatafiles.sql到backup/目录。# 执行后关键输出示例 # INFO: Starting prepare phase for tablespace USERS # INFO: Source database platform: AIX-Based Systems (64-bit) # INFO: Backup piece generated: /u01/backup/0123456789ABCDEF0123456789ABCDEF_1_1.bkp # INFO: Incremental backup piece generated: /u01/backup/0123456789ABCDEF0123456789ABCDEF_2_1.bkp # INFO: xttplan.txt and xttnewdatafiles.sql written to backup/逻辑说明--prepare并非真正迁移而是建立“基线”。它要求源表空间在备份期间保持READ ONLY因此业务停写窗口从此刻开始计算。xttplan.txt是后续所有步骤的“地图”里面每行包含datafile_id,file_name,block_size,bytes目标端xttpreparedest.sql会逐行解析它来校验文件完整性。3. 目标端接收与注入如何让 Linux 上的 Oracle “认出” AIX 的数据文件源端--prepare完成后backup/目录下已有USERS_1.bkp全量、USERS_1.inc首个增量、xttplan.txt、xttnewdatafiles.sql。这四件套必须完整传到目标端同一目录如/u01/xtt/backup/然后启动目标端流程。3.1 传输文件scp vs NFS选哪个更稳# 推荐方式源端打包目标端解压避免单文件传输中断 # 源端 cd /path/to/xtt/ tar -cf xtt_backup.tar backup/ gzip xtt_backup.tar # 目标端 scp oraclesource:/path/to/xtt/xtt_backup.tar.gz /u01/xtt/ cd /u01/xtt/ gunzip xtt_backup.tar.gz tar -xf xtt_backup.tar为什么不用 NFSNFS 在跨平台AIX→Linux挂载时若未显式设置nfsvers3和hard,intrRMAN 读取.bkp文件可能因 inode 缓存不一致报ORA-19505: failed to identify file。而scp保证字节级一致且xttdriver.pl内部对本地文件路径做了硬编码校验stat检查 mtime/sizeNFS 的缓存延迟易触发误判。3.2 目标端执行 xttconvert.shconvert restore switch# 确保目标库已启动到 MOUNT 状态非 OPEN sqlplus / as sysdba EOF SHUTDOWN IMMEDIATE; STARTUP MOUNT; EXIT; EOF # 进入目标端 XTT 目录执行 ./xttconvert.sh --restore该命令执行运行xttpreparedest.sql创建临时表空间XTT_TEMP校验xttplan.txt中每个数据文件的block_size是否与目标库db_block_size匹配调用xttdriver.pl启动 RMAN执行convert from platform将 AIX 的 big-endian 块转为 Linux little-endian再restore到目标路径最后switch datafile all更新控制文件中数据文件指针。# 关键日志片段 # INFO: Converting datafile /u01/backup/USERS_1.bkp to /u01/oradata/PROD/users01.dbf # INFO: RMAN CONVERT DATAFILE /u01/backup/USERS_1.bkp # FROM PLATFORM AIX-Based Systems (64-bit) # DB_FILE_NAME_CONVERT /u01/backup/,/u01/oradata/PROD/ # INFO: Switching datafile 5 to /u01/oradata/PROD/users01.dbf参数说明DB_FILE_NAME_CONVERT是xttdriver.pl自动拼接的其值来自xtt.properties中backup_format的路径前缀与目标数据文件路径的映射。若你的目标路径是 ASM需提前在xtt.properties中设dest_asm_diskgroupDATA脚本会自动替换为DATA/PROD/DATAFILE/USERS.256.12345。3.3 手动注入元数据绕过impdp的 schema-level 陷阱XTTCONVERT 2.0 不调用 Data Pump。它用xttpreparedest.sql中的DBMS_TTS.TRANSPORT_SET_CHECK和CREATE TABLESPACE ... DATAFILEDDL 注入元数据。但注意xttnewdatafiles.sql生成的 DDL 默认指向文件系统路径若目标用 ASM必须手动修改-- 原始 xttnewdatafiles.sql文件系统 CREATE TABLESPACE USERS DATAFILE /u01/oradata/PROD/users01.dbf SIZE 1G; -- 修改为 ASM需先查 ASM alias SELECT name FROM v$asm_alias WHERE system_createdN AND name LIKE %USERS%; -- 返回 DATA/PROD/DATAFILE/USERS.256.12345 -- 则改为 CREATE TABLESPACE USERS DATAFILE DATA/PROD/DATAFILE/USERS.256.12345 SIZE 1G;为什么必须手动xttconvert.sh --restore只负责物理文件转换与 restore元数据创建由xttpreparedest.sql执行而该 SQL 是静态生成的不感知 ASM。跳过此步直接ALTER DATABASE OPEN会报ORA-01157: cannot identify/lock data file—— 控制文件里记录了文件路径但实际文件在 ASM路径不匹配。4. 增量同步与回退用 RMAN 实现分钟级精度的“按需回退”rman-xttconvert_2.0.rar的核心价值不在首次迁移而在后续增量同步。当源库在--prepare后继续写入你需要定期追增量直到割接窗口。XTTCONVERT 2.0 支持--incremental模式它利用 RMAN 的incremental level 1备份实现比archive log应用更细粒度的恢复点。4.1 源端追增量--incremental的三次调用节奏# 第一次增量距 --prepare 2 小时后 ./xttconvert.sh --incremental # 第二次增量再过 1 小时 ./xttconvert.sh --incremental # 第三次增量割接前 5 分钟 ./xttconvert.sh --incremental每次执行生成一个USERS_N.incN 为序号并更新xttplan.txt中的checkpoint_scn。xttdriver.pl会自动识别上次增量的 SCN只备份该 SCN 之后的 block change。RMAN 增量原理--incremental调用的是backup incremental level 1 for transport它依赖源库的block change trackingBCT文件。若未启用 BCTRMAN 会全扫描数据文件耗时剧增。务必在源库执行ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE /u01/oracle/bct.f;4.2 目标端应用增量--apply的原子性保障目标端收到新USERS_2.inc后执行./xttconvert.sh --apply该命令等价于-- 在目标库 MOUNT 状态下 RECOVER DATAFILE /u01/oradata/PROD/users01.dbf OF TABLESPACE USERS FROM /u01/xtt/backup/USERS_2.inc;关键约束--apply必须在--restore之后、ALTER DATABASE OPEN之前执行。若已 OPEN则需先SHUTDOWN IMMEDIATE→STARTUP MOUNT否则报ORA-01126: database must be mounted in exclusive mode。4.3 “按分钟回退”的实操用 SCN 锚定精确恢复点标题中“rman备份 按分钟回退”并非虚言。XTTCONVERT 2.0 的--incremental生成的.inc文件自带 SCN 时间戳。你可在割接前 1 分钟在源库查当前 SCNSELECT CURRENT_SCN, TO_CHAR(SYSDATE, YYYY-MM-DD HH24:MI:SS) FROM v$database; -- 返回1234567890123, 2024-06-15 23:59:59然后在目标端--apply时指定 SCN# 修改 xtt.properties添加 apply_until_scn1234567890123 # 再执行 ./xttconvert.sh --applyxttdriver.pl会解析.inc文件只应用 SCN ≤apply_until_scn的块变更跳过之后的。这比recover database until time更精准——后者受 NLS_DATE_FORMAT 影响而 SCN 是绝对数字。血泪经验apply_until_scn必须小于等于.inc文件中记录的最大 SCN否则--apply报ORA-19907: datafile was not found。可用strings USERS_2.inc | grep SCN快速查看文件内嵌 SCN 范围。5. 避坑指南XTTCONVERT 2.0 的 4 个真实翻车现场与后悔药XTTCONVERT 2.0 的文档稀烂错误信息晦涩以下是你大概率会踩的坑按现象→原因→解决结构整理每条都来自真实生产事件。5.1 现象xttdriver.pl报Cant locate DBD/Oracle.pm脚本直接退出原因xttdriver.pl是 Perl 脚本依赖DBD::Oracle模块连接数据库。目标端若未装 Oracle Instant Client Perl DBI/DBD模块缺失。解决# 目标端Linux安装 yum install perl-DBI perl-DBD-Oracle # 确保 ORACLE_HOME、LD_LIBRARY_PATH 已设 export ORACLE_HOME/u01/app/oracle/product/12.1.0/dbhome_1 export LD_LIBRARY_PATH$ORACLE_HOME/lib:$LD_LIBRARY_PATH # 验证 perl -MDBD::Oracle -e print OK\n5.2 现象--restore时 RMAN 报ORA-19505: failed to identify file但文件明明存在原因.bkp文件被unzip或tar解压时损坏尤其 Windows 传过来的 rar 包。XTTCONVERT 对文件 CRC 校验极严xttplan.txt中记录的bytes与实际文件 size 不符即失败。解决源端重新rar a -md5打包强制 MD5 校验目标端用cksum对比cksum /u01/xtt/backup/USERS_1.bkp # 与源端输出对比必须完全一致5.3 现象--apply后ALTER DATABASE OPEN报ORA-01157: cannot identify data file原因xttnewdatafiles.sql创建表空间时DATAFILE路径写死为文件系统但实际文件在 ASM或路径权限不对Oracle 用户无读权限。解决检查v$datafile中该数据文件路径是否与xttnewdatafiles.sql一致若用 ASM手动ALTER DATABASE CREATE DATAFILE /u01/oradata/PROD/users01.dbf AS DATA/...;chmod 640确保.dbf文件属组为oinstall。5.4 现象--incremental生成的.inc文件体积异常小1MB但源库写入量很大原因源库未启用block change trackingRMANincremental level 1变成全量扫描但 XTTCONVERT 脚本默认只保留最近 1 个.inc旧文件被覆盖。解决立即启用 BCT见 4.1 节修改xttconvert.sh注释掉清理旧.inc的rm命令手动保留所有.inc按时间顺序--apply。注意rman delete archive类操作与 XTT 无关切勿在源库执行DELETE ARCHIVELOG否则--incremental依赖的归档日志丢失增量链断裂。6. 进阶技巧用 RMAN LIST BACKUP 做增量链健康度验证与故障定位XTTCONVERT 2.0 不提供增量链可视化但 RMAN 自带LIST BACKUP命令可成为你的“后悔药探测器”。当--apply失败别急着重跑先用以下三步定位是哪一环断了。6.1 查源库增量链完整性确认 level 1 备份连续性在源库 RMAN 中执行RMAN LIST BACKUP BY FILE WHERE COMPLETION_TIME SYSDATE-7 AND BACKUP_TYPE I ORDER BY COMPLETION_TIME;输出应类似List of Datafile Backups File Key Thrd Seq S Completion Time #Pieces #Copies Compressed Tag ---- ---- ----- ----- - ---------------- ------- ------- ---------- --- 5 1 123 1 A 2024-06-15 22:00:00 1 1 YES XTT_INC_1 5 1 124 1 A 2024-06-15 23:00:00 1 1 YES XTT_INC_2 5 1 125 1 A 2024-06-15 23:55:00 1 1 YES XTT_INC_3关键看Thrd Seq列它表示该增量备份覆盖的归档日志序列号范围。若123后直接125说明124序列归档丢失--incremental生成的USERS_2.inc将不完整。此时需从源库ARCHIVE LOG LIST查Oldest online log sequence确认归档是否被rman delete archive清理。6.2 查目标端已应用 SCN反向推导最后一次成功增量在目标库MOUNT 状态查SELECT file#, checkpoint_change#, last_change# FROM v$datafile WHERE name LIKE %USERS%;返回checkpoint_change# 1234567890123则说明USERS_2.inc含 SCN 1234567890123已成功应用。若last_change#为空说明数据文件仍为READ ONLY状态--apply未执行或失败。6.3 用 RMAN VALIDATE 检验 .inc 文件有效性避免传输损坏在目标端 RMAN 中对.inc文件做块级校验RMAN VALIDATE BACKUPSET /u01/xtt/backup/USERS_2.inc;若返回validation complete说明文件未损坏若报ORA-19624: operation failed with error ORA-19625则文件 CRC 错必须重传。6.4 表格XTTCONVERT 2.0 各阶段 RMAN 命令映射与可调试参数XTT 阶段等效 RMAN 命令可调试关键参数调试方法--prepareBACKUP FOR TRANSPORT FORMAT /u01/backup/%U TABLESPACE USERSFORMAT,MAXSETSIZE,DEVICE TYPE DISK PARALLELISM 4在xttdriver.pl中搜索backup for transport修改$rman_cmd变量--incrementalBACKUP INCREMENTAL LEVEL 1 FOR TRANSPORT FORMAT /u01/backup/%U TABLESPACE USERSLEVEL 1 CUMULATIVE,TAG XTT_INC_N修改xtt.properties中incremental_tagXTT_INC_2--restoreCONVERT DATAFILE /u01/backup/USERS_1.bkp FROM PLATFORM AIX... DB_FILE_NAME_CONVERT ...CONVERT,DB_FILE_NAME_CONVERT,NOFILENAMECHECK在xttpreparedest.sql中添加SET NOFILENAMECHECK--applyRECOVER DATAFILE /u01/oradata/PROD/users01.dbf FROM /u01/xtt/backup/USERS_2.incUNTIL SCN,AUXILIARY DESTINATION手动执行RECOVER ... UNTIL SCN 1234567890123测试我干这活五年最深的教训是永远在--prepare前用rman backup validate check logical database扫一遍源库数据文件——XTTCONVERT 不做逻辑坏块检查它只信 RMAN 的物理块。一个隐藏的ORA-01578会在--apply时让你凌晨三点对着ORA-19913发呆。希望帮到你。本文还有配套的精品资源点击获取
