大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
Oracle 迁移到国产数据库，是很多企业信创替代的必经之路。但"能不能迁"这个问题，不能靠拍脑袋，得靠数据说话。
金仓 KingbaseES 作为 Oracle 兼容度最高的国产数据库之一，官方宣称兼容率 90%+。但这个数字怎么来的？剩下的 10% 在哪？迁移前到底要自查什么？
我实测了一套典型的 Oracle 业务系统（约 200 张表、50 个存储过程、30 个触发器），用金仓的 KDMS 评估工具做了一次完整兼容性分析。今天把评估报告和迁移过程中的真实发现整理出来。
一、评估怎么做：用 KDMS 一键扫描
金仓的评估工具叫 KDMS（Kingbase Database Migration Service），做的事情很简单：
- 连接源 Oracle 库
- 读取全部 schema 对象（表、视图、索引、约束、序列、存储过程、函数、触发器、包）
- 逐项比对与 KingbaseES 的兼容程度
- 输出评估报告
整个过程不需要改源库，不会对生产造成影响。跑完一份完整的评估报告，大约 10-30 分钟（取决于对象数量）。
二、兼容性自查的 5 个核心维度
维度 1：SQL 语法兼容
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 模式下直接支持 |
DATE | TIMESTAMP(0) | KingbaseES 的 DATE 不含时间，ORA 模式下映射为 TIMESTAMP |
CLOB | CLOB | 完全一致 |
BLOB | BLOB | 完全一致 |
RAW(n) | RAW(n) | 完全一致 |
LONG | TEXT | Oracle 已废弃 LONG，建议迁移时一并改为 CLOB |
BFILE | 不支持 | 外部文件引用，需在应用层改造 |
TIMESTAMP WITH TIME ZONE | TIMESTAMP 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） - 动态 SQL（
EXECUTE 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 1：KDMS 评估（30 分钟）
连接 Oracle 源库，生成评估报告。核心指标：
- 表结构兼容率：98%
- 数据类型兼容率：95%
- 存储过程兼容率：70%
- 触发器兼容率：85%
- 视图兼容率：92%
Step 2：KDTS 结构迁移（10 分钟）
自动将 Oracle 的 DDL 转换为 KingbaseES 语法并执行。大部分表和索引自动创建成功，少数需要手动调整（如位图索引改为 B-Tree）。
Step 3：KDTS 数据迁移（2 小时）
200 张表，总数据量约 50GB。KDTS 并行迁移，2 小时完成。迁移期间源库可正常读写。
Step 4：KDC 数据校验（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 索引
- 确认时间精度需求：Oracle
TIMESTAMP精度到纳秒，KingbaseES 默认微秒，确认是否影响业务 - 制定存储过程改写计划：按 直接迁移 / 少量改写 / 较大改写 分类，估算工作量
- 准备回切方案：迁移后如果发现问题，需要有快速切回 Oracle 的预案
总结
金仓 KingbaseES 的 Oracle 兼容度，在日常业务场景下可以达到 90%+，存储过程场景下约 70%-80% 可以直接迁移。
迁移的关键不是"能不能迁"，而是评估先行、分类处理：SQL 和数据大部分可以直接迁，存储过程需要逐一看，Oracle 特有包提前找替代方案。
小耶在手，SQL不愁。
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
