1.迁移背景

响应国资委下发79号文件，全面指导并要求国央企落实信息化系统的信创国产化改造。
其中，明确要求所有中央企业在2022年11月底前将安可替代总体方案报送国资委；
自2023年1月起，每季度末向国资委报送信创系统替换进度。
最终要求2027年底前，实现所有中央企业的信息化系统安可信创替代。

2.为什么选择opengauss

生态兼容

社区活跃度

研发实力

大厂背景

享受引擎带来的对SQL标准和NoSQL的高度兼容、强大的处理复杂查询能力、以及丰富的插件支持等特性
同时还能大幅节省运维成本和硬件投入。

3.迁移的对象

本项目需要将一期oracle数据库切换成opengauss关系型数据库。
具体涉及到的表格和工作内容如下所示：

4.迁移的数据量

20GB

5.迁移工具选择

aws Schema Conversion Tool：迁移元数据、和生成评估报告
Kettle：适合异构数据量比较小,可以一键迁移

6.aws Schema Conversion Tool迁移元数据

6.1迁移思路

因为aws Schema Conversion Tool不支持opengauss，所以需要安装PG
先把元数据迁移到PG里，从PG里导出sql，然后在导入opengauss中

6.2迁移步骤

第一款工具aws Schema Conversion Tool闪亮登台

6.2.1设置数据库的驱动

6.2.2迁移源数据

7.迁移数据

第二款工具kettle闪亮出马
本人太喜欢kettle这款工具，有10多年的kettle使用经验

7.1设置源端数据源（oracle）

7.2设置目标端数据源（opengauss）

7.3编写一键迁移总按钮

非常灵活，迁移过程中可以对数据进行改造、可以过滤不迁移的表，只需点一下，所有的表迁移完成

8.数据校验

校验所有表的数据量：count(*)
如果非要校验数据迁移完成之后对数据做对比：验证HASH算法、MD5算法。
本人觉的数据校验意义不大，所以这次迁移只校验数据量和中文有没有乱码。

9.迁移难点

难点在于元数据迁移视图、存储过程、函数,aws Schema Conversion Tool不可能100%完成这项工作，
所以视图、存储过程、函数还需要开发根据实际业务工作情况改写。