简介GBaseMigrationToolkit_8.5.23.3_winx86_64.zip是南大通用GBase数据库的官方配套迁移工具包面向Windows 64位环境下的DBA、数据工程师及信创迁移项目人员用于将Oracle、MySQL、SQL Server等主流数据库的数据迁移至GBase或在不同GBase实例间完成同步与转换。压缩包共358个文件约117.91MB以135个jar与66个dll构成核心运行库辅以22个exe可执行程序、33个properties配置项及xml、ini等参数文件另含字体、图标与证书资源整体结构完整、依赖齐全。资源已有253人学习下载具备一定参考热度。借助该工具包读者可实践全量与增量迁移、实时数据同步、字段格式转换及迁移日志排错等关键环节结合MigrationCmd.bat等入口快速搭建迁移环境理解源库与目标库的兼容性处理思路为金融、电信等场景下的数据库平滑替换提供可复用的操作依据。1. 从一次迁移翻车说起GBaseMigrationToolkit 8.5.23.3 到底装的是什么第一次接触 GBaseMigrationToolkit 是在一个数据迁移项目里当时客户要求把一批异构数据库的表结构和数据整体搬到 GBase 8a 集群上。我心想不就是个迁移工具嘛解压、双击、连库、开跑能有多难。结果解压完打开目录一看一堆 jar 包、配置文件、脚本混在一起双击 exe 直接闪退日志里只留下一行JAVA_HOME not found。折腾了大半天才搞明白这个工具不是绿色软件它对 JDK 版本、字符集、驱动包位置都有硬性要求装不对连界面都出不来。GBaseMigrationToolkit 8.5.23.3 是南大通用推出的数据库迁移工具主要用来把 Oracle、MySQL、SQL Server 等异构库的对象和数据迁移到 GBase 8a/8s 上。它本身是个 Java 桌面应用Windows 下以 zip 包分发解压即用但依赖外部 JDK。很多人卡在第一步——环境没配对工具根本起不来。这篇笔记就把我从零装通这套工具的过程完整记下来包括 JDK 怎么选、环境变量怎么写、驱动包放哪里、连不上库怎么排查。如果你也正准备做 GBase 迁移照着走一遍能少踩不少坑。2. 安装前把环境列清楚JDK、系统版本和依赖一个都不能少2.1 JDK 版本选择为什么 8 和 11 的坑完全不一样GBaseMigrationToolkit 8.5.23.3 官方推荐的是 JDK 1.8但实测在 JDK 11 上也能跑起来只是有几个细节要注意。我一开始图省事直接用了机器上已有的 JDK 17结果启动脚本报了一堆模块化相关的错java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter这种原因是 JDK 11 之后 JAXB 模块被移出了标准库而工具内部还在用。换成 JDK 8 之后一切正常。所以我的建议很明确优先用 JDK 8u202 或之后的 8u 版本不要用 JDK 9 以上的版本。如果你机器上已经有其他 JDK不要改全局JAVA_HOME而是单独给这个工具配一个启动脚本在里面临时指定JAVA_HOME。这样不会影响你机器上其他项目的运行环境。具体操作是找到工具目录下的start.bat或类似启动脚本在开头加上echo off set JAVA_HOMED:\tools\jdk1.8.0_202 set PATH%JAVA_HOME%\bin;%PATH% java -version第一行关闭命令回显第二行把JAVA_HOME指向你专门为这个工具准备的 JDK 8 目录第三行把 JDK 的 bin 目录塞进PATH最前面保证调用的 java 命令是这个版本。第四行打印版本号方便你确认没指错。改完保存双击运行如果能看到java version 1.8.0_202就说明环境对了。提示如果你不确定机器上有几个 JDK在 cmd 里执行where java能看到所有 java.exe 的路径按顺序排在前面的就是当前生效的。2.2 系统版本和字符集Windows 10 以下别硬上工具本身是 winx86_64 架构意味着它只能在 64 位 Windows 上跑。我实测过 Windows 7 SP1 能启动但界面渲染有问题部分按钮点不动Windows 10 和 Windows 11 都正常。如果你还在用 Windows 8 或更早的版本建议先升级系统否则后面连库的时候各种玄学问题会让你怀疑人生。字符集这块容易被忽略。GBase 8a 集群默认用的是 UTF-8而 Windows 中文版默认是 GBK。如果你在迁移过程中看到中文乱码大概率是字符集没对齐。解决办法是在启动脚本里加一行set JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8这行设置 JVM 的文件编码为 UTF-8让工具读写文件时统一用 UTF-8 处理。加完之后重启工具之前乱码的表名和字段名应该就能正常显示了。2.3 依赖检查清单装之前先过一遍在正式解压之前我一般会先过一遍下面这个清单确认环境没有硬伤检查项要求检查命令操作系统Windows 10/11 64位winverJDK 版本1.8.0_202 及以上java -version磁盘空间至少 2GB 可用资源管理器查看内存建议 8GB 以上任务管理器查看目标库连通性能 telnet 通 GBase 端口telnet ip 5258源库驱动对应数据库的 JDBC 驱动检查 lib 目录磁盘空间这块多说一句工具本身不大但迁移过程中会在本地生成临时文件和日志如果迁移的表多、数据量大临时目录可能吃掉好几个 G。我一般会把工具解压到非系统盘比如D:\gbase_migration\避免 C 盘被撑爆。3. 解压与首次启动从 zip 到能看见界面3.1 解压路径的讲究为什么不能放在中文目录下拿到GBaseMigrationToolkit_8.5.23.3_winx86_64.zip之后第一步是解压。这里有个血泪经验解压路径不要带中文、不要带空格、不要带特殊符号。我试过放在D:\迁移工具\下面启动脚本直接报Error: Could not find or load main class因为脚本里的 classpath 拼接遇到中文路径就断了。后来换成D:\gbase_migration\就没事了。解压完之后目录结构大概是这样GBaseMigrationToolkit_8.5.23.3/ ├── bin/ # 启动脚本 ├── conf/ # 配置文件 ├── lib/ # 依赖 jar 包 ├── drivers/ # 数据库驱动存放目录 ├── logs/ # 日志输出 └── README.txt # 说明文件bin目录下一般有start.bat和start.shWindows 下用 bat。drivers目录是空的或者只有 GBase 自己的驱动其他数据库的驱动需要你自己放进去。3.2 启动脚本改造把 JAVA_HOME 和编码都写死前面说了要改启动脚本这里给一个完整的改造示例。用文本编辑器打开bin/start.bat在文件最前面插入以下内容echo off REM 指定专用 JDK 8 路径 set JAVA_HOMED:\tools\jdk1.8.0_202 set PATH%JAVA_HOME%\bin;%PATH% REM 强制 UTF-8 编码避免中文乱码 set JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8 REM 打印当前 Java 版本方便排查 java -version REM 调用原始启动逻辑 call %~dp0\startup.bat %*%~dp0表示当前脚本所在目录%*把外部传入的参数原样透传。这样改的好处是不管你在哪个目录下双击运行脚本都能找到自己的位置不会因为工作目录不对而找不到 jar 包。改完之后双击start.bat如果一切正常你会看到一个 Java 桌面窗口弹出来标题栏写着 GBaseMigrationToolkit 的版本号。如果窗口一闪而过说明还有问题去logs目录下找最新的日志文件里面会有具体的报错信息。3.3 驱动包放置源库和目标库的 JDBC 驱动怎么放工具启动起来只是第一步要连数据库还得有对应的 JDBC 驱动。GBase 8a 的驱动一般在lib目录下自带但如果你要迁移的是 Oracle 或 MySQL就需要手动把驱动 jar 包放到drivers目录下。我一般会准备这几个驱动gbase-connector-java-8.3.81.53-build55.5.7-bin.jarGBase 8a 驱动ojdbc8.jarOracle 驱动注意版本要和源库匹配mysql-connector-java-8.0.28.jarMySQL 驱动放进去之后重启工具在新建连接的界面里就能看到对应的数据库类型选项了。如果放进去还是看不到检查一下 jar 包有没有损坏或者是不是放错了目录。有些版本的工具有两层 drivers 目录一层在根目录下一层在 conf 下面我一般两处都放一份省得来回试。注意Oracle 驱动版本要和源库版本匹配。源库是 Oracle 11g 就用 ojdbc6 或 ojdbc8源库是 Oracle 19c 就用 ojdbc8 或 ojdbc10。版本不匹配会出现ORA-28040: No matching authentication protocol这种经典报错。4. 连接配置与迁移任务创建参数怎么填、任务怎么跑4.1 源库连接配置URL 写法和常见参数工具界面起来之后第一步是配源库连接。以 Oracle 为例连接配置界面一般要填这几项参数示例值说明主机名192.168.1.100源库 IP 地址端口1521Oracle 默认端口SID/服务名ORCL根据源库实际配置填用户名mig_user迁移专用账号密码********对应密码URLjdbc:oracle:thin:192.168.1.100:1521:ORCL自动生成或手动填URL 这块有个细节Oracle 的 URL 有两种写法一种是 SID 模式jdbc:oracle:thin:host:port:SID一种是服务名模式jdbc:oracle:thin://host:port/service_name。填错了会报ORA-12505: TNS:listener does not currently know of SID given in connect descriptor。我一般会先在 SQL 客户端里确认源库用的是哪种模式再照着填。MySQL 的 URL 相对简单jdbc:mysql://192.168.1.101:3306/source_db?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/Shanghai。注意serverTimezone参数不填的话可能会报时区错误尤其是 MySQL 8.0 以上版本。4.2 目标库连接配置GBase 8a 的连接要点目标库是 GBase 8a 集群连接配置和源库类似但有几个地方要注意。GBase 8a 的默认端口是 5258连接 URL 格式是jdbc:gbase://192.168.1.200:5258/target_db。用户名一般用gbase或者你创建的业务账号。如果连接时报Access denied for user先确认账号密码对不对再确认这个账号有没有远程访问权限。GBase 8a 默认只允许本地连接需要在集群端执行授权-- 在 GBase 8a 集群端执行授权远程连接 GRANT ALL PRIVILEGES ON *.* TO mig_user% IDENTIFIED BY password; FLUSH PRIVILEGES;第一行给mig_user账号授予所有库表的全部权限并允许从任意 IP 连接。第二行刷新权限表让授权立即生效。生产环境建议把%换成具体的 IP 段不要开放给所有地址。4.3 迁移任务创建选表、映射、跑任务连接都配通之后就可以创建迁移任务了。一般流程是选源库连接 → 选目标库连接 → 选要迁移的库表 → 配置字段映射 → 执行迁移。字段映射这块工具一般会自动匹配同名字段但类型映射需要你确认。比如 Oracle 的NUMBER类型映射到 GBase 8a 的DECIMAL还是INTVARCHAR2映射到VARCHAR还是TEXT这些都会影响迁移结果。我一般会先跑一个小表做验证确认类型映射没问题再跑全量。迁移模式有两种全量迁移和增量迁移。全量就是一次性把所有数据搬过去增量是只搬变化的数据。第一次迁移肯定用全量后续同步可以用增量。工具界面上一般有选项让你选选完之后点执行下面会有进度条和日志输出。提示迁移大表的时候建议在业务低峰期跑因为全量迁移会占用源库和目标库不少资源。我一般会先把大表拆成几个小批次分批迁移避免一次性把源库拖垮。5. 避坑与排查那些让我加班到凌晨的报错5.1 启动闪退JAVA_HOME 指向了错误的 JDK现象双击start.bat之后窗口一闪而过什么都没留下或者日志里只有一行JAVA_HOME not found。原因脚本里指定的JAVA_HOME路径不对或者指向了一个不存在的目录。还有一种情况是路径里有空格比如C:\Program Files\Java\jdk1.8.0_202脚本没加引号导致解析失败。解决在 cmd 里手动执行echo %JAVA_HOME%确认路径然后dir %JAVA_HOME%\bin\java.exe确认 java.exe 存在。如果路径有空格在脚本里用引号包起来set JAVA_HOMEC:\Program Files\Java\jdk1.8.0_202。改完再试。5.2 连接源库报 ORA-28040驱动版本和源库不匹配现象配好 Oracle 连接之后点测试报ORA-28040: No matching authentication protocol。原因Oracle 驱动版本太老不支持源库的认证协议。比如源库是 Oracle 19c你用的是 ojdbc6就会报这个错。解决换用 ojdbc8 或更高版本的驱动。去 Oracle 官网下载对应版本的 jar 包放到drivers目录下重启工具再试。如果换了驱动还报错检查一下源库的sqlnet.ora里有没有限制认证协议。5.3 迁移过程中中文乱码字符集没对齐现象迁移完成后目标库里的中文数据显示成???或者乱码。原因源库、工具、目标库三方的字符集不一致。常见的是源库 UTF-8工具用 GBK 读写进目标库就乱了。解决在启动脚本里加-Dfile.encodingUTF-8确保工具用 UTF-8 处理数据。同时检查源库和目标库的字符集设置GBase 8a 建库时指定CHARACTER SET utf8。如果已经迁移完了才发现乱码只能清空目标表重新迁。5.4 迁移速度慢批量提交参数没调现象迁移大表时速度特别慢几个小时才跑了几万条。原因工具默认的批量提交条数太小每条数据都单独提交网络往返次数太多。解决在迁移任务的配置里找batchSize或commitSize参数调大到 1000 或 5000。具体调多少要看网络延迟和目标库的写入能力我一般从 1000 开始试如果目标库没压力就继续往上加。另外可以开多个并发线程但不要超过目标库的承受能力。5.5 日志文件太大日志级别没调现象跑了一晚上迁移第二天发现logs目录下有个几十 G 的日志文件磁盘直接满了。原因工具默认日志级别是 DEBUG每条数据的读写都记日志。解决找到conf目录下的日志配置文件把日志级别从 DEBUG 改成 INFO 或 WARN。改完之后重启工具日志量会大幅下降。如果已经产生了大日志文件直接删掉或者归档别让它继续占着磁盘。6. 装完怎么验证跑通从一条数据到全量迁移工具装好、连接配通之后别急着跑全量迁移。我一般会先做一轮最小验证确认整条链路没问题再上量。具体分三步走。第一步建一张测试表。在源库建一张只有几行数据的小表字段类型覆盖你后面要迁移的主要类型比如NUMBER、VARCHAR2、DATE。然后在目标库建对应的表字符集用 UTF-8。第二步跑单表迁移。在工具里只选这张测试表执行迁移。跑完之后去目标库SELECT COUNT(*)对比行数再抽查几行数据看字段值对不对。重点看日期类型和数字类型有没有精度丢失中文有没有乱码。第三步验证增量同步。在源库往测试表里插几条新数据然后跑增量迁移看目标库能不能同步过去。增量同步依赖时间戳或者增量字段配置的时候要确认这个字段在源库里有索引否则增量查询会全表扫描慢得让你怀疑人生。这三步都过了再开始跑全量。全量迁移的时候我一般会开着日志监控每隔一段时间看一眼进度和报错。如果中途报错先暂停任务排查完再继续不要硬跑到底。从那以后我每次装完 GBaseMigrationToolkit都会先用一张小表跑通全流程确认环境、驱动、字符集、批量参数都没问题再动真格的数据。这个习惯帮我省了好几次通宵排查的时间。希望帮到你。本文还有配套的精品资源点击获取 GBaseMigrationToolkit 8.5.23.3 安装配置与迁移避坑实战指南
简介GBaseMigrationToolkit_8.5.23.3_winx86_64.zip是南大通用GBase数据库的官方配套迁移工具包面向Windows 64位环境下的DBA、数据工程师及信创迁移项目人员用于将Oracle、MySQL、SQL Server等主流数据库的数据迁移至GBase或在不同GBase实例间完成同步与转换。压缩包共358个文件约117.91MB以135个jar与66个dll构成核心运行库辅以22个exe可执行程序、33个properties配置项及xml、ini等参数文件另含字体、图标与证书资源整体结构完整、依赖齐全。资源已有253人学习下载具备一定参考热度。借助该工具包读者可实践全量与增量迁移、实时数据同步、字段格式转换及迁移日志排错等关键环节结合MigrationCmd.bat等入口快速搭建迁移环境理解源库与目标库的兼容性处理思路为金融、电信等场景下的数据库平滑替换提供可复用的操作依据。1. 从一次迁移翻车说起GBaseMigrationToolkit 8.5.23.3 到底装的是什么第一次接触 GBaseMigrationToolkit 是在一个数据迁移项目里当时客户要求把一批异构数据库的表结构和数据整体搬到 GBase 8a 集群上。我心想不就是个迁移工具嘛解压、双击、连库、开跑能有多难。结果解压完打开目录一看一堆 jar 包、配置文件、脚本混在一起双击 exe 直接闪退日志里只留下一行JAVA_HOME not found。折腾了大半天才搞明白这个工具不是绿色软件它对 JDK 版本、字符集、驱动包位置都有硬性要求装不对连界面都出不来。GBaseMigrationToolkit 8.5.23.3 是南大通用推出的数据库迁移工具主要用来把 Oracle、MySQL、SQL Server 等异构库的对象和数据迁移到 GBase 8a/8s 上。它本身是个 Java 桌面应用Windows 下以 zip 包分发解压即用但依赖外部 JDK。很多人卡在第一步——环境没配对工具根本起不来。这篇笔记就把我从零装通这套工具的过程完整记下来包括 JDK 怎么选、环境变量怎么写、驱动包放哪里、连不上库怎么排查。如果你也正准备做 GBase 迁移照着走一遍能少踩不少坑。2. 安装前把环境列清楚JDK、系统版本和依赖一个都不能少2.1 JDK 版本选择为什么 8 和 11 的坑完全不一样GBaseMigrationToolkit 8.5.23.3 官方推荐的是 JDK 1.8但实测在 JDK 11 上也能跑起来只是有几个细节要注意。我一开始图省事直接用了机器上已有的 JDK 17结果启动脚本报了一堆模块化相关的错java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter这种原因是 JDK 11 之后 JAXB 模块被移出了标准库而工具内部还在用。换成 JDK 8 之后一切正常。所以我的建议很明确优先用 JDK 8u202 或之后的 8u 版本不要用 JDK 9 以上的版本。如果你机器上已经有其他 JDK不要改全局JAVA_HOME而是单独给这个工具配一个启动脚本在里面临时指定JAVA_HOME。这样不会影响你机器上其他项目的运行环境。具体操作是找到工具目录下的start.bat或类似启动脚本在开头加上echo off set JAVA_HOMED:\tools\jdk1.8.0_202 set PATH%JAVA_HOME%\bin;%PATH% java -version第一行关闭命令回显第二行把JAVA_HOME指向你专门为这个工具准备的 JDK 8 目录第三行把 JDK 的 bin 目录塞进PATH最前面保证调用的 java 命令是这个版本。第四行打印版本号方便你确认没指错。改完保存双击运行如果能看到java version 1.8.0_202就说明环境对了。提示如果你不确定机器上有几个 JDK在 cmd 里执行where java能看到所有 java.exe 的路径按顺序排在前面的就是当前生效的。2.2 系统版本和字符集Windows 10 以下别硬上工具本身是 winx86_64 架构意味着它只能在 64 位 Windows 上跑。我实测过 Windows 7 SP1 能启动但界面渲染有问题部分按钮点不动Windows 10 和 Windows 11 都正常。如果你还在用 Windows 8 或更早的版本建议先升级系统否则后面连库的时候各种玄学问题会让你怀疑人生。字符集这块容易被忽略。GBase 8a 集群默认用的是 UTF-8而 Windows 中文版默认是 GBK。如果你在迁移过程中看到中文乱码大概率是字符集没对齐。解决办法是在启动脚本里加一行set JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8这行设置 JVM 的文件编码为 UTF-8让工具读写文件时统一用 UTF-8 处理。加完之后重启工具之前乱码的表名和字段名应该就能正常显示了。2.3 依赖检查清单装之前先过一遍在正式解压之前我一般会先过一遍下面这个清单确认环境没有硬伤检查项要求检查命令操作系统Windows 10/11 64位winverJDK 版本1.8.0_202 及以上java -version磁盘空间至少 2GB 可用资源管理器查看内存建议 8GB 以上任务管理器查看目标库连通性能 telnet 通 GBase 端口telnet ip 5258源库驱动对应数据库的 JDBC 驱动检查 lib 目录磁盘空间这块多说一句工具本身不大但迁移过程中会在本地生成临时文件和日志如果迁移的表多、数据量大临时目录可能吃掉好几个 G。我一般会把工具解压到非系统盘比如D:\gbase_migration\避免 C 盘被撑爆。3. 解压与首次启动从 zip 到能看见界面3.1 解压路径的讲究为什么不能放在中文目录下拿到GBaseMigrationToolkit_8.5.23.3_winx86_64.zip之后第一步是解压。这里有个血泪经验解压路径不要带中文、不要带空格、不要带特殊符号。我试过放在D:\迁移工具\下面启动脚本直接报Error: Could not find or load main class因为脚本里的 classpath 拼接遇到中文路径就断了。后来换成D:\gbase_migration\就没事了。解压完之后目录结构大概是这样GBaseMigrationToolkit_8.5.23.3/ ├── bin/ # 启动脚本 ├── conf/ # 配置文件 ├── lib/ # 依赖 jar 包 ├── drivers/ # 数据库驱动存放目录 ├── logs/ # 日志输出 └── README.txt # 说明文件bin目录下一般有start.bat和start.shWindows 下用 bat。drivers目录是空的或者只有 GBase 自己的驱动其他数据库的驱动需要你自己放进去。3.2 启动脚本改造把 JAVA_HOME 和编码都写死前面说了要改启动脚本这里给一个完整的改造示例。用文本编辑器打开bin/start.bat在文件最前面插入以下内容echo off REM 指定专用 JDK 8 路径 set JAVA_HOMED:\tools\jdk1.8.0_202 set PATH%JAVA_HOME%\bin;%PATH% REM 强制 UTF-8 编码避免中文乱码 set JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8 REM 打印当前 Java 版本方便排查 java -version REM 调用原始启动逻辑 call %~dp0\startup.bat %*%~dp0表示当前脚本所在目录%*把外部传入的参数原样透传。这样改的好处是不管你在哪个目录下双击运行脚本都能找到自己的位置不会因为工作目录不对而找不到 jar 包。改完之后双击start.bat如果一切正常你会看到一个 Java 桌面窗口弹出来标题栏写着 GBaseMigrationToolkit 的版本号。如果窗口一闪而过说明还有问题去logs目录下找最新的日志文件里面会有具体的报错信息。3.3 驱动包放置源库和目标库的 JDBC 驱动怎么放工具启动起来只是第一步要连数据库还得有对应的 JDBC 驱动。GBase 8a 的驱动一般在lib目录下自带但如果你要迁移的是 Oracle 或 MySQL就需要手动把驱动 jar 包放到drivers目录下。我一般会准备这几个驱动gbase-connector-java-8.3.81.53-build55.5.7-bin.jarGBase 8a 驱动ojdbc8.jarOracle 驱动注意版本要和源库匹配mysql-connector-java-8.0.28.jarMySQL 驱动放进去之后重启工具在新建连接的界面里就能看到对应的数据库类型选项了。如果放进去还是看不到检查一下 jar 包有没有损坏或者是不是放错了目录。有些版本的工具有两层 drivers 目录一层在根目录下一层在 conf 下面我一般两处都放一份省得来回试。注意Oracle 驱动版本要和源库版本匹配。源库是 Oracle 11g 就用 ojdbc6 或 ojdbc8源库是 Oracle 19c 就用 ojdbc8 或 ojdbc10。版本不匹配会出现ORA-28040: No matching authentication protocol这种经典报错。4. 连接配置与迁移任务创建参数怎么填、任务怎么跑4.1 源库连接配置URL 写法和常见参数工具界面起来之后第一步是配源库连接。以 Oracle 为例连接配置界面一般要填这几项参数示例值说明主机名192.168.1.100源库 IP 地址端口1521Oracle 默认端口SID/服务名ORCL根据源库实际配置填用户名mig_user迁移专用账号密码********对应密码URLjdbc:oracle:thin:192.168.1.100:1521:ORCL自动生成或手动填URL 这块有个细节Oracle 的 URL 有两种写法一种是 SID 模式jdbc:oracle:thin:host:port:SID一种是服务名模式jdbc:oracle:thin://host:port/service_name。填错了会报ORA-12505: TNS:listener does not currently know of SID given in connect descriptor。我一般会先在 SQL 客户端里确认源库用的是哪种模式再照着填。MySQL 的 URL 相对简单jdbc:mysql://192.168.1.101:3306/source_db?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/Shanghai。注意serverTimezone参数不填的话可能会报时区错误尤其是 MySQL 8.0 以上版本。4.2 目标库连接配置GBase 8a 的连接要点目标库是 GBase 8a 集群连接配置和源库类似但有几个地方要注意。GBase 8a 的默认端口是 5258连接 URL 格式是jdbc:gbase://192.168.1.200:5258/target_db。用户名一般用gbase或者你创建的业务账号。如果连接时报Access denied for user先确认账号密码对不对再确认这个账号有没有远程访问权限。GBase 8a 默认只允许本地连接需要在集群端执行授权-- 在 GBase 8a 集群端执行授权远程连接 GRANT ALL PRIVILEGES ON *.* TO mig_user% IDENTIFIED BY password; FLUSH PRIVILEGES;第一行给mig_user账号授予所有库表的全部权限并允许从任意 IP 连接。第二行刷新权限表让授权立即生效。生产环境建议把%换成具体的 IP 段不要开放给所有地址。4.3 迁移任务创建选表、映射、跑任务连接都配通之后就可以创建迁移任务了。一般流程是选源库连接 → 选目标库连接 → 选要迁移的库表 → 配置字段映射 → 执行迁移。字段映射这块工具一般会自动匹配同名字段但类型映射需要你确认。比如 Oracle 的NUMBER类型映射到 GBase 8a 的DECIMAL还是INTVARCHAR2映射到VARCHAR还是TEXT这些都会影响迁移结果。我一般会先跑一个小表做验证确认类型映射没问题再跑全量。迁移模式有两种全量迁移和增量迁移。全量就是一次性把所有数据搬过去增量是只搬变化的数据。第一次迁移肯定用全量后续同步可以用增量。工具界面上一般有选项让你选选完之后点执行下面会有进度条和日志输出。提示迁移大表的时候建议在业务低峰期跑因为全量迁移会占用源库和目标库不少资源。我一般会先把大表拆成几个小批次分批迁移避免一次性把源库拖垮。5. 避坑与排查那些让我加班到凌晨的报错5.1 启动闪退JAVA_HOME 指向了错误的 JDK现象双击start.bat之后窗口一闪而过什么都没留下或者日志里只有一行JAVA_HOME not found。原因脚本里指定的JAVA_HOME路径不对或者指向了一个不存在的目录。还有一种情况是路径里有空格比如C:\Program Files\Java\jdk1.8.0_202脚本没加引号导致解析失败。解决在 cmd 里手动执行echo %JAVA_HOME%确认路径然后dir %JAVA_HOME%\bin\java.exe确认 java.exe 存在。如果路径有空格在脚本里用引号包起来set JAVA_HOMEC:\Program Files\Java\jdk1.8.0_202。改完再试。5.2 连接源库报 ORA-28040驱动版本和源库不匹配现象配好 Oracle 连接之后点测试报ORA-28040: No matching authentication protocol。原因Oracle 驱动版本太老不支持源库的认证协议。比如源库是 Oracle 19c你用的是 ojdbc6就会报这个错。解决换用 ojdbc8 或更高版本的驱动。去 Oracle 官网下载对应版本的 jar 包放到drivers目录下重启工具再试。如果换了驱动还报错检查一下源库的sqlnet.ora里有没有限制认证协议。5.3 迁移过程中中文乱码字符集没对齐现象迁移完成后目标库里的中文数据显示成???或者乱码。原因源库、工具、目标库三方的字符集不一致。常见的是源库 UTF-8工具用 GBK 读写进目标库就乱了。解决在启动脚本里加-Dfile.encodingUTF-8确保工具用 UTF-8 处理数据。同时检查源库和目标库的字符集设置GBase 8a 建库时指定CHARACTER SET utf8。如果已经迁移完了才发现乱码只能清空目标表重新迁。5.4 迁移速度慢批量提交参数没调现象迁移大表时速度特别慢几个小时才跑了几万条。原因工具默认的批量提交条数太小每条数据都单独提交网络往返次数太多。解决在迁移任务的配置里找batchSize或commitSize参数调大到 1000 或 5000。具体调多少要看网络延迟和目标库的写入能力我一般从 1000 开始试如果目标库没压力就继续往上加。另外可以开多个并发线程但不要超过目标库的承受能力。5.5 日志文件太大日志级别没调现象跑了一晚上迁移第二天发现logs目录下有个几十 G 的日志文件磁盘直接满了。原因工具默认日志级别是 DEBUG每条数据的读写都记日志。解决找到conf目录下的日志配置文件把日志级别从 DEBUG 改成 INFO 或 WARN。改完之后重启工具日志量会大幅下降。如果已经产生了大日志文件直接删掉或者归档别让它继续占着磁盘。6. 装完怎么验证跑通从一条数据到全量迁移工具装好、连接配通之后别急着跑全量迁移。我一般会先做一轮最小验证确认整条链路没问题再上量。具体分三步走。第一步建一张测试表。在源库建一张只有几行数据的小表字段类型覆盖你后面要迁移的主要类型比如NUMBER、VARCHAR2、DATE。然后在目标库建对应的表字符集用 UTF-8。第二步跑单表迁移。在工具里只选这张测试表执行迁移。跑完之后去目标库SELECT COUNT(*)对比行数再抽查几行数据看字段值对不对。重点看日期类型和数字类型有没有精度丢失中文有没有乱码。第三步验证增量同步。在源库往测试表里插几条新数据然后跑增量迁移看目标库能不能同步过去。增量同步依赖时间戳或者增量字段配置的时候要确认这个字段在源库里有索引否则增量查询会全表扫描慢得让你怀疑人生。这三步都过了再开始跑全量。全量迁移的时候我一般会开着日志监控每隔一段时间看一眼进度和报错。如果中途报错先暂停任务排查完再继续不要硬跑到底。从那以后我每次装完 GBaseMigrationToolkit都会先用一张小表跑通全流程确认环境、驱动、字符集、批量参数都没问题再动真格的数据。这个习惯帮我省了好几次通宵排查的时间。希望帮到你。本文还有配套的精品资源点击获取