告别兼容焦虑：电科金仓 KES 如何把 Oracle 的 PL/SQL 和 JSON 业务“接住”

告别兼容焦虑：电科金仓 KES 如何把 Oracle 的 PL/SQL 和 JSON 业务“接住”

真正做过 Oracle 迁移的人都知道，最怕的不是数据量大，而是业务逻辑压在数据库里动不了。在多个项目里实践下来，电科金仓 KingbaseES（KES）在 PL/SQL 兼容和 JSON 处理这两点上，确实帮我省下了不少时间。

一、写在前面：迁移时，最先被问到的三个问题

在信创项目里，只要提到“Oracle 替换”，几乎都会被连续追问三件事：

• 现有存储过程要不要全部重写？
• 那些年堆出来的 PL/SQL 能不能跑？
• 现在大量用 JSON 的地方，性能会不会崩？

这些问题如果答不好，迁移方案基本就很难往下走。

从实际项目经验来看，电科金仓 KES 给到的答案是：能跑、少改、风险可控。下面我就围绕 PL/SQL 和 JSON 这两块，结合实际使用情况，展开说说它到底解决了什么问题。

二、PL/SQL：决定迁移成本的“分水岭”

2.1 为什么 PL/SQL 才是真正的难点

很多系统嘴上说是“Java 应用”，但真正复杂的规则，其实都在数据库里：

• 核心结算逻辑写在存储过程中
• 校验、补偿、统计放在触发器里
• 各种历史遗留包，没人敢动

如果迁移数据库意味着推倒重来，那项目大概率会直接流产。

KES 在这一点上的策略很明确：尽量按 Oracle 的方式来，而不是强迫业务迁就新数据库。

2.2 实际体验：多数存储过程可以直接过

下面这个过程，来自我在项目里常见的一类写法，逻辑不复杂，但细节很多：

CREATEORREPLACEPROCEDUREcalculate_bonus(p_emp_idINNUMBER,p_bonusOUTNUMBER)ASv_salary NUMBER;v_performance_rating NUMBER;BEGINv_performance_rating :=0;SELECTsalaryINTOv_salaryFROMemployeesWHEREemp_id=p_emp_id;IFv_salary>10000THENSELECTperformance_score*0.15INTOv_performance_ratingFROMperformance_reviewsWHEREemp_id=p_emp_idANDreview_year=EXTRACT(YEARFROMSYSDATE)-1;ELSESELECTperformance_score*0.10INTOv_performance_ratingFROMperformance_reviewsWHEREemp_id=p_emp_idANDreview_year=EXTRACT(YEARFROMSYSDATE)-1;ENDIF;p_bonus :=v_salary*GREATEST(v_performance_rating,0.05);EXCEPTIONWHENNO_DATA_FOUNDTHENp_bonus :=v_salary*0.05;WHENOTHERSTHENRAISE_APPLICATION_ERROR(-20001,'计算奖金时发生错误: '||SQLERRM);END;

在 KES 环境下，这类代码几乎不需要调整。
变量声明、异常处理、内置函数、控制结构，基本都能对齐 Oracle 行为。

👉这点非常关键：
迁移不是“语法能不能写”，而是“历史代码能不能活”。

2.3 游标、%TYPE、%ROWTYPE这些老朋友还在

很多老系统严重依赖游标，尤其是按行处理逻辑。KES 对这块支持得比较完整：

DECLARECURSORemp_cursorISSELECTemp_id,emp_name,salary,department_idFROMemployeesWHEREhire_date>DATE'2020-01-01'ORDERBYsalaryDESC;v_emp_record emp_cursor%ROWTYPE;v_department_name departments.department_name%TYPE;BEGINOPENemp_cursor;LOOPFETCHemp_cursorINTOv_emp_record;EXITWHENemp_cursor%NOTFOUND;SELECTdepartment_nameINTOv_department_nameFROMdepartmentsWHEREdepartment_id=v_emp_record.department_id;DBMS_OUTPUT.PUT_LINE('员工: '||v_emp_record.emp_name||', 部门: '||v_department_name||', 薪资: '||v_emp_record.salary);ENDLOOP;CLOSEemp_cursor;END;

这一类写法如果不能兼容，迁移基本没法推进。
好在 KES 在这里并没有“另起炉灶”。

2.4 内置包不是摆设，是真的能用

DBMS_OUTPUT、DBMS_SQL、DBMS_LOB这些包，在调试和历史逻辑里非常常见。

BEGINDBMS_OUTPUT.ENABLE(1000000);FORiIN1..5LOOPDBMS_OUTPUT.PUT_LINE('循环次数: '||i);DBMS_OUTPUT.PUT_LINE('当前时间: '||TO_CHAR(DBMS_UTILITY.GET_TIME,'YYYY-MM-DD HH24:MI:SS'));ENDLOOP;END;

从可用性角度讲，不是“名字一样”就行，而是行为要接近，这一点 KES 做得相对稳。

三、函数与分析能力：不是“能跑”，而是“够用”

3.1 日常函数支持情况

字符串、日期、数值这些基础函数，不展开吹，直接看用起来顺不顺：

SELECTLOWER('Hello World'),ADD_MONTHS(SYSDATE,3),MONTHS_BETWEEN(SYSDATE,DATE'2023-01-01')FROMdual;

这类语句在迁移中属于“最不想碰的”，KES 基本不会给你添堵。

3.2 分析函数：迁移后最容易被低估的能力

不少系统其实非常依赖窗口函数，比如排名、同比、滚动统计。

SELECTemp_id,department_id,salary,RANK()OVER(PARTITIONBYdepartment_idORDERBYsalaryDESC),ROW_NUMBER()OVER(PARTITIONBYdepartment_idORDERBYsalaryDESC)FROMemployees;

KES 对这类语法支持完整，这一点对报表系统、统计系统尤为重要。

四、JSON：不是“支持”，而是“能不能放心用”

4.1 JSON 和 JSONB，别选错

KES 提供 JSON / JSONB 两种类型，本质和 PostgreSQL 类似：

• JSON：保留原始文本
• JSONB：二进制存储，查询更快

如果是业务字段频繁查询，我个人建议直接 JSONB，不要犹豫。

4.2 常见 JSON 场景实战

建表、写入、查询这几个动作，决定了你能不能在生产环境用得住。

CREATETABLEproducts(idSERIALPRIMARYKEY,product_info JSONB,created_atTIMESTAMPDEFAULTCURRENT_TIMESTAMP);

SELECTproduct_info->>'name',product_info->'specs'->>'brand'FROMproductsWHERE(product_info->>'in_stock')::boolean=true;

语法不花哨，但胜在稳定、清晰、可维护。

4.3 JSON 更新和索引，性能差距就在这

如果 JSON 查询慢，九成问题出在索引上：

CREATEINDEXidx_products_infoONproductsUSINGGIN(product_info);CREATEINDEXidx_products_brandONproducts((product_info->'specs'->>'brand'));

这一步不做，JSON 用得越多，锅背得越狠。

五、迁移中绕不开的几个现实问题

5.1CONNECT BY怎么办？

老方案不用扔，递归 CTE 就能解决：

WITHRECURSIVE org_hierarchyAS(SELECT1ASlevel,employee_id,manager_idFROMemployeesWHEREmanager_idISNULLUNIONALLSELECToh.level+1,e.employee_id,e.manager_idFROMemployees eJOINorg_hierarchy ohONe.manager_id=oh.employee_id)SELECT*FROMorg_hierarchy;

5.2 MERGE 语句？

这一点反而轻松，KES 是直接支持的，不用改写。

六、一些个人判断（不是宣传话术）

从实际迁移经验看，我对电科金仓 KES 的评价很简单：

• PL/SQL 是真的想帮你接住历史包袱
• JSON 能用，而且用得住
• 迁移风险可控，不靠赌运气

数据库迁移从来不是技术炫技，而是能不能让系统平稳落地。

在当前信创背景下，KES 至少在“Oracle 平替”这条路上，走得比较务实。

七、结语

如果你正在评估国产数据库替代 Oracle，我的建议是：

不要只看 PPT，一定要跑一轮真实业务代码。

从 PL/SQL 到 JSON，从老逻辑到新需求，KES 给出的不是完美答案，但确实是一个现实可落地的选择。

迁移这件事，本就不该追求“零成本”，而是追求可控、可回退、可持续。
在这一点上，电科金仓 KES，至少没有让人失望。