虚谷数据库迁移工具Windows 64位实战：类型映射、字符集与避坑指南

简介：虚谷数据库迁移工具（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 数据类型映射：先对照表，再决定哪几列要人工干预

工具内置的映射表解决的是常见类型，我整理了一份实践中比较常用的对应关系。不同版本的虚谷数据库映射细节可能略有出入，但大方向是一致的：

NUMBER到整型这行最容易出问题。Oracle的NUMBER不带精度时，理论上是任意精度数值，工具映射到虚谷数据库是哪一种类型，直接决定了数据会不会失真。我的经验是，迁移前先在源库跑一些统计，找出所有NUMBER列里小数位不为零的样本，如果数量大，就要把对应列改成DECIMAL，不能简单按“NUMBER映射为BIGINT”处理。

VARCHAR2到VARCHAR看似直搬，但有一个长度陷阱。Oracle的VARCHAR2长度单位是字节还是字符，取决于数据库参数；虚谷数据库的VARCHAR长度单位在不同版本里也有差异。如果两边单位不一致，一个包含中文的字符串很容易在迁移后报“值超出长度”。稳妥的办法是把长度按字符数放大一点，比如源库VARCHAR2(100)字符，目标库建成VARCHAR(300)，代价是存储空间多占一些，但换取的是不用反复回来改表。

提示：BLOB/CLOB这类大字段在迁移时最耗时，而且容易因为网络原因中途断开。建议单独为大字段表设置更长的超时时间，不要和普通表混在同一个任务里跑。

3.2 字符集引发的乱码问题：Windows环境下的中文数据重灾区

迁移工具本身在Windows上运行，操作系统默认字符集、源库字符集、目标库字符集这三者只要有一个不匹配，中文数据就会出现乱码。源头多半不在工具，而在源库导出前的字符集设置。Oracle那边如果是AL32UTF8，MySQL那边如果是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节的方式填，目标连接填虚谷数据库的连接信息。两边的连接配置里都要确认端口可达，源库端口不通连不上，目标库端口不通则迁移过程中会写失败。

配置界面一般会有“最大连接数”和“批处理大小”两个参数，这两个参数直接影响吞吐。我的经验取值如下：

这两个参数不是越大越好。最大连接数调大，并发读写是真的会快，但源库如果是生产库，连接数过高会挤占业务连接池，引发生产告警。批处理大小也不是越大越好，过大会占用更多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-8，Windows中文版的默认编码导致工具用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列里，虽然业务上没立刻炸，但后面排查了很久。从那以后，我再也没有省过这一层校验。希望这篇笔记能帮你避开我走过的弯路，用最少的时间把迁移这件事做扎实。

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