1. 项目概述最近在帮客户做数据库迁移项目需要将Oracle 11g RAC集群中的数据迁移到openGauss 6.0.3 LTS版本。经过技术选型最终选择了阿里开源的DataX作为数据迁移工具。DataX作为阿里巴巴集团内部广泛使用的离线数据同步工具其稳定性和性能在业界有口皆碑。这次迁移涉及的是HR模块的EMPLOYEES表包含107条员工记录。虽然数据量不大但作为生产环境迁移的POC验证需要确保每个环节都万无一失。下面我将详细记录整个迁移过程包括环境准备、配置细节和踩过的坑。2. 环境准备与工具安装2.1 环境拓扑说明迁移环境采用经典的两层架构源端Oracle 11g RAC集群主机名oradb1IP192.192.103.123 (VIP)数据库服务名oradb测试用户hr/hr目标端openGauss单节点主机名opengaussdbIP192.192.103.134数据库名testdb用户hr/Huawei_1234DataX部署在目标端服务器上版本为官方GitHub最新release版注意生产环境中建议将DataX部署在独立的中转服务器上避免对源库和目标库造成资源争用2.2 DataX安装步骤下载安装包 从GitHub官方仓库(https://github.com/alibaba/DataX)下载最新稳定版的datax.tar.gz解压安装cd /soft tar -xzf datax.tar.gz解压后会生成datax目录包含以下关键子目录bin执行脚本conf配置文件plugin各种Reader/Writer插件job任务模板环境验证python bin/datax.py job/job.json这个自检任务会验证DataX基础功能是否正常。成功执行后应该看到类似输出任务总计耗时 : 10s 记录写入速度 : 10000rec/s 读写失败总数 : 03. 迁移实施详解3.1 前置检查Oracle端检查sqlplus hr/hr192.192.103.123:1521/oradb SQL select count(*) from EMPLOYEES;openGauss端检查gsql -h 192.192.103.134 -p 15400 -Uhr -d testdb -W Huawei_1234 testdb select count(*) from employees;重要提示确认两端表结构兼容性。虽然DataX会自动处理大部分数据类型映射但对于Oracle特有的数据类型(如CLOB、BLOB等)需要提前做好转换方案。3.2 认证方式适配这是本次迁移遇到的第一个坑openGauss默认使用SCRAM-SHA-256认证而DataX的postgresqlwriter插件目前仅支持MD5认证。解决方法修改openGauss密码加密方式gs_guc reload -N all -I all -c password_encryption_type0修改pg_hba.confhost all all 0.0.0.0/0 md5 gs_ctl reload重置用户密码alter user hr password Huawei_1234;安全提示迁移完成后建议恢复为SHA-256加密MD5仅作为临时方案使用3.3 任务配置文件详解创建迁移任务配置文件ora2gsdb.json核心配置项说明{ job: { content: [{ reader: { name: oraclereader, parameter: { username: hr, password: hr, column: [*], // 迁移所有列 connection: [{ table: [EMPLOYEES], jdbcUrl: [jdbc:oracle:thin://192.192.103.123:1521/oradb] }] } }, writer: { name: postgresqlwriter, parameter: { username: hr, password: Huawei_1234, column: [*], connection: [{ jdbcUrl: jdbc:postgresql://192.192.103.134:15400/testdb, table: [employees] }] } } }], setting: { speed: { channel: 2 // 并发通道数 } } } }关键参数优化建议channel数建议设置为源库CPU核数的1/4到1/2batchSize大数据量时可适当调大(默认1024)fetchSizeOracle读取批次大小(默认1000)3.4 执行迁移任务python bin/datax.py job/ora2gsdb.json成功执行后输出示例任务启动时刻 : 2026-03-12 10:58:04 任务结束时刻 : 2026-03-12 10:58:15 任务总计耗时 : 11s 记录写入速度 : 10rec/s 读出记录总数 : 107 读写失败总数 : 04. 验证与问题排查4.1 数据一致性验证记录数比对-- Oracle端 SELECT COUNT(*) FROM EMPLOYEES; -- openGauss端 SELECT COUNT(*) FROM employees;抽样数据比对-- 随机抽取5条记录比对 SELECT * FROM employees ORDER BY RANDOM() LIMIT 5;4.2 常见问题解决方案问题1日期格式不一致现象Oracle的DATE类型迁移后时间部分丢失解决方案在writer配置中添加类型转换type: timestamp, format: YYYY-MM-DD HH24:MI:SS问题2字段名大小写问题现象Oracle大写字段名在openGauss中需要引号解决方案在writer中明确指定字段名column: [EMPLOYEE_ID, FIRST_NAME, ...]问题3特殊字符处理现象包含反斜杠等特殊字符的数据迁移失败解决方案在reader配置中添加escape: \\5. 性能优化建议批量提交优化batchSize: 2048, postSql: [ANALYZE employees]索引处理策略迁移前禁用目标表索引迁移后重建索引网络调优fetchSize: 5000, session: [ ALTER SESSION SET NLS_DATE_FORMATYYYY-MM-DD HH24:MI:SS ]资源控制setting: { speed: { byte: 1048576, // 限制1MB/s channel: 4 } }6. 项目总结这次迁移虽然数据量不大但完整走通了Oracle到openGauss的迁移流程验证了几个关键点DataX对Oracle和openGauss的兼容性良好认证方式需要特殊处理数据类型映射需要特别注意对于更大的数据量迁移建议采用分批次迁移策略增加数据校验环节考虑使用DataX的增量同步功能整个过程中最耗时的部分其实是环境准备和问题排查实际数据迁移只用了11秒。这也印证了数据库迁移项目中准备大于执行的特点。
