简介瀚高数据库抽取工具是一款面向数据库管理员与数据迁移工程师的实用软件聚焦Oracle到瀚高HGDB数据库的数据抽取、转换与同步场景适用于数据库系统变更、升级或主备部署时保障数据一致性与完整性。工具针对Oracle特性做了优化可处理PL/SQL存储过程、触发器、索引等复杂对象并支持实时或定期同步运行依赖JRE7环境对Oracle 10g Release 3版本有较好兼容性。压缩包共660个文件约55.29MB以dll动态库、jar包、properties配置、exe可执行程序及大量时区资源文件为主另含字体、图标与说明文档目录结构完整解压后可直接部署使用。目前已有778人学习下载。借助该工具读者可掌握ETL迁移流程、跨库数据类型差异处理与同步机制并参考其安全恢复与易用性设计降低迁移风险与人为出错概率。1. 从 Oracle 迁到瀚高先别急着点“下一步”上周又帮一个团队收拾迁移现场源库是 Oracle目标库是瀚高数据库HGDB中间用瀚高数据库抽取工具做结构与数据搬运。工具装上了连接也通了结果抽取到一半卡在字符集和字段类型上日志里只有一句含糊的失败提示几个人围着屏幕干瞪眼。这类场景太常见了——抽取工具本身不复杂难的是 Oracle 和 HGDB 两端的版本、驱动、字符集、权限得先对齐。这篇笔记按我实际装过的一套流程写装什么版本、驱动怎么放、连接参数怎么填、抽取出错怎么定位。适合正在做 Oracle 到 HGDB 迁移、第一次接触这套抽取工具的开发者也适合想少走弯路的熟手。2. 装前把环境列清Oracle 与 HGDB 两端的版本账抽取工具是夹在两端中间的搬运工它自己不存数据但两端的任何一处不匹配都会在它身上报错。所以装工具之前先把源端 Oracle、目标端 HGDB、运行工具的机器这三块环境盘清楚比装完再回头查要省事得多。2.1 三块环境各自要确认什么源端 Oracle 这边我一般先确认三件事数据库大版本11g、12c、19c 差异不小、字符集NLS_CHARACTERSET、以及给抽取账号的权限。字符集这条最容易被忽略源库是ZHS16GBK、目标库是UTF8的话中文数据抽取过去就可能变问号而且往往不是全表出错是某些字段偶发排查起来很折磨。目标端 HGDB 要确认版本号、兼容模式、监听端口以及目标库是否已经建好对应的 schema。HGDB 有兼容 Oracle 的模式建库时如果开了这个模式很多 Oracle 的类型和语法能平滑过去没开的话NUMBER、DATE、CLOB这些类型的映射规则会不一样抽取工具按默认规则走就可能报类型不兼容。运行抽取工具的机器重点看 JDK 版本和内存。这类工具多数是 Java 写的JDK 版本对不上会直接起不来内存给小了抽取大表时会 OOM。下面这张表是我这套环境实际用的对照版本号按你手上的安装包为准思路可以照搬组件我用的版本关键确认项不匹配的典型表现源端 Oracle11g / 19c字符集、抽取账号权限中文乱码、读元数据失败目标端 HGDB按安装包标注版本兼容模式、监听端口、schema类型不兼容、建表失败运行机 JDK与工具要求一致常见 8 或 11java -version输出工具启动即退出运行机内存不低于 4G大表建议 8G 以上JVM 堆参数抽取中途 OOM提示字符集这一项源端和目标端最好在动手前就用查询确认别信“应该是一样的”。我见过源库是 GBK、目标库建库时默认 UTF8 的情况前面小表抽取都正常到一张带中文备注的大表才炸。2.2 版本选择的取舍别追新追匹配抽取工具和两端数据库之间存在版本适配关系。工具版本太老可能不认识新版 HGDB 的驱动工具版本太新又可能要求更高版本的 JDK而运行机上还跑着别的老服务JDK 不好随便升。我的取舍原则是以目标端 HGDB 的版本为主选官方标注支持该 HGDB 版本的抽取工具版本源端 Oracle 只要在支持列表内就行。具体到操作拿到安装包后先看包里的说明或版本文件确认它声明的 JDK 要求和支持的数据库版本范围。如果运行机上已有 JDK先跑一遍# 查看当前 JDK 版本确认是否满足抽取工具要求 java -version # 同时看下 JAVA_HOME 指向哪里避免多版本 JDK 打架 echo $JAVA_HOMEjava -version输出里第一行的版本号要和工具要求对上JAVA_HOME要指向你打算用的那个 JDK而不是系统里残留的旧路径。多版本 JDK 共存时工具启动脚本读的是JAVA_HOME命令行java读的是PATH两者不一致就会出现“命令行看着是 11工具却按 8 跑”的玄学现象。确认无误再往下走这一步花五分钟能省后面半小时。3. 安装抽取工具解压、驱动、启动脚本三件事环境对齐之后安装本身反而简单。这类抽取工具通常不写注册表、不装系统服务解压即用真正要动手的是驱动放置和启动参数。下面按我实际的操作顺序走一遍。3.1 解压与目录规划先把安装包解压到一个路径不含中文和空格的目录。路径带空格是很多 Java 工具启动脚本翻车的根源脚本里引号没处理好JAVA_HOME拼出来的命令就断了。我一般放在/opt/hgdb-extract这类干净路径下# 创建安装目录路径避免中文和空格 mkdir -p /opt/hgdb-extract # 解压安装包到该目录包名以实际为准 tar -zxvf hgdb-extract-tool.tar.gz -C /opt/hgdb-extract # 进入目录看结构确认有启动脚本、lib、conf 等 ls -l /opt/hgdb-extract解压后重点看三处启动脚本常见是.sh结尾、lib目录放 JDBC 驱动、conf目录放连接配置。如果包里没有conf配置一般写在启动脚本同级或通过命令行参数传入看脚本里的变量定义就知道。目录规划的意义在于后面升级或回滚时整个目录替换即可不会把配置散落到系统各处。3.2 JDBC 驱动放置Oracle 与 HGDB 各一份抽取工具要同时连两端就得同时有 Oracle 的 JDBC 驱动和 HGDB 的 JDBC 驱动。Oracle 驱动一般是ojdbc系列 jarHGDB 驱动是瀚高提供的 jar 包。两个都要放进lib目录版本要和两端数据库大版本匹配——Oracle 11g 用太新的ojdbc可能连不上HGDB 驱动版本和 HGDB 服务端差太多也会报协议错误。# 把两端驱动放进 lib 目录文件名以实际包为准 cp ojdbc8.jar /opt/hgdb-extract/lib/ cp hgdb-jdbc.jar /opt/hgdb-extract/lib/ # 确认 lib 下驱动都在 ls -l /opt/hgdb-extract/lib/ | grep -Ei ojdbc|hgdb放完驱动别急着启动先确认启动脚本的 classpath 是否包含lib下所有 jar。多数脚本用lib/*通配那就没问题如果是逐个列 jar 名新加的驱动不会被加载表现为“驱动明明放了却报找不到驱动类”。这种情况要么改脚本加一行要么把驱动名改成脚本里已列的名字前者更干净。3.3 启动脚本里的 JVM 参数启动脚本里通常有一段 JVM 参数控制堆内存、字符集和临时目录。抽取大表时堆内存给小了会 OOM字符集没指定可能让日志里的中文变乱码。我一般会显式加上这几项# 编辑启动脚本在 JAVA_OPTS 里补充参数 JAVA_OPTS-Xms1g -Xmx4g -Dfile.encodingUTF-8 -Djava.io.tmpdir/opt/hgdb-extract/tmp-Xms和-Xmx是初始和最大堆大表抽取建议最大堆不低于 4G机器内存够就往上加-Dfile.encodingUTF-8固定 JVM 字符集避免日志和中间文件乱码-Djava.io.tmpdir把临时目录指到安装目录下防止系统/tmp空间不足导致抽取中断。临时目录要提前建好并给写权限否则工具启动时不会报错抽取到一半才失败属于典型的黑匣子问题。4. 配置连接与抽取任务参数填错比装错更常见工具装好、驱动就位接下来是配置。抽取工具的配置一般分两块两端的连接信息以及抽取任务的规则抽哪些表、字段怎么映射、批量多大。连接信息填错是最常见的失败原因而且报错往往不直观所以这一章把参数逐个说清。4.1 源端 Oracle 连接参数Oracle 连接串的写法取决于驱动版本老驱动用 SID新驱动用服务名。填之前先确认源库用的是 SID 还是服务名填反了会报ORA-12505之类的监听错误。抽取账号需要能读元数据和业务表一般给CONNECT加对目标表的SELECT权限就够不必给 DBA。# Oracle 源端连接配置示例 source.urljdbc:oracle:thin:192.168.1.10:1521:ORCL source.usernameextract_user source.password****** source.schemaBIZsource.url里1521是监听端口ORCL是 SID如果源库用服务名写法是//192.168.1.10:1521/服务名。source.schema指定抽取的业务 schema不填可能默认抽当前登录用户下的对象抽出来是空的。密码建议走配置文件权限控制别明文放在脚本里配置文件权限设成 600。4.2 目标端 HGDB 连接参数HGDB 的连接串格式和 PostgreSQL 系一致jdbc:hgdb://host:port/dbname或按驱动文档的写法。端口默认不是 5432 就是安装时指定的以实际监听为准。目标 schema 要提前建好抽取工具一般不会自动建 schema只会建表。# HGDB 目标端连接配置示例 target.urljdbc:hgdb://192.168.1.20:5866/hgdb target.usernamehgdb_user target.password****** target.schemaBIZ5866是这套环境实际用的端口你按自己安装时的监听端口填。target.schema要和源端 schema 对应上或者按迁移方案做映射。如果 HGDB 开了 Oracle 兼容模式类型映射基本能自动走没开的话NUMBER到数值类型、DATE到时间戳的映射要在任务配置里显式指定否则可能报类型不兼容。4.3 抽取任务的批量与并发参数抽取任务配置里有两个参数值得单独说批量提交大小和并发数。批量太小抽取慢批量太大单次事务过重出错回滚代价高。并发数开多了对源库压力大开少了抽得慢。我一般从保守值起步跑通再调。# 抽取任务参数示例 extract.batchSize1000 extract.parallel2 extract.commitInterval5000batchSize是每批读取的行数1000 是个稳妥起点大表可以试 5000parallel是并发抽取的线程数源库压力允许再往上加commitInterval控制提交频率按行数或时间提交避免长事务把源库 undo 撑爆。这几个参数没有万能值取决于表大小、网络和两端负载先小后大是血泪经验。5. 避坑与排查抽取失败时先看这五处抽取工具跑起来之后失败点集中在连接、字符集、类型、权限和资源五类。下面五条是我实际踩过或帮人处理过的按“现象 → 原因 → 解决”记下来遇到问题先对照。5.1 报找不到驱动类现象启动抽取任务直接报ClassNotFoundException提示 Oracle 或 HGDB 驱动类找不到。原因多半是驱动 jar 没放进lib或者启动脚本的 classpath 没包含新加的 jar。解决确认lib下驱动文件存在再检查脚本 classpath 是否用lib/*通配逐个列 jar 的脚本要手动补上驱动名。放完重启工具别在运行中替换 jar。5.2 中文数据抽取后变问号现象英文和数字正常中文备注、名称类字段抽过去变成问号或乱码。原因通常是源端和目标端字符集不一致或者 JVM 没指定file.encoding。解决先查两端字符集确认差异再在启动脚本加-Dfile.encodingUTF-8如果源库是 GBK抽取工具读取时也要按源库字符集解码必要时在连接参数里指定字符集。这类问题不要靠改数据补救要从链路源头对齐。5.3 类型不兼容导致建表失败现象结构抽取阶段报字段类型无法映射表建不出来。原因多是 HGDB 没开 Oracle 兼容模式NUMBER、DATE、CLOB等类型按默认规则映射失败。解决确认目标库兼容模式没开的话在任务配置里显式指定类型映射比如NUMBER映射到NUMERIC、DATE映射到TIMESTAMP。映射规则要按业务精度定别一刀切。5.4 抽取中途 OOM 或临时空间不足现象小表正常大表抽到一半进程退出或报内存错误。原因一是 JVM 堆太小二是临时目录空间不够。解决调大-Xmx把java.io.tmpdir指到大容量分区同时适当调小batchSize降低单批内存占用。抽取前先看下临时目录剩余空间大表抽取的中间文件可能不小。5.5 权限不足读不到元数据现象连接成功但抽结构时对象列表为空或报权限错误。原因抽取账号只有业务表SELECT没有读元数据视图的权限或者source.schema填错。解决给抽取账号补上读数据字典的权限确认 schema 名大小写和实际一致Oracle 里对象名默认大写填小写可能匹配不到。权限问题报错往往含糊先查账号权限再怀疑工具。6. 装完怎么验证先抽一张小表跑通全链路工具装好、配置填完别直接上生产大表。我的习惯是先找一张几十行、字段类型齐全的小表把“连接 → 读结构 → 建表 → 抽数据 → 校验”整条链路跑一遍全绿了再扩大范围。这一步是后悔药能提前暴露字符集、类型映射、权限三类问题代价最小。验证分三层。第一层是连通性工具里一般有测试连接按钮或命令两端都显示成功再往下。第二层是结构抽取抽一张小表的结构到目标库然后去 HGDB 里查表是否存在、字段类型是否符合预期-- 在 HGDB 目标库确认表结构和字段类型 SELECT column_name, data_type, character_maximum_length FROM information_schema.columns WHERE table_schema biz AND table_name t_demo ORDER BY ordinal_position;这条查询列出目标表的字段名、类型和长度重点看原来 Oracle 的NUMBER、DATE、VARCHAR2映射成了什么。类型对不上就回任务配置调映射规则别等数据抽完才发现。第三层是数据校验抽完小表后比对行数和关键字段。行数比对用两端各查一次COUNT(*)关键字段抽几条带中文的记录确认没有乱码。如果表里有时间字段还要看时区是否一致Oracle 的DATE和 HGDB 的时间戳在时区处理上可能有差异。验证层检查动作通过标准连通性两端测试连接均返回成功结构查目标表字段类型类型映射符合预期数据比对行数与中文样本行数一致、无乱码三层都过了再按表的重要性分批扩大抽取范围先抽无外键依赖的小表再抽大表和有关联的表。每批抽完做一次行数比对出问题能快速定位到具体批次。从那以后我每次做 Oracle 到 HGDB 的抽取都强制先走一遍这张小表的全链路不管多急都不跳过——跳过的那次往往就是后面花半天排查的那次。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助?