从 Oracle 到电科金仓：一次真实迁移，把我逼清醒的 4 个致命问题
从 Oracle 到电科金仓：一次真实迁移，把我逼清醒的 4 个致命问题
——不讲“兼容率”，只讲我线上是怎么救回来的
如果你正在做 Oracle → 国产数据库迁移，
系统里还有一堆年纪比你都大的 PL/SQL，
那你大概率会在某个深夜，和我遇到同样的问题。这篇文章不谈理念、不讲趋势，只复盘一件事：
Oracle 的老代码，放到电科金仓（KES）里，到底要怎么才能跑稳。
一、我最早犯的一个错：把“Oracle 兼容”当成了“Oracle 本身”
项目刚启动时，方案里有一句话我至今记得很清楚：
“电科金仓支持 Oracle 兼容模式，迁移风险可控。”
这句话本身没问题，问题出在我当时的理解太天真。
真正上手之后，我才慢慢意识到两件完全不同的事：
- 兼容模式解决的是：能不能跑
- 真正迁移解决的是：跑得对不对、稳不稳
尤其是下面这些地方，几乎是“集中爆雷区”：
- OCI / 客户端连接
- PL/SQL 匿名块
- JSON 相关逻辑
- 物化视图及刷新方式
下面这些坑，都是我按真实踩坑顺序，一个个爬出来的。
二、第一天就翻车：数据库连不上，直接给我一个 OCI-21500
2.1 现场非常真实：连库都连不上
环境刚交付，我习惯性用 OCI 测了一下：
sqlplus sys/xxx@127.0.0.1:54321/orcl as sysdba
结果没有任何铺垫，直接报：
OCI-21500: internal error code, arguments: [kpodOpen]
说实话，这个错误在 Oracle 体系里我几乎没见过。
第一反应不是“配置问题”，而是：这环境是不是有问题？
2.2 后来才发现：不是环境，是我想当然了
折腾了一圈才意识到一个很基础、但极容易被忽略的事实：
KES 并不会默认给你一套完整的 Oracle 行为。
Oracle 兼容模式，是需要明确打开的，而且影响的是一整套行为，而不只是语法。
一句话总结：
👉 Oracle 兼容 ≠ 装好就生效
2.3 正确处理方式（别嫌基础，真有人踩）
ALTER SYSTEM SET ora_compatible = on;
-- 然后重启实例
⚠️ 这里有个非常容易翻车的点：
一定确认你改的是持久化配置，不是会话级。
2.4 我现在的处理习惯
只要出现下面这些问题之一：
- OCI 连接异常
- PL/SQL 行为奇怪
- 系统包调用异常
第一步永远不是怀疑代码，而是先确认兼容参数。
三、PL/SQL 匿名块跑不起来：这是最容易被低估的坑
3.1 一个在 Oracle 里“理所当然”的例子
set serveroutput on;
DECLARE
v_cnt NUMBER := 10;
BEGIN
DBMS_OUTPUT.PUT_LINE(v_cnt);
END;
/
这段在 Oracle 里跑了多少年，没人会多看一眼。
但在 KES 里，它就是不认。
3.2 错的不是逻辑，是我们默认的“运行环境”
Oracle 用久了，很容易形成几个下意识的假设：
- SQL*Plus 命令和脚本可以混着写
- DBMS_OUTPUT 随手就能用
- 匿名块怎么写都能兜住
但在 KES 里，这些假设并不成立：
- SQL*Plus 指令不是 PL/SQL 语法
- 输出机制不一样
- 对结构要求更明确
3.3 在 KES 里，我现在会这样写
DO $$
DECLARE
v_cnt INTEGER := 10;
BEGIN
RAISE NOTICE 'v_cnt=%', v_cnt;
END $$;
3.4 这类问题，我的迁移原则是
- 把匿名块当程序，而不是脚本
- 输出、异常、变量声明全写清楚
- 不要再指望“环境帮你兜底”
四、JSON 一直返回 NULL：我一度以为是 bug
4.1 当时最让我困惑的一条 SQL
SELECT json_value('{"name":"张三","age":18}', '$.name') FROM dual;
Oracle 返回正常
KES 返回 NULL
第一反应很真实：
“这不可能吧？”
4.2 冷静下来才发现：问题出在类型
在 KES 里，有一条规则非常重要：
字符串就是字符串，JSON 就是 JSON。
它不会像 Oracle 那样，帮你偷偷做隐式转换。
4.3 正确方式一：类型显式化
SELECT json_value('{"name":"张三","age":18}'::json, '$.name') FROM dual;
4.4 正确方式二：直接用 JSON 操作符
SELECT '{"name":"张三","age":18}'::json #>> '{name}' FROM dual;
4.5 我现在的结论很明确
👉 所有 JSON 相关逻辑，迁移时必须先“显式类型”
👉 不要再依赖 Oracle 留下来的“隐式习惯”
五、物化视图刷新：真正拖慢上线节奏的地方
5.1 Oracle 时代的老操作
EXEC dbms_refresh.refresh('MV_TEST');
5.2 到 KES 这一步，很多人会直接懵
- 没有这个包
- 刷新方式变了
- 行为更直白，但也更“硬”
5.3 正确的刷新方式
REFRESH MATERIALIZED VIEW mv_test;
⚠️ 注意两个现实限制：
- 当前只支持完全刷新
- 大表刷新，资源消耗非常明显
5.4 我最后的处理策略
- 放弃“准实时刷新”的执念
- 改为业务低谷批量刷新
- 大 MV 拆分或重构逻辑
这一步不改，上线周期一定被拖死。
六、一些不致命，但会反复折磨你的细节
6.1 触发器里的 NEW / OLD
❌ Oracle 写法：
:new.create_time := sysdate;
✔ KES 写法：
NEW.create_time := current_timestamp;
6.2 函数返回类型别偷懒
Oracle：
RETURN VARCHAR2
KES：
RETURN VARCHAR
这种问题，不会立刻炸，但迟早会炸。
七、性能问题：不是“迁过来就完了”
7.1 函数索引这个小细节
Oracle：
CREATE INDEX idx_name ON t(upper(name));
KES：
CREATE INDEX idx_name ON t((upper(name)));
少一层括号，索引可能直接不生效。
7.2 查询写法的一个建议
Oracle 时代的“模糊写法”，
在 KES 里尽量少用。
👉 越明确，执行计划越可控。
八、迁移到最后，我反复验证的三个结论
1️⃣ 兼容模式不是护身符
2️⃣ 所有隐式行为，都该被显式化
3️⃣ 能跑，离上线还差很远
九、如果你现在正卡在这些问题上
- PL/SQL 各种奇怪报错
- JSON 行为对不上
- 物化视图刷新慢到怀疑人生
- Oracle 老代码一动就炸
别慌，这不是你一个人的问题。
我个人很建议多看看 电科金仓官方技术社区：
🔗 https://kingbase.com.cn/explore
很多坑，其实已经有人替你踩过。
结语：国产数据库迁移，真正考验的是工程能力
这次 Oracle → 电科金仓的迁移，对我最大的价值不是“数据库换了”，而是：
终于被迫把那些靠 Oracle 隐式兜底的代码，一次性理顺了。
迁移不是终点，更像一次系统级的“技术体检”。
如果这篇文章能让你少熬一个夜、少翻几次日志，那它就算没白写。
浙公网安备 33010602011771号