大家好我是小耶写功课只是为了我踩过的坑你们别再踩了Oracle 迁移到国产数据库是很多企业信创替代的必经之路。但能不能迁这个问题不能靠拍脑袋得靠数据说话。金仓 KingbaseES 作为 Oracle 兼容度最高的国产数据库之一官方宣称兼容率 90%。但这个数字怎么来的剩下的 10% 在哪迁移前到底要自查什么我实测了一套典型的 Oracle 业务系统约 200 张表、50 个存储过程、30 个触发器用金仓的 KDMS 评估工具做了一次完整兼容性分析。今天把评估报告和迁移过程中的真实发现整理出来。一、评估怎么做用 KDMS 一键扫描金仓的评估工具叫KDMSKingbase Database Migration Service做的事情很简单连接源 Oracle 库读取全部 schema 对象表、视图、索引、约束、序列、存储过程、函数、触发器、包逐项比对与 KingbaseES 的兼容程度输出评估报告整个过程不需要改源库不会对生产造成影响。跑完一份完整的评估报告大约 10-30 分钟取决于对象数量。二、兼容性自查的 5 个核心维度维度 1SQL 语法兼容KingbaseES 基于 PostgreSQL 内核但在 Oracle 兼容模式ORA 兼容下大量 Oracle 特有的 SQL 语法被直接支持Oracle 语法KingbaseES 支持情况SELECT ... FROM DUAL✅ 完全支持NVL()/NVL2()✅ 完全支持DECODE()✅ 完全支持SYSDATE/SYSTIMESTAMP✅ 完全支持ROWNUM伪列✅ 完全支持CONNECT BY递归查询✅ 完全支持MERGE INTO✅ 完全支持ROWID伪列✅ 支持语义略有差异()外连接语法⚠️ 支持但不推荐建议改用 ANSI JOIN层次查询START WITH ... CONNECT BY✅ 完全支持结论日常业务 SQL 的兼容率通常在 95% 以上。不兼容的主要是极个别的 Oracle 特有函数和语法糖。维度 2数据类型映射这是迁移中最容易踩坑的地方。KingbaseES 的 ORA 兼容模式对 Oracle 数据类型做了大量适配Oracle 类型KingbaseES 映射注意事项NUMBER(p,s)NUMBER(p,s)完全一致VARCHAR2(n)VARCHAR2(n)ORA 模式下直接支持DATETIMESTAMP(0)KingbaseES 的 DATE 不含时间ORA 模式下映射为 TIMESTAMPCLOBCLOB完全一致BLOBBLOB完全一致RAW(n)RAW(n)完全一致LONGTEXTOracle 已废弃 LONG建议迁移时一并改为 CLOBBFILE不支持外部文件引用需在应用层改造TIMESTAMP WITH TIME ZONETIMESTAMP WITH TIME ZONE完全一致NVARCHAR2(n)NVARCHAR2(n)ORA 模式下支持结论常见数据类型的兼容率很高。需要重点关注的是LONG类型Oracle 已废弃和BFILE不支持这两类需要在迁移前做应用层改造。维度 3存储过程和 PL/SQL这是兼容性差距最大的部分也是决定迁移周期的关键因素。KingbaseES 支持 PL/SQL 的绝大多数语法包括匿名块BEGIN ... END;命名块PROCEDURE、FUNCTION、PACKAGE游标显式/隐式异常处理EXCEPTION WHEN ... THEN动态 SQLEXECUTE IMMEDIATE集合类型TABLE OF / VARRAY记录类型RECORD不兼容或需要改写的部分Oracle 特有内置包DBMS_OUTPUT、DBMS_JOB、UTL_FILE、DBMS_RANDOM等。金仓提供了部分包的替代实现如DBMS_OUTPUT有对应实现但DBMS_JOB需要用 KingbaseES 的定时任务机制替代触发器语法差异Oracle 的REFERENCING NEW AS语法在 KingbaseES 中写法不同自治事务PRAGMA AUTONOMOUS_TRANSACTION支持情况需具体测试管道函数PIPELINED函数支持有限实测数据在一套包含 50 个存储过程的系统中约 35 个70%可以直接迁移10 个20%需要少量语法改写5 个10%涉及 Oracle 特有包需要较大改动。维度 4触发器和序列触发器的兼容率通常较高85%但有几个注意点BEFORE/AFTER触发器✅ 完全支持INSTEAD OF触发器✅ 支持行级触发器FOR EACH ROW✅ 完全支持语句级触发器✅ 完全支持REFERENCING NEW/OLD语法需要调整序列SEQUENCE完全兼容CREATE SEQUENCE、NEXTVAL、CURRVAL语法一致。维度 5索引和约束B-Tree 索引✅ 完全支持唯一索引✅ 完全支持函数索引✅ 支持位图索引❌ KingbaseES 不支持位图索引Oracle 特有需要改为 B-Tree 索引域索引Oracle Text❌ 不支持需要应用层改造外键约束✅ 完全支持CHECK 约束✅ 完全支持延迟约束DEFERRABLE✅ 支持三、实测迁移流程复盘Step 1KDMS 评估30 分钟连接 Oracle 源库生成评估报告。核心指标表结构兼容率98%数据类型兼容率95%存储过程兼容率70%触发器兼容率85%视图兼容率92%Step 2KDTS 结构迁移10 分钟自动将 Oracle 的 DDL 转换为 KingbaseES 语法并执行。大部分表和索引自动创建成功少数需要手动调整如位图索引改为 B-Tree。Step 3KDTS 数据迁移2 小时200 张表总数据量约 50GB。KDTS 并行迁移2 小时完成。迁移期间源库可正常读写。Step 4KDC 数据校验1 小时自动比对源库和目标库的行数、关键字段 CHECKSUM。发现 3 张表的TIMESTAMP精度有微秒级差异确认为 Oracle 和 KingbaseES 时间精度差异不影响业务。Step 5存储过程手动适配3 天50 个存储过程中 35 个直接通过10 个修改了 Oracle 特有语法后通过5 个涉及DBMS_JOB和UTL_FILE用 KingbaseES 的替代方案重写。四、迁移成本评估从实测来看Oracle 迁移到金仓 KingbaseES 的工作量主要在三个部分工作内容工作量占比说明存储过程适配50%70% 可直接迁移30% 需要改写应用 SQL 调整20%大部分 SQL 无需改动少数特有语法需调整数据迁移 校验20%工具自动化完成测试验证10%功能测试 性能测试如果系统中存储过程数量多、Oracle 特有包使用频繁迁移周期会相应拉长。反之如果业务以简单 CRUD 为主迁移可以非常快。五、迁移前的自查清单在正式启动迁移前建议按以下清单逐项确认运行 KDMS 评估拿到兼容性报告确认整体兼容率盘点 Oracle 特有包列出所有使用的DBMS_/UTL_包逐一确认替代方案检查位图索引如果有位图索引提前规划改为 B-Tree 索引确认时间精度需求OracleTIMESTAMP精度到纳秒KingbaseES 默认微秒确认是否影响业务制定存储过程改写计划按 直接迁移 / 少量改写 / 较大改写 分类估算工作量准备回切方案迁移后如果发现问题需要有快速切回 Oracle 的预案总结金仓 KingbaseES 的 Oracle 兼容度在日常业务场景下可以达到 90%存储过程场景下约 70%-80% 可以直接迁移。迁移的关键不是能不能迁而是评估先行、分类处理SQL 和数据大部分可以直接迁存储过程需要逐一看Oracle 特有包提前找替代方案。小耶在手SQL不愁。还有什么想了解的欢迎留言小耶一定知无不言言无不尽……我们下次见~