虚谷数据库迁移工具Windows版64位：异构迁移的DDL转换与断点续传实战

简介面向数据库管理员、运维人员及需要跨平台迁移数据的IT团队这套Windows 64位虚谷数据库迁移工具提供了从源库到目标库的ETL迁移能力支持MySQL、Oracle、SQL Server等关系型数据库及常见非关系型数据库可有效降低升级系统或更换数据库管理平台时的数据丢失与迁移风险。压缩包共包含252个文件以140个jar核心程序、42个dll动态库、18个exe可执行入口和12个properties配置文件为主另有pdf与txt说明文档整体约132.98MB目录内还包含证书、安全策略、字体、JVM运行配置等依赖组件结构上覆盖运行库、脚本入口与验证材料便于按模块检索。目前已有336人学习下载。使用者可在Windows环境中直接部署通过图形界面或自定义迁移规则完成迁移前验证、过程监控与迁移后数据校验工具内含大量jar、dll与exe运行组件可直接运行的迁移环境便于检查底层依赖pdf与txt说明文档、运行脚本也有助于排查环境问题。适合需要稳妥完成数据库割接的中高级技术人员同时对不熟悉命令行操作的用户提供了较友好的图形化引导。1. 迁移的坑都在细节虚谷数据库迁移工具Windows版 64位到底能帮你省什么数据库迁移的瓶颈从来不在网速而在结构转换和类型映射。某公司上线三年的 ERP 跑在 Windows Server 上源库是老牌商业数据库合同期内要完成国产数据库替换虚谷数据库迁移工具Windows版 64位就是这种情况下会用到的方案把元数据抽取、DDL 转换、数据分片搬运、断点续传封装在一个 Windows 图形界面加命令行双模式工具里。适合数据库运维、实施工程师和要接手国产化的应用团队。接下来从环境准备讲到迁移任务配置再到我踩过的五个坑照着做能少熬几个通宵。2. 这个迁移工具是什么先搞清楚它和手工脚本、通用ETL的本质差别2.1 迁移工具解决的核心问题异构DDL转换与数据搬运先明确一个概念数据库迁移最耗时间的不是“把数据导出来再导进去”而是“让目标库能读懂源库的结构”。以最常见的 Oracle 到虚谷为例Oracle 的 NUMBER(10) 在虚谷里可能是 INTOracle 的 VARCHAR2 在虚谷里通常对应 VARCHAROracle 的序列 SYS_C001234 在虚谷里没有同名的实现方式。如果手工去导要把建表语句逐行改过、把函数和存储过程重写一遍还要处理自增列的生成策略。迁移工具做的事情就是把这些规则变成了一张可编辑的映射表自动翻译 DDL 并按依赖顺序建对象——先建表、再建索引、再建约束避免因为外键存在导致建表失败。数据搬运阶段工具会按主键或唯一索引把大表切成若干分片用多线程读源库、批量写目标库。这个分片逻辑很关键它决定了迁移过程的稳定性和断点续传的粒度。没有分片的话一张上亿行的表从头读到尾中途任何网络抖动都要全部重来。所以我的判断标准很简单结构对象超过 100 个、单表行数超过 500 万、或者源库和目标库不是同一个厂商的产品都值得用迁移工具而不是手工脚本。2.2 和 expdp/impdp、通用ETL工具的选型对比很多同行拿到迁移任务第一反应是用源库自带的数据泵或者某个开源 ETL 平台。我做过几次对比结论是这几个方案各有边界方案DDL转换断点续传类型映射适用场景源库自带数据泵不支持部分不支持同厂商迁移通用ETL平台不支持要看组件手动配置数据仓库、数采专用迁移工具内置内置可编辑异构数据库整体迁移源库自带数据泵在异构迁移里基本没用导出来的是源库语法目标库不认。通用 ETL 平台擅长的是持续的数据同步和加工但你要自己写建表脚本、自己处理序列和存储过程等于一半的迁移工作还是手工完成。迁移工具这一类把重心放在“一次搬完、搬得对”上DDL 自动翻译、类型自动映射、断点续传是它天然要解决的问题。给一个实际参考某公司一个 2TB 的库对象 800 多个其中表 300 张用迁移工具全量迁移在不调优的情况下跑了 9 小时如果纯手工改 DDL光结构部分就花了 4 天。省下的时间主要来自 DDL 转换和类型映射的自动化而不是数据搬运本身。2.3 Windows 64位环境下的准备项JDK、路径和权限标题里带了 Windows 版 64 位说明目标运行环境是 Windows 桌面或服务器的 64 位操作系统。我建议的基线是 Windows Server 2016 / 2019 / 2022Windows 10 和 Windows 11 也能跑前提是系统语言和字符集不乱。环境准备有四个点。第一JDK。这类工具通常基于 Java至少要求 JDK 8 及以上。确认方式是在命令行执行java -version如果是 32 位 JDK 配 64 位工具启动时会直接报错。常见做法是安装 64 位 JDK并把JAVA_HOME环境变量指到 JDK 安装目录。第二安装路径。不要装在C:\Program Files下路径里的空格会让批处理脚本里的参数解析出问题也不要放在带中文的目录里后面配置文件和日志路径很容易出现编码问题。我一般放在D:\tools\migration-tool这种纯英文短路径下。第三驱动。工具能连什么源库取决于驱动包放没放对位置。Oracle 的 ojdbc、MySQL 的 Connector/J、SQL Server 的 mssql-jdbc这些 jar 文件要放到工具的 driver 目录并在配置里引用。Windows 下特别容易忽略一件事情下载的是 64 位版本的驱动而源库客户端是 32 位两者混用时连接会莫名失败。第四权限。工具的图形界面和命令行如果以普通用户运行写 logs 目录和临时目录时会碰壁。常见做法是以管理员身份运行命令行窗口再启动工具或者给工具目录赋写权限而不是用右键“以管理员身份运行”去处理每一个脚本——那样反而容易出现路径上下文不一致。2.4 工具自带的日志能帮你省多少排查时间迁移工具的价值还体现在日志上。它通常会按任务输出独立的日志文件包含每个对象的迁移开始时间、结束时间、行数、失败原因。这个日志的详细程度决定了排错是小时级还是分钟级。我习惯在第一次跑任务时把日志级别调到 DEBUG确认源库连接、元数据抽取、DDL 生成这几步都正常后再调回 INFO 跑全量。DEBUG 日志里能看到每一条被翻译后的建表语句这对排查类型映射问题是决定性的。Windows 下工具自身的日志文件一般落在工具的 logs 目录和 Windows 安全日志是两回事排查数据库迁移问题先看工具日志不要一上来就去翻系统事件查看器。3. 部署启动流程把 Windows 版跑起来的最小动作3.1 目录结构与启动方式双击 vs 命令行拿到 Windows 64 位迁移工具的解压包后目录结构通常是固定的几块bin 放启动脚本和可执行文件conf 放连接配置和日志配置logs 放运行日志driver 放数据库驱动。这个结构不用背但要知道启动脚本在 bin 下、配置在 conf 下。启动有两种方式。图形界面版双击 bin 下的启动脚本即可命令行版可以在终端里直接运行适合在服务器上配合计划任务使用。这里有个 Windows 下很常见的细节双击启动脚本时窗口闪一下就没了多半是脚本本身报错退出了。闪退的原因通常是找不到 Java 环境或者脚本里引用的相对路径不对。我一般不会直接双击而是先在命令行里手动执行启动脚本让报错停留在屏幕上cd /d D:\tools\migration-tool\bin migrate.bat这个命令的作用是切换到工具目录后再执行启动脚本。在 Windows 的 cmd 里/d参数允许同时切换盘符和目录。直接在资源管理器双击脚本如果报错窗口会瞬间关闭看不到任何信息用命令行跑报错会留在屏幕上能看出是缺 JDK 还是缺配置文件。启动成功后会弹两个窗口一个是控制台日志一个是主界面。控制台日志窗口不要关关闭它等于强杀进程。如果你用的是命令行模式前台进程会占据当前终端配合日志参数可以详细观察每一批数据的写入情况。3.2 连接配置源库、目标库的参数写在哪、怎么写启动后第一步是配置连接。图形界面里一般有“源库配置”和“目标库配置”两个页签底层写入的是同一个配置文件。我见过不少人只在界面上填了连接信息重启工具后信息又不见了就是因为界面配置和数据落盘没有同步。稳妥的做法是直接编辑配置文件再在界面里加载它。配置文件常见为 properties 或 yaml 格式核心参数如下# 源库连接配置 source.typeoracle source.host192.168.10.20 source.port1521 source.serviceNameORCL source.usernamescott source.password按实际填写 source.encodingGBK # 目标库连接配置 target.typexugu target.host192.168.10.30 target.port5132 target.databaseappdb target.usernamexugu target.password按实际填写 target.encodingUTF-8 # 迁移任务参数 task.batchSize1000 task.threadCount4 task.resume.enabletrue task.resume.chunkSize500000这里每一组参数的作用要理清楚。source.encoding和target.encoding是字符串转换的源头源库是 GBK、目标库要 UTF-8如果不显式指定工具会用 JVM 默认字符集Windows 中文版 JVM 默认通常是 GBK迁移到 UTF-8 的目标库就可能乱码。task.batchSize是单批写入行数1000 行是一个保守值。task.threadCount是数据搬运线程数不是越大越好后文专门讲。task.resume.enable控制断点续传task.resume.chunkSize是分片大小500000 行一个分片中断后可以从分片边界继续而不是从头再来。3.3 JVM 内存与日志级别第一次跑全量前必须调的两个参数工具默认的 JVM 堆内存一般只有 512MB 或 1GB跑大表迁移时会频繁触发 Full GC表现为“数据搬运速度突然掉到零”。在启动脚本里调整内存是常见操作Windows 批处理里一般长这样set JAVA_HOMED:\tools\jdk8 set MIGRATE_OPTS-Xms512m -Xmx4096m -Dfile.encodingUTF-8 %JAVA_HOME%\bin\java.exe %MIGRATE_OPTS% -jar migration-tool.jar %*-Xms512m是初始堆大小-Xmx4096m是最大堆大小。对于 2TB 级别的元数据抽取任务4GB 是起步值如果机器内存 16GB我习惯给到 6GB。-Dfile.encodingUTF-8是强制 JVM 用 UTF-8 处理文件读写避免 Windows 默认编码干扰日志和 SQL 文件输出。日志级别在 conf 下的日志配置文件里调常见值是 INFO 和 DEBUG。第一次跑通连接阶段用 INFO进入大表搬运阶段如果怀疑分片逻辑有问题临时切成 DEBUG能看每张表的分片范围。日志级别调完要重启工具才生效这一点和改配置文件一样别在界面上点完设置就以为生效了。4. 配置迁移任务表、类型、并发参数一起调才不出幺蛾子4.1 对象选择与映射规则先学会控制迁移范围迁移任务的核心是“选择哪些对象、以什么规则映射”。这一步决定了迁移结果和源库的相似度。对象选择分为表、视图、序列、索引、约束、存储过程、函数、触发器几类。第一次迁移我建议只选表和序列跑通后再补索引和约束。原因是索引和约束在数据搬运完成之后创建顺序上更合理存储过程和函数只要有一条语法不兼容整个任务可能被标记为失败而实际上表数据已经迁移成功了。映射规则里最常用的是表名映射和类型映射。表名映射解决的是源库表名太长、大小写不一致的问题类型映射解决的是源库类型在目标库没有一一对应的问题。类型映射界面上通常有“默认映射”和“自定义映射”两个视图默认映射是工具内置的对应关系自定义映射允许把源库的 VARCHAR2(4000) 统一映射为目标库的 VARCHAR(4000)或者把 CLOB 映射为 TEXT。这里我给一个实用建议第一次跑任务时把映射规则导出留存等迁移完成后再对照目标库实际建出的表结构微调。不要依赖工具的“自动推荐映射”一步到位自动推荐基于源库元数据未必考虑到了应用层对字段长度的依赖。4.2 批量大小与线程数性能参数的正确打开方式数据搬运的性能参数是迁移任务里最容易“照抄别人作业翻车”的部分。某些教程推荐 batchSize 设成 10000、线程数设成 16看起来很猛实际上小内存机器直接 OOM或者目标库写入锁竞争严重整体吞吐反而下降。我按源库类型和目标库规格给出一组基线实际操作时从这组值开始往两边探场景batchSizethreadCount说明小表100万行5002稳定优先大表1000万行级20004平衡吞吐和内存超大表上亿行10008用并发保吞吐批小一点源库是Oracle10004Oracle读游标本身有开销目标库并发写入弱5002避免锁等待堆积这个表的逻辑是批量大、单条记录也长时内存消耗是乘积级别的。一张表平均单行 10KBbatchSize 10000 意味着单批要攒 100MB 数据再乘上线程数内存很容易吃不消。我的经验是先跑一张中等大小的表观察工具日志里“写入耗时”的变化逐步调大 batchSize直到耗时不再下降为止。另外要留意工具是读一条写一批还是读一批写一批。前者在断点续传时只需要记录批号后者要记录偏移量。如果是记录偏移量主键不是递增的乱序表会出问题建议按主键分片而不是按行数分片。提示调整 batchSize 后如果日志里频繁出现 Full GC说明堆内存不足优先调大 -Xmx 而不是继续降 batchSize。4.3 断点续传与校验迁移中断后怎么稳到终点断点续传是迁移工具相比手工脚本最有价值的能力。它的原理是把每个分片的迁移状态记录到工具的元数据表里某分片未完成就标记为 pending中断后重新启动任务只处理 pending 的分片其他分片跳过。使用断点续传前要确认两件事。第一所有大表都要有主键或唯一索引。没有主键的表无法稳定分片工具通常会退化为单线程整表搬运中断后从头再来。第二断点记录本身如果放在目标库目标库不可用时断点也读不到放在本地文件时则要求本地磁盘不清理日志目录。我习惯用本地文件方式因为迁移工具跑在 Windows 服务器上目标库重启不影响断点状态。迁移完成后不要急着切流量。先做行数校验用工具自带校验功能或者外部 SQL 对比。行数校验通过只能说明“记录条数一致”说明不了“内容一致”。更严格的校验是主键级别对比把源库和目标库的主键集合拉出来做差集这一步能发现重复插入、分片边界重复的问题。5. 迁移工具Windows版避坑指南现象、原因、解决5.1 启动脚本闪退或双击无反应现象双击 bin 下的启动脚本窗口一闪而过工具没有起来。原因最常见的是系统里没装 JDK或者JAVA_HOME指向了 32 位 JDK其次是脚本所在路径有空格或中文导致批处理里的%JAVA_HOME%或相对路径解析失败。解决先在命令行里手动执行启动脚本让报错留在屏幕上。报错若提示找不到 Java就安装 64 位 JDK 并设置JAVA_HOME。把工具整个目录移到纯英文短路径下比如D:\tools\migrate。Windows 脚本命令闪退这个现象不只在迁移工具上有任何 Java 系工具在 Windows 上都可能遇到排查思路都是先命令行看报错。5.2 测试连接报超时驱动版本和端口占用一起查现象图形界面里测试源库连接几秒后提示超时或无法连接。原因我遇到过三种。第一驱动 jar 没放对位置第二源库端口被本机其他进程占用第三Windows 防火墙放行了工具进程但没放行 JDK 进程。解决先在命令行里确认端口监听状态netstat -ano | findstr :1521这条命令的作用是列出所有监听 1521 端口的进程及其 PID。在 Windows 上要关闭占用的端口先确定 PID 再决定是结束进程还是改端口。如果端口被占用拿到 PID 后用taskkill //PID 1234 //F结束占用进程或者改迁移工具连接的端口。如果端口空闲再用驱动自带的连接工具测试 JDBC 连通性。注意 Windows 防火墙有时会因为 Java 进程名和工具进程名不同而拦截需要放行java.exe或 JDK 安装目录。5.3 中文数据迁移后乱码现象表结构迁移正常数据条数也对但查询结果里中文变成问号。原因源库字符集与source.encoding参数不一致。典型情况是源库实际是 GBK连接参数里没写编码JVM 按 UTF-8 读取中文字符被解码成乱码后写入目标库。解决在配置文件里显式指定source.encodingGBK、target.encodingUTF-8并确认目标库建表时指定了字符集。如果工具连接串是 JDBC URL 形式还要在 URL 里追加characterEncodingGBK或useUnicodetruecharacterEncodingUTF-8。改完参数后重新迁移一张小表验证不要直接全量重跑。5.4 大表迁移OOM或速度归零现象任务跑到一半工具进程无响应任务日志里出现内存溢出或者数据搬运速度从每秒上万行掉到几十行。原因批量插入攒的数据超过 JVM 堆上限。Windows 下 JVM 默认堆只有物理内存的四分之一任务并发调高后堆不够用。解决启动脚本里把-Xmx提到 6GB 或更高并适度降低batchSize和threadCount。我的经验是内存 16GB 的机器-Xmx4096mbatchSize 1000threadCount 4组合比-Xmx2048mbatchSize 10000threadCount 8稳定得多且总耗时更短。原因是大批量加高并发会让 JVM 频繁 Full GCGC 暂停反而吞噬了吞吐优势。5.5 校验行数一致但内容对不上现象迁移完成后行数校验一致业务查询时发现部分记录的主键存在但字段值错误。原因分片边界重复写入同一行被两个分片同时处理或者源表存在触发器读取时触发了数据变更。解决分片方式从“按行数切片”改为“按主键范围切片”确保每个主键区间互不重叠。如果源表有触发器在迁移配置里显式排除对源表的写操作影响只读数据。还有一招是校验时用主键加关键字段拼接后的哈希对比而不是只看行数这个放到最后一部分展开。6. 迁移后上线前我每次必做的三项验证6.1 主键差集对账把源库和目标库的钥匙串对齐行数一致不等于数据一致我吃过这个亏。某次迁移后 count 完全一致上线当晚业务方说“有个客户记录不见了”查到最后是分片边界重复A 分片写了主键 100 到 500B 分片又从 500 写了一遍行数没差但主键 501 到 600 的记录根本没被搬运。现在我做第一道验证固定用主键差集脚本-- 源库口令抽主键集合 SELECT id FROM source_table MINUS SELECT id FROM target_table;这个 SQL 的结果是有在源库但不在目标库的主键。反过来再跑一遍SELECT id FROM target_table MINUS SELECT id FROM source_table;后者能发现重复写入或源库无对应记录的多余数据。两道 SQL 都返回空集行数级校验才算通过。实际对大表跑这个 SQL 时按主键范围分片执行不要全表 MINUS否则源库和目标库都会被拖死。6.2 字段级抽样随机抽 5000 行做全字段哈希对比差集校验通过了字段值对不对还不一定。我一般会抽 5000 行做字段级对比用源库和目标库都能执行的哈希函数拼接所有字段后比较。做法是在源库随机取 5000 个主键把这批主键及关键字段导出为 CSV在目标库按同一批主键查出对应字段用脚本逐行对比。如果字段里有 CLOB 或 TEXT 大文本单独抽出来做长度和 MD5 对比避免整表对比时内存爆炸。这一步能把类型映射错误、字符集转换错误暴露出来是上线前最有价值的一道检查。6.3 把增量迁移注册成 Windows 计划任务上线后还能继续用全量迁移完成不代表工具使命结束。业务切换窗口内可能还有少量增量数据我用 Windows 任务计划程序注册一个每日增量迁移任务把工具的命令行模式包装成批处理定时执行。echo off cd /d D:\tools\migration-tool\bin migrate-cli.bat --task daily-sync --log-level INFO D:\tools\migration-tool\logs\sync.log 21这段批处理做了三件事切换到工具目录、以命令行模式执行增量任务、把所有输出追加到同步日志。--log-level INFO控制日志量避免每日任务把磁盘写满。注册计划任务时注意用“使用最高权限运行”并勾选“不管用户是否登录都运行”否则服务器重启后任务不会自动补跑。复盘一下我做过的最痛的一次迁移就是跳过了主键差集校验直接切流量结果上线当晚被业务方问“数据是不是少了”第二天回滚、重迁、加班补数。从那以后我把上面三项验证固化成上线流程哪怕只是几十张表的小迁移也不跳过。迁移这种事省掉一道校验省下的十分钟会在上线后的某个凌晨加倍还回来。希望帮到你。本文还有配套的精品资源点击获取