从Oracle到K-DB数据库迁移说明
一、 背景说明
随着国家有关部门近年来陆续出台相关政策指导文件，推动探索安全可控的金融科技产品，加强银行业信息安全建设，国内众多金融政企机构纷纷开始探索改造原有 IT 系统，对国产化数据库的需求日益强烈。
本次迁移测试项目采用了 K1 Power Linux 服务器 +K-DB 的组合替换原有的 x86 服务器 +Oracle 组合。
本次数据库迁移测试选取的数据库大小约为 80GB ，迁移测试系统环境说明如下：
| 主机配置 | 数据库版本 | |
| 源库 | X86服务器； 32core，380GB内存； | Oracle 11.2 |
| 目标库 | K1 Power Linux服务器，采用oVirt虚拟化管理； 虚拟机配置： 8core，16GB内存； | K-DB 11 |
二、迁移步骤
1、 在目标环境创建对应表空间
因为服务器磁盘挂在路径名称可能不同，所以需要手动提前创建表空间
create tablespace credit datafile '/home/kdb/kdb11/database/kdb/CREDIT001.dtf' size 1G autoextend on next 1G
create tablespace credit_index datafile '/home/kdb/kdb11/database/kdb/CREDIT_INDEX001.dtf' size 1G autoextend on next 1G
create tablespace USERS datafile '/home/kdb/kdb11/database/kdb/USERS001.dtf' size 700M autoextend on next 1G
判断 mycredit 用户下的 segments 总的字节数大概 80G
select sum (bytes)/ 1024 / 1024 ,tablespace_name from dba_segments where owner= 'MYCREDIT' group by tablespace_name
所以 credit 表空间要添加三个数据文件每个数据文件大小 32G 。
2、 启动 T-UP 进行迁移
配置 oracle 数据库连接
配置字段类型转换规则（如果没有特殊要求默认不需要修改）
连接 K-DB
迁移概要
点击开始迁移
可以看到正在迁移的对象类型，以及迁移进度
三、迁移问题汇总
1 、对象个数对比以及解决方法
迁移用时：
表和数据迁移用时 2 小时 45 分。主要影响因素为网络带宽。
索引和约束迁移用时 3 小时。主要影响因素为目标端系统 IO 性能。
其他对象迁移用时 15 分钟。
约 97% 的迁移工作由 T-UP 自动化迁移工具完成。
| oracle | K-DB | |||
| 对象个数 | 对象类型 | 对象个数 | 对象类型 | 原因 |
| 83 | FUNCTION | 83 | FUNCTION | |
| 1149 | INDEX | 1136 | INDEX | 有13个alter table 添加主键约束语句失败，手动创建解决 |
| 208 | LOB | 146 | LOB | 缺少的LOB对象是回收站中的已经删除的LOB，未清空回收站所致。 此为正常现象，可以忽略。 |
| 127 | PACKAGE | 127 | PACKAGE | |
| 122 | PACKAGE BODY | 118 | PACKAGE BODY | 四个创建失败经过对比发现中文括号问题导致创建失败，修改后解决。开发过程严格遵守代码规范可以避免此问题。 |
| 30 | PROCEDURE | 30 | PROCEDURE | |
| 154 | SEQUENCE | 154 | SEQUENCE | |
| 143 | SYNONYM | 143 | SYNONYM | |
| 1155 | TABLE | 1139 | TABLE | 差异原因DR$开头的表，这些是全文索引创建时自动生成的，K-DB创建全文索引时的表和oracle不一样。 此为正常现象，可以忽略。 |
| 300 | TRIGGER | 300 | TRIGGER | |
| 7 | TYPE | 7 | TYPE | |
| 99 | VIEW | 96 | VIEW | 三个视图主要是中文括号问题，修改后手工创建成功。开发过程严格遵守代码规范可以避免此问题。 |
| 对象总数3577 | 合计3479 | 总结：通过T-UP直接迁移完成3479个对象，迁移成功约97%，手动修改对象数36个（排除LOB类型）。 无效对象个数34个（排除oracle无效对象之后）处理完成31个，剩余3个package body 还未解决 | ||
2、 无效对象处理
无效对象经过和 Oracle原库对比发现，失效对象主要集中在 pakcage 部分，排除掉因为中文括号问题导致编译失败问题后，仍然报错的 package 以及原因如下
| package名称 | 问题描述 |
| PKG_TOOL | 1、该package中设计重载函数GET_XML FUNCTION GET_XML(P_XML IN XMLTYPE) RETURN CLOB; FUNCTION GET_XML(P_XML IN VARCHAR2) RETURN VARCHAR2; FUNCTION GET_XML(P_XML IN CLOB) RETURN CLOB; 其中输入参数为XMLTYPE和CLOB的两个重载函数冲突，K-DB有自带函数可以直接实现XMLTYPE到CLOB的转换。 2、 该package的函数FUNCTION TWOVALUETONUMLIST ( MINV IN INTEGER, MAXV IN INTEGER ) RETURN NUMTABLETYPE AS VCURV INTEGER; V_DATA NUMTABLETYPE := NUMTABLETYPE(); 要求返回参数是numtabletype，通过手工创建oracle对应类型CREATE OR REPLACE TYPE NUMTABLETYPE as table of number;但是仍然报错TBR-2058: Invalid data type. |
| PKG_SETDATA | 需要调用PKG_TOOL 中的TWOVALUETONUMLIST函数。 |
四、迁移总结
本次迁移采用了 T-UP 图形化工具，比较简单地实现从 Oracle 到 K-DB 的数据与存储过程、自定义函数等对象的迁移。整个迁移过程十分方便、快捷，只需要简单的配置。如果存储过程在开发过程中严格遵守代码规范，例如不使用中文扩号，则可以实现 99% 的迁移工作不需要人工干预。
同时， K-DB 在极少数不常用的 Package 上，没有百分百与 Oracle 兼容，需要对应用代码作比较小的修改。
通过本次迁移，可以看到 K-DB 与 Oracle 有非常高的兼容性，迁移过程也十分的简单方便。
如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！
赞1
添加新评论0 条评论