引言：国产化浪潮下的数据库迁移需求
在信息技术国产化战略背景下，数据库作为信息系统的核心组件，其自主可控显得尤为重要。本文记录了将原有Oracle数据库系统迁移至金仓数据库(Kingbase)的完整过程，包括前期准备、迁移实施、适配改造以及性能优化等关键环节，旨在为类似项目提供参考。
一、迁移背景与前期评估
1.1 项目背景
我们负责的系统原本运行在Oracle数据库上，随着国产化要求的提出，经过多方评估最终选择了金仓数据库V9版本作为替代方案。金仓数据库作为国产数据库的佼佼者，兼容Oracle语法和协议，支持PL/SQL，这大大降低了我们的迁移成本。
1.2 环境评估
金仓数据库部署在172.16.60.174服务器上，使用54321端口，数据库名为testdb。系统提供了两个业务用户：
- tenduser
- smhuser
目标端kingbase数据库信息：
平台架构：X86
数据库版本：KingbaseES V9(V009R001C001B0025)
IP：172.16.60.174
端口：54321
数据库：testdb
源端Oracle数据库信息：
平台架构：X86
数据库版本：11g
ip：172.16.60.200
端口：1521
数据库：testdb
数据同步工具信息：
同步工具：金仓KDTS
版本：v1.0.3.138
访问地址：http://172.16.60.174:54523/#/login
迁移用户：
- tenduser
- smhuser
1.3 数据规模评估
从迁移记录来看，系统涉及的表数量庞大，其中数据量较大的表包括：
- ORG表：20633条记录
- DICTIONARY表：24698条记录
- ACCOUNT_NEW/ACCOUNT_OLD表：各208216条记录
- MENU_USER_USE_INFO表：14503条记录
这些大数据量表的存在意味着我们需要特别关注迁移效率和性能表现。
二、迁移工具与平台使用
2.1 KDTS迁移平台
金仓提供了专门的KDTS(Kingbase Data Transfer Service)迁移平台，部署在http://172.16.60.174
在实际使用中，我们发现KDTS平台具有以下特点：
- 可视化操作界面，降低了迁移门槛
- 支持结构迁移、数据迁移、数据校验等完整流程
- 提供迁移报告和问题定位功能
- 支持断点续传，这对大数据量表特别有用
2.2 迁移过程记录
数据迁移情况
smhuser：表：75张，数据总量：66964条，主键约束：65，索引：16，唯一约束：8，触发器：2，注释：1003.
tenduser：表：79张，数据总量：503054条，主键约束：51，索引：52，唯一约束：5，触发器：0，注释：1128.
所有结构和数据全部迁移成功，无报错信息。
特别值得注意的是，系统中有两个触发器也成功迁移：
- TRG_USER_TO_LX
- HDTY$HD_USER_CHANGE_SYNC
触发器的成功迁移说明金仓数据库在PL/SQL兼容性方面表现良好。
三、应用适配与改造
3.1 JDBC驱动配置
根据文档中的配置示例，我们在pom.xml中添加了金仓数据库驱动依赖：
<dependency> <groupId>cn.com.kingbase</groupId> <artifactId>kingbase8</artifactId> <version>8.6.0</version> <scope>provided</scope> </dependency>
数据源配置调整为：
framework: driver-class-name: com.kingbase8.Driver url: jdbc:kingbase8://172.16.60.174:54321/testdb druid: username: tenduser password: XXXX
3.2 SQL语法适配
在迁移过程中，我们发现大部分标准SQL语句无需修改即可运行。需要特别注意的适配点包括：
- 分页查询：金仓支持Oracle的ROWNUM语法，但推荐使用标准的LIMIT/OFFSET
- 序列使用：金仓的序列语法与Oracle略有不同
- 日期函数：部分日期函数需要调整，如TO_DATE改为CAST(... AS DATE)
- 空值处理：NVL函数改为COALESCE
3.3 MyBatis适配
文档特别提到MyBatis-Plus版本选择的重要性：
<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.4.1</version> </dependency>注意避免使用3.5.1版本，因为该版本的count函数返回值类型变化会导致大量代码需要修改。
3.4 应用服务器适配
原系统使用Tomcat作为应用服务器，迁移后改为TongWeb。这需要在pom.xml中排除Tomcat相关依赖：
<exclusions> <exclusion> <artifactId>spring-boot-starter-tomcat</artifactId> <groupId>org.springframework.boot</groupId> </exclusion> </exclusions>
软件适配情况及注意事项
软件增删改查及分页全部正常。
注意事项：
1、驱动版本使用的是：kingbase8-8.6.0.jar，9.0无法引入。
2、mybatis-plus版本：3.4.1，版本3.5.1存在问题，count函数出来的是long形式参，要大量更改代码 不建议3.5.1。
3、数据源配置：filters: stat #动态数据源取的配置路径金仓和达梦都一样。
4、应用程序配置：<!-- 需要将涉及到tomcat地方全部排除掉 --> <artifactId>spring-boot-starter-tomcat</artifactId> <groupId>org.springframework.boot</groupId>
四、迁移后的验证与优化
4.1 数据一致性验证
我们采用了以下方法验证数据一致性：
- 记录数对比：确保源表和目标表记录数一致
- 抽样校验：随机抽取数据进行内容比对
- 聚合校验：检查SUM、COUNT等聚合结果
- 业务校验：通过业务功能验证数据正确性
从迁移记录来看，所有表的"源库记录数"和"迁移成功记录数"完全一致，初步验证了数据完整性。
4.2 性能优化实践
迁移完成后，我们对系统进行了性能测试和优化：
索引优化：分析执行计划，添加必要的索引。例如，为HD_LOG表添加了多个索引以提高查询效率：
CREATE INDEX IDX_LOG_CURRENT_USERNAME ON LOG(CURRENT_USERNAME); CREATE INDEX IDX_LOG_CURRENT_USER_ID ON LOG(CURRENT_USER_ID);SQL重写：优化复杂查询，避免全表扫描
参数调整：优化金仓数据库的内存参数配置
连接池配置：调整Druid连接池参数以适应新的数据库特性
4.3 兼容性问题解决
在迁移过程中遇到并解决的主要兼容性问题：
- Oracle特有函数：如WM_CONCAT()需要替换为STRING_AGG()
- 特殊语法：如(+)外连接语法改为标准LEFT JOIN
- 事务隔离级别：调整应用代码以适应金仓的默认隔离级别
- LOB处理：金仓对LOB类型的处理方式与Oracle略有不同
根据迁移记录，所有表结构迁移均显示"成功"状态，主键约束和索引也全部迁移成功。数据迁移方面，源库记录数与目标库记录数完全一致，表明数据完整性得到了保证。
五、经验总结与建议
5.1 迁移经验总结
通过本次迁移实践，我们总结了以下经验：
- 前期评估至关重要：充分评估数据库对象复杂度、数据量大小和业务特性
- 工具辅助提高效率：善用KDTS等迁移工具可以事半功倍
- 分阶段实施：建议先迁移结构，再迁移数据，最后进行应用适配
- 充分测试：需要安排足够时间进行功能测试和性能测试
- 回退方案：准备完善的回退方案以应对意外情况
5.2 对金仓数据库的评价
从技术角度看，金仓数据库具有以下优势：
- 高兼容性：对Oracle语法和特性的兼容度较高
- 性能稳定：在大数据量情况下表现稳定
- 工具完善：提供完整的迁移和管理工具链
- 文档齐全：技术文档详细，降低了学习成本
需要改进的方面：
- 部分高级特性与Oracle仍有差距
- 错误信息的友好度有待提高
- 性能诊断工具可以更加丰富
5.3 对未来项目的建议
对于计划进行类似迁移的项目，我们建议：
- 建立专业团队：包括DBA、开发人员和业务专家
- 制定详细计划：明确各阶段目标、时间点和责任人
- 充分测试：特别是业务高峰期场景测试
- 培训计划：对团队进行金仓数据库专项培训
- 长期优化：迁移后持续进行性能监控和优化
六、结语
本次从Oracle到金仓数据库的迁移实践，不仅完成了技术平台的国产化替代，也为团队积累了宝贵的经验。金仓数据库在兼容性、性能和稳定性方面的表现令人满意，虽然过程中遇到了一些挑战，但通过团队的努力都得到了妥善解决。
未来，我们将继续深入探索金仓数据库的高级特性，进一步优化系统性能，同时将这次迁移的经验教训总结成内部知识库，为后续项目提供参考。数据库国产化道路虽然充满挑战，但通过不断实践和积累，我们正逐步建立起对国产数据库技术的信心和能力。
