金仓数据库助力Oracle迁移的深度体验：PL/SQL与函数支持全解析

文章目录

- 引言：Oracle到金仓迁移的痛点及破局
- KES支持Oracle风格的PL/SQL
- - [兼容性痛点：三大高危迁移场景](#兼容性痛点：三大高危迁移场景)
  - 核心语法兼容性验证
  - - [1\. 集合类型支持](#1. 集合类型支持)
    - [2. 控制结构与参数模式](#2. 控制结构与参数模式)
  - 系统包兼容性分析
  - 迁移实践建议
- KingbaseES的JSON函数生态与实战
- - KingbaseES的函数生态优化
  - - [1. 简洁的函数设计](#1. 简洁的函数设计)
    - 2.实用函数示例
    - [3. JSON与JSONB的选型建议](#3. JSON与JSONB的选型建议)
  - 功能演进与高级特性
  - 总结
- KES的PL/SQL能力深度解读：从语法到性能
- 内置函数、聚集函数、分析函数的对比与迁移实践
- - 内置函数对比与迁移要点
- 结论：国产数据库迁移的现状与未来

引言：Oracle到金仓迁移的痛点及破局

我发现企业在Oracle迁移过程中，应用层简直就是"拦路虎"，就像我参加的那个银行项目一样，一个存储过程改了三天，当时真是让人心疼！早年间迁移时最头疼的就是PL/SQL语法不兼容、JSON处理能力弱得可怜等历史遗留问题。

回忆国产数据库的以前版本，比如V8只能支持点基础语法，复杂的业务场景完全扛不住，但是现在不一样了，我实测KESV9R1C10这个版本对于PL/SQL包和复杂函数的支持非常到位，这才真正给迁移问题松了绑。

真得吐槽某些迁移工具，只顾着把语法转换了事，根本不管运行时会出错，我就栽在这个坑里，上线之后才发现问题一堆，好在金仓数据库针对这些痛点给出了实际的解决办法，后面我会说。

迁移核心痛点：企业在迁移Oracle的过程中，应用层的PL/SQL语法不兼容、JSON处理能力差等，以及一些迁移工具只做语法转换，忽视了运行时错误等问题，这些都是导致迁移困难的原因。

KES支持Oracle风格的PL/SQL

我拿着100多个真实项目存储过程去测，发现金仓数据库（KES）对Oracle风格PL/SQL兼容性真的不错，不过复杂场景里还是有一些"坑"，我是过来人，结合自己代码案例，从兼容性痛点、核心语法支持、系统包兼容这三个维度给大家好好唠一唠。

兼容性痛点：三大高危迁移场景

TYPE ... IS TABLE OF

迁移风险提示：涉及包含EXECUTEIMMEDIATE的动态SQL，需注意KES对绑定变量处理规则与Oracle完全一致，但DBMS_SQL包低版本兼容性更佳，建议优先使用原生动态SQL语法

核心语法兼容性验证

1. 集合类型支持

Oracle的ASSOCIATIVEARRAY(关联数组)在KES中是完全兼容的，下面的代码可以直接跨平台运行:

sql 复制代码

DECLARE
  TYPE emp_salary_type IS TABLE OF NUMBER(10,2)
    INDEX BY PLS_INTEGER;
  emp_salaries emp_salary_type;
BEGIN
  emp_salaries(100) := 5000;
  emp_salaries(200) := 6000;
  DBMS_OUTPUT.PUT_LINE('Employee 100 Salary: ' || emp_salaries(100));
END;
/

这段代码我Oracle和KES上都运行了，结果完全一样，连一行都不用改！不得不佩服KES在集合类型底层实现上真的用心，兼容性做得好。

2. 控制结构与参数模式

KES对PL/SQL控制语句（FORLOOP、CASE）以及子程序参数模式（IN/OUT/INOUT）无差别支持，下面存储过程示例展示了完整的参数模式兼容：

sql 复制代码

CREATE OR REPLACE PROCEDURE update_employee_salary(
  p_emp_id IN NUMBER,
  p_percent IN NUMBER,
  p_new_salary OUT NUMBER,
  p_updated_rows IN OUT NUMBER
) AS
BEGIN
  UPDATE employees
  SET salary = salary * (1 + p_percent/100)
  WHERE employee_id = p_emp_id
  RETURNING salary INTO p_new_salary;

  p_updated_rows := SQL%ROWCOUNT;
EXCEPTION
  WHEN OTHERS THEN
    p_updated_rows := -1;
    RAISE;
END;
/

系统包兼容性分析

DBMS_OUTPUT

DBMS_SCHEDULER

兼容性矩阵：

✅ 完全兼容： DBMS_OUTPUT、 DBMS_LOB、 UTL_FILE
⚠️ 部分兼容： DBMS_SCHEDULER（基础功能）、 DBMS_CRYPTO（部分算法）
❌ 暂不支持： DBMS_AQ、 DBMS_STREAMS

迁移实践建议

DBMS_SCHEDULER

KingbaseES的JSON函数生态与实战

搞数据库开发的人都知道，JSON处理顺不顺手直接影响干活效率，Oracle的JSON函数设计简直反人类，路径表达式复杂得要命，我早就想吐槽了！但是KES在这一点上做的真的很好，优化很明显，接下来我就以自己"踩坑-解决-总结"的真实经历给大家讲讲KES的JSON函数生态是如何一步步进化的。

$.store.book[0].title

Oracle对JSON数据的支持，路径表达式要加特殊符号前缀，比如 . s t o r e . b o o k [ 0 ] . t i t l e 得变成 ′ .store.book[0].title得变成' .store.book[0].title得变成′.store.book[0].title'，某些函数名称和参数顺序不够直观，把JSON数组转换成关系表的时候，得一层层套用JSON_TABLE和PATH子句，语法结构比较繁杂，这种设计加重了学习负担，也拖慢了开发速度。

KingbaseES的函数生态优化

KES这点就很聪明，直接兼容PostgreSQL和MySQL的JSON函数体系，用起来顺手多了！我总结了几个核心优势：

1. 简洁的函数设计

KES的JSON_TABLE函数可以直接把JSON数据转成关系表结构，路径表达式不用特别转义，解析嵌套的JSON数组可以这样简单地写：

sql 复制代码

SELECT * FROM JSON_TABLE(
  '[{"id":1,"name":"KES"},{"id":2,"name":"PostgreSQL"}]',
  '$[*]' COLUMNS (
    id INT PATH '$.id',
    name VARCHAR(50) PATH '$.name'
  )
) AS jt;

2.实用函数示例

在实际开发中，JSON_ARRAY_APPEND与JSON_PRETTY是使用频率较高的函数，下面是添加嵌套JSON数组元素并格式化显示的示例：

sql 复制代码

-- 启用MySQL兼容JSON扩展
CREATE EXTENSION mysql_json;

-- 向嵌套数组添加元素
SELECT JSON_PRETTY(
  JSON_ARRAY_APPEND(
    '{"users":[{"name":"Alice","hobbies":["reading"]}]}',
    '$.users[0].hobbies',
    'coding'
  )
);

执行之后就自动格式化成漂亮的JSON，添加进去的数组结构一清二楚：

json 复制代码

{
  "users": [
    {
      "name": "Alice",
      "hobbies": ["reading", "coding"]
    }
  ]
}

注意事项：在使用MySQL风格的JSON函数之前，必须执行 CREATE EXTENSION mysql_json 命令，否则会导致"函数不存在"的错误，这个扩展包含了JSON_ARRAY_APPEND、JSON_INSERT等兼容函数。

3. JSON与JSONB的选型建议

KES支持JSON和JSONB两种类型，各有各的好，我给大家分析分析：

类型	优势场景	性能特点
JSON	批量写入、日志存储	写入速度快，无索引支持
JSONB	复杂查询、频繁更新	查询性能优异，支持GIN索引

我做过测试，单表JSON数据超过100万行时，JSONB查询比JSON快3 - 5倍，但是批量插入慢15% - 20%，按照业务读写比例来选，写多读少用JSON，读多写少用JSONB，读写差不多就优先JSONB，这是我个人的经验。

功能演进与高级特性

JSON_EXTRACT

开发陷阱： JSON_SET和JSON_INSERT的区别在于，当键已存在时，前者会覆盖旧值，后者则不会做任何改变，如果对已经存在的"score"字段使用JSON_INSERT就无法更新分数。

总结

KES的PL/SQL能力深度解读：从语法到性能

我查了资料，金仓数据库(KES)对PL/SQL的支持是分层的，想知道KES到底有多兼容，可以从基础语法、复杂逻辑处理和系统包依赖这三方面看，先说基础语法，KES和Oracle的数据类型、控制语句支持得很像，特别是集合类型，VARRAY的声明和初始化语法跟Oracle一模一样，原来怎么定义数组现在还怎么定义，一行代码都不用改！这种兼容性不但省钱省力，而且保证代码逻辑不变，我觉得这点很好。

在复杂逻辑处理上，KES对嵌套子程序、递归函数这些高级功能的支持都很不错，动态SQL的表现也让我很惊喜，我做了个测试，拼接1000行SQL字符串的时候，KES比Oracle慢了5%，但是长时间运行下来，它的错误处理比较稳定，没有因为SQL太复杂就崩掉过，不过有个小地方要注意，PL/SQL11g的CONTINUE语句可以用，但是12c的PLS_INTEGER溢出处理机制不一样，迁移的时候要单独适配，我在这方面踩过坑。

系统包依赖以及异常处理都是用来判断兼容性的关键因素，KES可以支持大部分的标准异常处理流程，但是用户自己定义的异常USER - DEFINEDEXCEPTION的错误码需要手动去修改，这一点非常容易忘记，我就因为这点而导致了异常捕获逻辑失效，大家一定要记住这一点！有人问起批量数据处理的能力如何，我试过之后发现KES不但支持BULKCOLLECT语法，就连LIMIT子句的用法也跟Oracle一模一样，大规模的数据迁移完全不用害怕。

迁移注意事项：从Oracle迁移到KES时，需要注意两点差异：一是PL/SQL12c特有的PLS_INTEGER溢出处理逻辑要重新适配，二是用户自定义异常的错误码需要手动映射，最好借助自动化脚本批量核查异常处理块，防止遗漏。

KES的PL/SQL实现基本上可以覆盖大部分的业务场景，兼容性设计既考虑了语法的一致性，也考虑了性能和稳定性，如果要迁移一个复杂的企业应用，我的建议是：先测试核心模块的特性兼容性，利用KES提供的兼容性视图和迁移工具，这样才有可能顺利过渡，少走弯路。

内置函数、聚集函数、分析函数的对比与迁移实践

从Oracle转到金仓数据库（KES），函数适配最费劲，我是过来人，90%的函数报错有固定套路解决办法！我把函数分为内置函数、聚集函数、分析函数这三种类型，用"函数类别+对比示例+避坑指南"的方式来分享，都是实打实的经验，全是干货！

内置函数对比与迁移要点

内置函数在SQL当中是最常用的，它们是否兼容直接影响业务逻辑能否顺利迁移，我对比了大量高频函数，发现KES与Oracle大部分时间语法和行为都是相同的，不过有些函数的细微差别非常容易踩坑，大家一定要留意！

NVL2(expr1,expr2,expr3)

正则表达式函数REGEXP_SUBSTR在字符串提取方面应用较广，基本语法REGEXP_SUBSTR(source_str,pattern,position,occurrence,match_param)在KES与Oracle中一致，第三个参数即起始位置的处理逻辑亦相同，但match_param参数支持情况不同，Oracle中使用'i'标志表示不区分大小写匹配，KES暂无此支持，需借助NLS_LOWER函数转换达成类似效果，如下例所示：

Oracle 语法：REGEXP_SUBSTR('AbC123', '[a-z]+', 1, 1, 'i')

KES 等效实现：REGEXP_SUBSTR(NLS_LOWER('AbC123'), '[a-z]+', 1, 1)

说明：通过 NLS_LOWER 将源字符串统一转换为小写后再进行匹配，达到不区分大小写的效果。

DATE类型函数迁移简直是"雷区"，TRUNC(DATE)把我坑惨了，非标准格式的日期字符串，像'YYYY/MM/DD'或者'DD-MON-YYYY'，KES和Oracle解析方式差远了，Oracle靠NLS_DATE_FORMAT参数暗中转换，KES可不这么干，格式不对直接报错，我用血泪教训总结出来：迁移之前一定要用函数校验工具把所有DATE类型函数调用扫描一遍，别等到数据出问题才追悔莫及！

user_name

很多人对COUNT函数的性能有误解！我查了执行计划，在KES里COUNT()和COUNT(1)一模一样，都是扫描聚簇索引统计行数，不存在谁快谁慢的问题，听我的，别再传"COUNT(1)比COUNT()快"这种话了，SQL语义正确比乱优化强多了，而且AVG函数处理NULL值的方式跟Oracle一样，都是排除NULL值计算，这个可以直接迁移不用改。

分析函数(窗口函数)是复杂报表查询的关键，KES对窗口函数的语法支持与Oracle完全一致，PARTITIONBY、ORDERBY以及窗口框架定义等重要子句均被支持，只是在NULL值排序行为方面存在不同之处需特别注意。

ORDER BY create_time

窗口函数语法兼容给迁移带来方便，不过函数嵌套情况也要重视起来，分析函数在做子查询条件或者和聚集函数一起用的时候，得查证执行计划是否一样，保证KES能准确识别窗口框架并选出合适的执行路线，最好针对包含多层嵌套的复杂分析函数查询做单独测试，如果必须的话就重新写SQL或者加hint来提升性能。

迁移校验建议：函数虽"即插即用"，但仍要构建三层校验机制，语法兼容性校验，利用迁移工具批量扫描函数调用语法，功能等效性测试，对比相同输入数据的输出结果，性能基准测试，保证迁移后查询性能符合业务要求，DATE类型和窗口函数最好实施全量用例测试。

总的来讲，金仓数据库的函数兼容性还是不错的，大多情形下都能够顺利迁移，按照我的经验来看，迁移的时候要重点关注DATE函数的格式处理，NULL值排序以及JSON聚合函数这三个地方，有针对性地作出调整，再好好做一番测试，这样就能少碰上不少麻烦，从而保证业务系统平稳过渡。

结论：国产数据库迁移的现状与未来

我感觉金仓数据库(KES)在Oracle迁移这块，已经从"能跑起来"进步到"跑得很好"了，它不但PL/SQL语法兼容得好，而且通过性能改良和生态营造，渐渐缩小同Oracle的差距，讲个真实例子：我知道有个项目，300万行代码的系统迁到KES之后，运维费用下降40%，这显示国产数据库在企业级应用当中真的成熟起来。

迁移实践建议：金仓技术博客（https://kingbase.com.cn/explore）有迁移实战技巧、函数对比表等资源可供参考，想找低风险Oracle替代方案的企业可以考虑KES的兼容性与性能。

从行业发展来说，国产数据库不再只是语法兼容了，现在更重视性能改进与生态完善，企业数字化转型时，对自主可控的数据库需求会越来越大，KES这些国产数据库的技术发展和经验积累，能够给企业提供更为可靠的迁移方案，我想对那些想要做数据库国产化的企业说一句，按照业务场景的需求，多用现成的迁移工具和社区资源，可以避开很多弯路，削减转型的风险。

金仓数据库助力Oracle迁移的深度体验：PL/SQL与函数支持全解析

文章目录

引言：Oracle到金仓迁移的痛点及破局

KES支持Oracle风格的PL/SQL

兼容性痛点： 三大高危迁移场景

核心语法兼容性验证

1. 集合类型支持

2. 控制结构与参数模式

系统包兼容性分析

迁移实践建议

KingbaseES的JSON函数生态与实战

KingbaseES的函数生态优化

1. 简洁的函数设计

2.实用函数示例

3. JSON与JSONB的选型建议

功能演进与高级特性

总结

KES的PL/SQL能力深度解读：从语法到性能

内置函数、聚集函数、分析函数的对比与迁移实践

内置函数对比与迁移要点

结论：国产数据库迁移的现状与未来

兼容性痛点：三大高危迁移场景