从 Oracle 到金仓：一次真实迁移经历的复盘与思考-程序员充电站

从 Oracle 到金仓：一次真实迁移经历的复盘与思考

这几年信创的推进力度越来越大，不少企业都在搞数据库国产化替代。从我接触过的项目来看，最“费脑子”的往往不是怎么建库、怎么配置，而是怎么把原来稳稳运行的 Oracle 系统，平稳地挪到金仓这种国产数据库上。过程看似简单，真干起来才知道里面有多少坑。

下面这篇，就是我根据一些典型项目做的梳理，希望能给准备迁移的同学一点参考，至少别再重复我们踩过的那些“历史错误”。

一、OCI 连接不上，到底卡在哪？

大多数迁移项目的第一步，就是把应用的连接从 Oracle 换到金仓。很多团队一开始都很乐观，以为改个 JDBC URL 就行，但现实通常会给你当头一棒。

一个真实案例：TNS 超时，但网络根本没问题

某家金融机构的系统，在迁移测试第一天就被“ORA-12170: TNS 连接超时”搞懵了。
运维先查网络，发现四通八达；DBA再查监听，也都在跑。后来大家才意识到：问题根本不是连不连得上，而是说话的语言不对。

金仓默认使用 PostgreSQL 协议，而 Oracle 用的是 TNS。这俩的握手方式、数据包格式都对不上号，客户端自然听不懂服务端在说什么。

-- Oracle 示例(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.100)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=orcl)))-- 金仓示例host=192.168.1.100port=54321dbname=testuser=system password=123456

这就好比你用英语去跟一个只会说日语的人聊天，双方都急也没用。

KOCI：金仓给的沟通翻译器

为解决这个协议鸿沟，金仓提供了一个叫KOCI的兼容层，用来接收 Oracle 的 TNS 消息并转为金仓能识别的格式。

// Oracle JDBCClass.forName("oracle.jdbc.driver.OracleDriver");DriverManager.getConnection("jdbc:oracle:thin:@//192.168.1.100:1521/orcl","system","password");// 金仓 JDBCClass.forName("com.kingbase8.Driver");DriverManager.getConnection("jdbc:kingbase8:oci://192.168.1.100:54321/test","system","123456");

不过项目里遇到的问题远不止于此。有些 Oracle 客户端会启用特定加密算法，而金仓要能处理，就必须在配置中同步开启：

ALTERSYSTEMSETssl=on;ALTERSYSTEMSETtns_ssl_mode='prefer';

迁移初期这一块要重点检查，不然浪费的排查时间会非常多。

二、PL/SQL：真正的“硬骨头”

如果说连接协议不兼容还能靠工具解决，那 PL/SQL 就完全要靠一点点“啃”了。Oracle 的 PL/SQL 功能太丰富，写法又灵活，迁移时最容易出现语法级和语义级的双重差异。

存储过程：简单复制 ≠ 能用

有个 ERP 系统，整库超过 5000 多个过程和函数。迁移初期，团队把代码往金仓里一贴，结果立即报错一片。

比如 Oracle 里很常见的写法：

DECLARETYPEEmpRecISRECORD(emp_id employees.employee_id%TYPE,emp_name employees.last_name%TYPE,salary employees.salary%TYPE);v_emp EmpRec;BEGINSELECTemployee_id,last_name,salaryINTOv_empFROMemployeesWHEREemployee_id=100;DBMS_OUTPUT.PUT_LINE('员工姓名: '||v_emp.emp_name);EXCEPTIONWHENNO_DATA_FOUNDTHENDBMS_OUTPUT.PUT_LINE('未找到该员工');END;

迁到金仓，就必须做语法调整：

DO$$DECLAREv_emp RECORD;BEGINSELECTemployee_id,last_name,salaryINTOv_empFROMemployeesWHEREemployee_id=100;RAISE NOTICE'员工姓名: %',v_emp.last_name;EXCEPTIONWHENNO_DATA_FOUNDTHENRAISE NOTICE'未找到该员工';END$$;

看似细节，但当你面对几千条代码时，这种差异真的能让人头皮发麻。

批量处理：FORALL 没了怎么办？

Oracle 的 BULK COLLECT + FORALL 是性能利器，但金仓没有对应语法，需要换思路：

-- OracleFORALL iIN1..v_ids.COUNTUPDATEsalariesSETbonus=bonus*1.1WHEREemployee_id=v_ids(i);-- 金仓UPDATEsalariesSETbonus=bonus*1.1WHEREemployee_id=ANY(v_ids);

好处是：写法更简单，但迁移代码时需要重新审视原逻辑。

三、JSON 的细微差异：名称相似但用法不完全一样

JSON 使用越来越多，Oracle 和金仓名字看起来很像，但语法不完全一样。

-- OracleJSON_VALUE(customer_data,'$.name')-- 金仓jsonb_extract_path_text(customer_data::jsonb,'name')

金仓也提供 json_value，但有时使用上仍需调整。

而 Oracle 的 JSON_TABLE 在金仓里更是需要完全重写：

-- 金仓的替代方式SELECT(item->>'id')::VARCHAR,(item->>'quantity')::NUMERIC,(item->>'price')::NUMERICFROMorders o,jsonb_array_elements(o.order_items::jsonb)itemWHEREo.order_id=1001;

四、怎么控制迁移成本？工具是关键

如果想让迁移更可控，金仓的 KDTS 和 KFS 这两个工具非常有必要上手。

KDTS：结构+数据一条龙

配置好之后能直接把 Oracle 的 schema、表结构、数据迁过去。

sources:-dbType:oracledbVersion:19cschemas:HR,SALEStable-includes:"orders.*,customers.*"

迁完之后仔细做数据校验，是必须的流程。

KFS：解决“停机难”的增量同步

适用于对停机特别敏感的系统。

SELECTsubscription_name,apply_lag,write_lagFROMsys_stat_subscription;

您能看到同步延迟，方便判断能不能切流量。

五、迁移完成只是开始，优化才是长期战

迁移之后需要做性能基线、慢 SQL 排查、索引分析等一系列动作。

SELECTquery,calls,mean_timeFROMsys_stat_statementsWHEREmean_time>1000ORDERBYtotal_timeDESC;

金仓也提供 index_recommendation 这样的工具，能给出索引建议，让应用更快适配新的数据库。

六、经验总结：这些点请务必提前规划

迁移前

做兼容性评估
优先迁非核心系统
构建完整测试环境

迁移中

分阶段推进
每次迁移后都做一致性校验
做压力对比测试

迁移后

建立监控
定期优化
团队知识转移要跟上

结语

从 Oracle 迁到金仓，说实话，没人能拍着胸脯说这活容易。它需要耐心、细致，甚至需要一点点“工匠精神”。
但把这些工作走一遍，你的团队对 Oracle 和金仓都会理解得更深，对数据库本身的掌控能力也会大幅提升。

如果你现在正在计划这类迁移，金仓官网的技术资料确实值得一看，很多文档都比较实用，不是那种走过场的内容。

希望这篇复盘能让你少走点弯路，也希望你的迁移之路能更顺畅一些。

从 Oracle 到金仓：一次真实迁移经历的复盘与思考