简介虚谷数据库迁移工具Windows 64位是一款面向数据库管理员与系统运维人员的迁移辅助软件用于在跨平台或跨版本场景下完成数据搬迁与系统升级尤其适合从旧数据库替换到新环境或更换数据库管理系统时的数据保障。压缩包共包含252个文件以jar、dll、exe等程序组件为核心其中jar为Java运行依赖dll提供底层系统调用exe为启动入口辅以properties配置、pdf说明文档、gif演示和启动脚本整体体积约133MB。目前已有336人学习/下载适合需要执行数据库迁移任务的开发与运维工程师。工具包内不仅提供可执行的迁移主程序还集成了证书、安全策略、类加载清单等运行支撑文件用户可在Windows 64位环境中直接部署借助其数据提取、转换与加载能力降低迁移风险同时依靠内置的配置模板与文档快速上手。1. 虚谷数据库迁移工具Windows 64位老系统替换的第一步也是最容易踩坑的第一步许多正在从Oracle或MySQL切换到虚谷数据库的团队一上来就卡在数据迁移。我见过不少项目把迁移评估做成“数据导出再导入”结果存储过程、序列、大字段在Windows端反复报错项目周期硬生生拖了两周才从坑里爬出来。虚谷数据库官方提供了Windows 64位下的图形化迁移工具能承担结构迁移、数据迁移和对象迁移这三件最主要的事。这篇笔记围绕“在Windows 64位环境里把这套工具用好”展开适合负责数据库替换、数据搬迁的工程师和运维人员也适合刚接到迁移任务、准备拿真实库做验证的开发者。2. 迁移工具的运行机制与安装准备先弄懂它怎么工作再决定从哪下手迁移工具本质上是一个运行在Windows上的Java应用它通过JDBC同时连接源数据库和目标虚谷数据库在内存里做数据读取、类型转换和写入。几乎所有Windows下的迁移事故都出在两个地方一个是Java进程的堆内存不够另一个是源库驱动版本和工具内置驱动冲突。所以安装不是“下一步下一步”就能完事先花十分钟把运行机制搞懂后面能省一整天的排错时间。2.1 迁移的四段式流程读取、转换、写入、校验常见做法是迁移工具会按照“读取源库元数据→生成目标库建表语句→批量抽取数据→写入目标库→记录日志”这个顺序工作。读取元数据阶段工具要查询源库的系统表或元数据视图拿到的字段类型、约束、索引和注释信息会作为后续建表语句的输入。这一阶段的耗时和源库的表数量成正比几千张表的实例可能要跑几分钟不要以为工具卡死了。接下来是生成建表语句工具会根据预置的类型映射规则把源库的NUMBER、VARCHAR2、TIMESTAMP这类类型翻译成虚谷数据库对应的类型。如果源库里有自定义类型或不常见的类型映射表里找不到对应项工具通常会把这种列标记为“跳过”或“转成文本”而不是直接报错退出。这一点对数据完整性影响很大后面会专门讲。数据抽取阶段决定了整个迁移的速度。工具用JDBC的ResultSet一行一行读出来再批处理写进目标库。批处理大小可以在配置里调整默认值一般不会太大遇到千万行级别的表适当调大批处理能明显缩短时间。最后是写入校验工具记录每个表的成功行数和失败行数失败行会落到日志表里迁移任务结束时能看到一份汇总。这个四段式设计决定了迁移工具的边界它能老老实实搬数据和结构的“形状”但搬不了源库里的应用逻辑。比如Oracle的物化视图刷新、定时任务、触发器之间的依赖顺序工具大多数情况下只负责生成对象定义不负责保证对象创建顺序所以迁移后的功能测试比迁移本身更费精力。注意工具是辅助不是全自动它处理的是数据搬迁和结构转换应用逻辑、权限体系、高可用方案都需要人工跟进。2.2 Windows 64位环境下的安装与启动参数调整虚谷数据库迁移工具在Windows环境下的安装包是标准安装程序安装过程本身没有太多可配置项。但安装目录下通常会带一个启动配置文件用来设置Java虚拟机参数。如果你是从其他数据库工具转过来很容易忽略这个文件直接双击快捷方式启动等到数据量一大就卡死或闪退。我一般会先检查安装目录下的配置文件确认如下两个参数# 启动参数示例实际参数名以安装目录下的 ini/conf 文件为准 JAVA_OPTS-Xms1024m -Xmx4096m # -Xms 是JVM启动时分配的初始堆内存-Xmx是最大堆内存 # 32位版本最大只能挖到1.5G左右64位版本才能把 -Xmx 往上拉这里就有个很典型的64位认知误区不是说系统是64位工具就自动吃满内存。JVM的堆大小上限还是要靠 -Xmx 参数指定。64位JDK的进程寻址空间大但如果不配置默认堆大小可能只有物理内存的1/4迁移大表时Full GC频繁界面上表现为长时间卡顿严重时直接假死。另一个常见的启动问题是端口冲突。迁移工具启动时会在本机开一个管理端口如果之前迁移进程没有正常退出残留的Java进程还占着端口再次启动就会提示端口被占用。遇到这种情况不一定要重启机器在PowerShell里查出端口对应的进程并结束掉就行# 查看端口占用情况把 2080 换成工具实际使用的端口 netstat -ano | findstr 2080 # 根据 PID 结束残留进程 taskkill /PID 这里填查到的PID /F参数调整完之后要用一个不重要的测试库先跑通最小流程确认工具能连上源库、能建表、能写数据再动真实库。虚拟机的快照或Windows的恢复点建议在安装和配置阶段就打好后面改配置出了岔子还能退回去。2.3 连接源库时驱动和网络的两个细节迁移工具能识别哪些源库取决于它在发布时内置了哪些JDBC驱动。Oracle、MySQL、SQL Server、PostgreSQL这四类是比较齐全的。连接配置界面上要填的通常是IP、端口、服务名或数据库名、用户名、密码。我经常遇到连不上源库的情况排查顺序是先看看是不是本机防火墙拦了出站访问再检查源库是否允许远程连接最后确认驱动版本和源库版本是否匹配。有一个细节容易被忽略Oracle的连接串里服务名和SID填错一个字符都连不上MySQL则要区分5.x和8.x驱动工具内置驱动如果是5.x连MySQL 8默认的认证插件就会报认证失败。常见做法是干脆用源库自带的命令行客户端先测一下连通性能连上再填到工具里这样可以避免在图形界面上反复填写、反复报错浪费时间。连接配置测试通过后工具会把源库的所有schema列表拉出来。这里要注意如果源库实例里有一堆系统schema或测试库迁移前最好在权限上做限制只给迁移账号授需要的库的读权限否则工具拉取元数据时会把无关的表也带出来迁移清单会非常混乱。迁移账号的权限建议给SELECT视图、存储过程的定义读取需要额外的SHOW VIEW或SELECT权限这一点因数据库而异提前确认能省很多事。3. 源库到虚谷数据库的映射规则类型、字符集、对象依赖是三大关口迁移工具替代人工搬运的地方就是它内置了一套从Oracle/MySQL到虚谷数据库的映射规则但这套规则不是万能的。实际迁移项目里人工要介入的部分集中在三块字段类型映射、字符集适配、对象创建顺序。这三块如果在迁移前不整理清楚到迁移中段就会频繁报错而且错误类型五花八门排查起来比刚开始多花数倍时间。3.1 数据类型映射先对照表再决定哪几列要人工干预工具内置的映射表解决的是常见类型我整理了一份实践中比较常用的对应关系。不同版本的虚谷数据库映射细节可能略有出入但大方向是一致的Oracle 类型虚谷数据库类型说明NUMBER(10)INT 或 BIGINT精度小于等于10通常映射为INT再大映射为BIGINTNUMBER(18,4)DECIMAL(18,4)带小数位的按DECIMAL保留精度VARCHAR2(200)VARCHAR(200)长度直接对应NVARCHAR2(200)VARCHAR(400)字符集不同时长度要按双倍预留DATETIMESTAMP虚谷无独立DATE类型时按此处理TIMESTAMP(6)TIMESTAMP(6)精度保持一致CLOBTEXT 或 CLOB大文本按目标库支持类型落BLOBBYTEA 或 BLOB二进制大对象迁移验证时重点抽查NUMBER到整型这行最容易出问题。Oracle的NUMBER不带精度时理论上是任意精度数值工具映射到虚谷数据库是哪一种类型直接决定了数据会不会失真。我的经验是迁移前先在源库跑一些统计找出所有NUMBER列里小数位不为零的样本如果数量大就要把对应列改成DECIMAL不能简单按“NUMBER映射为BIGINT”处理。VARCHAR2到VARCHAR看似直搬但有一个长度陷阱。Oracle的VARCHAR2长度单位是字节还是字符取决于数据库参数虚谷数据库的VARCHAR长度单位在不同版本里也有差异。如果两边单位不一致一个包含中文的字符串很容易在迁移后报“值超出长度”。稳妥的办法是把长度按字符数放大一点比如源库VARCHAR2(100)字符目标库建成VARCHAR(300)代价是存储空间多占一些但换取的是不用反复回来改表。提示BLOB/CLOB这类大字段在迁移时最耗时而且容易因为网络原因中途断开。建议单独为大字段表设置更长的超时时间不要和普通表混在同一个任务里跑。3.2 字符集引发的乱码问题Windows环境下的中文数据重灾区迁移工具本身在Windows上运行操作系统默认字符集、源库字符集、目标库字符集这三者只要有一个不匹配中文数据就会出现乱码。源头多半不在工具而在源库导出前的字符集设置。Oracle那边如果是AL32UTF8MySQL那边如果是utf8mb4情况会好一些如果源库还是GBK迁移到UTF-8的目标库工具转换时就要做一次转码。我自己踩过的一个坑是工具界面上字符集不设置默认按平台字符集处理Windows中文版下默认是GBK读UTF-8的源库数据界面显示正常但写入虚谷数据库之后就变成了乱码。后来在连接配置里明确了源库编码为UTF-8目标库编码也指定为UTF-8才恢复正常。验证字符集有没有问题最快的方法不是看界面预览而是在迁移完一个小表后直接在虚谷数据库查询工具里执行下面这句SQL看返回结果是不是和源库一致-- 在虚谷数据库侧检查表级别码是否正常 SELECT table_name, column_name FROM information_schema.columns WHERE table_schema 目标库名 AND table_name 表名;如果查询出来的数据没有问题再回头批量迁移这样可以把乱码问题控制在最小范围内。已经迁移完的数据发现乱码的话不要直接在目标库上改数据把对应的表删掉修正字符集配置后重新迁移那一批往往比重写数据更省事。3.3 对象依赖排序表和视图好搬序列、存储过程、触发器要排顺序结构迁移不是只有建表。序列、视图、存储过程、函数、触发器、同义词这些对象工具一般也支持迁移但对象之间有依赖关系。视图依赖表存储过程依赖表和视图触发器依赖表如果按字母顺序建对象先建视图、表还没建必然报“对象不存在”。常见做法是迁移前先把对象清单导出人工排一个创建顺序。顺序大致是表、序列、视图、函数、存储过程、触发器。如果工具支持“脚本式迁移”可以考虑把源库的对象定义导出来按依赖顺序整理后手动执行跳过工具内置的自动执行环节这样可控性更高。还有一种情况是工具虽然能在配置界面勾选“自动处理依赖”但跨类型的依赖它不一定能分析到。比如存储过程里动态拼接SQL访问别的表工具分析不出来迁移后在目标库执行存储过程才会报错。所以在对象迁移完成后不能只看“迁移成功”的状态要把每个存储过程和函数在目标库上单独执行一遍或者至少编译一遍。4. 跑通一次最小可用的全量迁移配置、执行、核对的三段实操前面把机制和映射讲清楚了这一章直接用操作路径走一遍。先选一张数据量中等的表做全量迁移验证连接、映射、字符集都没问题再扩展成整个schema的迁移。这样做的价值在于每一步的失败都能被快速定位而不是在几千张表的迁移日志里大海捞针。4.1 在工具里配置数据源和目标任务迁移工具主界面通常有“新建任务”或“迁移方案”的入口。先配置源连接和目标连接源连接按2.3节的方式填目标连接填虚谷数据库的连接信息。两边的连接配置里都要确认端口可达源库端口不通连不上目标库端口不通则迁移过程中会写失败。配置界面一般会有“最大连接数”和“批处理大小”两个参数这两个参数直接影响吞吐。我的经验取值如下参数建议初始值说明最大连接数4源库和目标库各自建立的连接数过大可能压垮源库批处理大小1000每批次写入的行数大表可以调大小表不必数据抽取超时300秒超过时间则整表标记失败避免任务卡死这两个参数不是越大越好。最大连接数调大并发读写是真的会快但源库如果是生产库连接数过高会挤占业务连接池引发生产告警。批处理大小也不是越大越好过大会占用更多JVM堆内存2G堆的情况下批处理调到5000以上内存占用会明显上升。建议先用默认值跑一张中等表观察工具日志里的耗时再逐步调整。来源库的时候尽量选择业务低峰期。工具读取数据会占用源库的I/O和CPU尤其大表全表扫描时对生产环境的压力不容小觑。我遇到过在交易高峰期跑迁移源库告警阈值被触发的情况后来所有迁移任务都安排在凌晨执行才算彻底解决。4.2 执行单表迁移并在目标库核对选一张业务表把迁移范围里只勾选这一张表运行任务。运行结束后工具会给出成功行数和失败行数。如果失败行数为0在目标库执行计数和样本对比-- 对比行数源库和目标库分别执行 COUNT(*) SELECT COUNT(*) FROM 源库schema.业务表; SELECT COUNT(*) FROM 目标库schema.业务表;-- 抽样对比关键字段建议取主键最大的前几条和随机的几条 SELECT * FROM 目标库schema.业务表 ORDER BY 主键列 DESC FETCH FIRST 10 ROWS ONLY;如果两张表表结构在迁移后已经约定好了可以直接对比行数确认没有丢数据。这里提醒一下COUNT()在数据量很大的表上比较耗时可以改用SUM(主键)或先查表统计信息但以行数为准的话COUNT()最可靠。单表迁移通过后再做全schema迁移。全量迁移过程中不要断开工具或者关闭电脑Windows系统休眠会导致JDBC连接断掉迁移任务中断。建议在迁移前把Windows电源计划改成“从不睡眠”并接上电源。真跑到一半断了工具普遍会记录断点重新执行时可以选择续传但要确认目标库里已有的数据不会重复写入产生主键冲突。4.3 理解迁移日志的三种级别成功、失败、跳过迁移工具的日志一般分为三部分任务级日志、表级日志、行级错误日志。任务级日志记录整个迁移的起止时间、读取行数、写入行数表级日志记录每张表的迁移结果和耗时行级错误日志记录某一行写入失败时目标库返回的错误信息。出问题时看行级错误日志的优先级最高。常见错误信息里“违反唯一约束”通常意味着目标库里已经有同主键的数据多半是上一次迁移残留或迁移范围重叠“字段值超长”多半是类型映射的长度设置问题“无法连接目标库”则要检查虚谷数据库的连接数和网络。把错误日志和表名对应起来看才能把问题定位到具体的映射规则上。工具跑完并不是终点。我的习惯是全量迁移结束后把源库和目标库的表清单导出做一次diff重点看三件事缺少哪些表、哪些表行数不一致、哪些表结构有差异。表结构差异可以执行系统视图查询来对比这一步很多人会省掉但恰恰是省掉之后上线阶段才会暴露字段缺失的问题。注意迁移日志要保留到项目验收之后不要任务跑完就删。增量迁移时还会用到这些记录用来确认全量迁移的基线和边界。5. 迁移工具的避坑记录五个真实踩过的坑附排查路径这一章写的都是我在实际迁移项目里碰到的、且反复出现的问题。写成“现象→原因→解决”的格式方便遇到问题时照着排查。5.1 启动秒退窗口一闪而过现象双击迁移工具快捷方式后界面闪现一下就没有了连错误提示都看不见。原因多半是Java运行时缺失或JVM参数异常。64位工具要求64位的JDK如果机器上装的是32位JDK工具启动时直接失败。也可能是配置文件里-Xmx参数写了一个超过物理内存的值JVM起不来。解决先用命令行手动启动把错误信息留下来。在安装目录下执行启动脚本如果提示“找不到Java”或“不支持的参数”再调整系统环境变量。确认JDK架构的方法java -version # 输出里如果是 32-Bit 字样说明是32位JDK必须换64位JDK再把配置文件里的-Xmx调到一个保守值比如2048m排除参数问题。如果命令行能启动但双击快捷方式不行说明快捷方式的工作目录或环境变量路径有问题手动修改快捷方式的启动路径即可。5.2 迁移到一半连接被断开界面还显示任务在跑现象整个迁移界面看起来还在执行但日志已经很久没有新增行数进度条不动。原因源库或目标库的连接空闲超时。JDBC连接一段时间内没有数据读写数据库端会主动断开连接。工具如果没有重连机制任务就卡在“假运行”状态直到超时才会报错。解决在源库和目标库都检查连接超时参数可以把空闲连接的最长空闲时间调大或者让工具每批次之间保持活跃。另一个更实际的办法是不要用默认的自动提交模式而是按批次提交每一批提交都会保持连接活跃状态降低被数据库端断开的概率。5.3 迁移后中文全部变成问号现象数据行数和类型都对但目标库里的中文和符号类内容全部显示为问号。原因字符集链路没有打通。最常见的是连接参数里没有指定UTF-8Windows中文版的默认编码导致工具用GBK去写目标库还有一种是虚谷数据库本身的字符集设置是GBK工具写入UTF-8数据时发生转换丢失。解决第一步确认目标库和表的字符集第二步在迁移工具连接配置里显式指定编码。迁移前用带特殊字符的测试数据跑一遍比如中文、日文假名、emoji如果emoji能正常写入说明字符集链路是通的如果只有中文正常说明基础字符集可用但完整字符集不一定支持。这一步最花时间但也是排查乱码最快的方式。5.4 Oracle的NUMBER列被截断为整数现象源库某一列存的是带小数位的数值迁移到虚谷数据库后所有小数位都变成了0数据看起来没少但值变了。原因工具的类型映射里不带精度描述的NUMBER被默认映射成了BIGINT在写入时做了取整。解决这属于类型映射人工干预不到位的典型案例。处理方式是先在源库查一下该列实际存的内容确定最大小数位数然后在目标库把表结构改成DECIMAL并重新迁移该表。这样处理虽然要改表但比起在数据写入后再做UPDATE批量修复效率高得多。5.5 Windows休眠导致迁移中断重跑时报主键冲突现象迁移进行到一半Windows进入睡眠状态任务中断。重新运行同一迁移任务日志里出现大量主键冲突。原因任务中断时已经提交了一部分数据到目标库。续传功能如果定位断点的逻辑不完善会从头再读一次之前已经写入的数据就成为冲突行。解决不要直接在原任务上重跑。我的处理方式是先把目标库中该任务对应的表数据清空再从头迁移一次。如果表里数据量很大清空重来的成本反而比逐条处理冲突低。为了避免下次中断迁移前把Windows电源设置改为“从不睡眠”并使用稳定的供电环境这一步对长时间迁移非常重要。6. 迁移收尾别只信“全部成功”用三套反向校验把迁移质量钉死最后一章写一个我坚持了很久的习惯迁移完成后不信任工具界面上“任务成功”四个字用三套独立校验交叉确认。第一套验证是总量校验就是前面说的COUNT(*)对比适合确认行数不丢。第二套验证是字段级校验对随机抽取的主键列比较源库和目标库上这一行的关键字段值。第三套验证是对象校验对比表、索引、序列、存储过程的数量和定义。我一般会在迁移后写一个简单的对比脚本利用数据库自带的元数据视图做表清单比对。如果源库是Oracle目标库是虚谷数据库查各自的信息视图导出清单再在脚本里做差集效率比肉眼核对高得多。这一步做一次后面线上出问题的概率能明显下降。字段级抽样校验有一条经验不要只抽前几行因为前几行往往都是结构简单、类型规整的数据。用ORDER BY随机排序或者按主键的模数分成多个区间每个区间抽一条覆盖的数据形态更全面。中文、NULL值、超大字段、边界日期就藏在这些随机样本里。索引对比则要关注迁移后索引是否真的生效。有的工具迁移索引时只是把索引定义语句原样搬过来如果目标库不兼容其中的函数索引或表达式索引创建时可能静默跳过但不会中断任务。我遇到过一次源库两个执行很快的查询迁移后变慢排查发现是函数索引丢了重建后才恢复。所以上线前的性能压力测试不是可选项是必选项。另一个收尾技巧是保留迁移工具的完整日志和配置文件连同迁移时间、源库版本、目标库版本一起记录到项目交接文档里。后面如果还有增量迁移或第二次全量迁移直接复用这套配置会比重新填一遍配置少踩一半的坑。最后说一下自己的教训。我曾经在时间压力下跳过字段级抽样直接信了总量校验结果一张大表行数完全一致但有两列发生了错位源库的A列内容跑到了目标库的B列里虽然业务上没立刻炸但后面排查了很久。从那以后我再也没有省过这一层校验。希望这篇笔记能帮你避开我走过的弯路用最少的时间把迁移这件事做扎实。本文还有配套的精品资源点击获取