从 Oracle 到金仓：一次真实数据库迁移的避坑实录

是 否 +2 论坛币

k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群

赵安豆老师微信：zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

立即领取

感谢您参与论坛问题回答

经管之家送您两个论坛币！

+2 论坛币

从 Oracle 到金仓：一次真实的数据库迁移避坑记录

近年来，信创替代进程不断加快，越来越多企业开始推进数据库的国产化转型。在各类迁移路径中，

Oracle → 金仓（KingbaseES）

是最常见但也最具挑战性的一条路线。

作为长期奋战在一线的数据库迁移工程师，我亲身经历过的项目问题远比写过的 SQL 多得多。本文不谈理论、不讲官方文档，只聚焦于实际场景中的典型故障、踩坑过程以及最终解决方案，希望能为正在或即将进行类似迁移的团队提供一些实用参考。

一、连接失败？别急着查网络

在多数迁移项目的初期阶段，第一个拦路虎往往是：

应用无法连接到金仓数据库

日志中最常见的报错信息是：

ORA-12170: TNS 连接超时

大多数人的第一反应是排查网络连通性、防火墙策略和端口状态。但实际上，这类问题绝大多数并非出在网络层面，而是通信协议不兼容所致。

1. 实际案例还原

某金融系统原运行于 Oracle 19c 环境，迁移后应用启动即报连接异常。经确认，IP 可 ping 通，54321 端口开放，但 JDBC 始终无法建立连接。

对比两种数据库的连接配置即可发现问题所在：

-- Oracle 标准连接格式
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.100)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=orcl)))

-- 金仓标准连接格式
host=192.168.1.100 port=54321 dbname=test user=system password=123456

核心差异在于：

Oracle 使用 TNS 协议，而金仓基于 PostgreSQL 协议栈实现。

当使用 Oracle 客户端向金仓发送 TNS 请求时，后者无法解析该协议，自然导致连接中断。

2. 正确应对方案：启用 KOCI 兼容模式

为解决协议差异，金仓提供了 KOCI 兼容层，用于模拟 Oracle 的 OCI 行为，实现协议“翻译”功能。

以下是不同连接方式的对比示例：

// 原 Oracle JDBC 连接
Class.forName("oracle.jdbc.driver.OracleDriver");
Connection conn = DriverManager.getConnection(
"jdbc:oracle:thin:@//192.168.1.100:1521/orcl",
"system",
"password"
);

// 金仓标准 JDBC 模式
Class.forName("com.kingbase8.Driver");
Connection conn = DriverManager.getConnection(
"jdbc:kingbase8://192.168.1.100:54321/test",
"system",
"123456"
);

// 金仓 OCI 兼容模式（关键）
Class.forName("com.kingbase8.Driver");
Connection conn = DriverManager.getConnection(
"jdbc:kingbase8:oci://192.168.1.100:54321/test",
"system",
"123456"
);

很多项目之所以长时间卡在连接环节，正是由于忽略了这一层协议转换机制，导致反复排查无效。

3. 加密配置易被忽视

另一个隐藏风险点是客户端加密策略。部分 Oracle 客户端默认启用特定 SSL 或压缩设置，若金仓未做对应配置，会直接拒绝连接，且错误提示极为模糊：

仅显示“连接失败”，无具体原因。

建议在金仓侧提前开启相关安全选项：

-- 启用 SSL 支持
ALTER SYSTEM SET ssl = on;
ALTER SYSTEM SET ssl_cert_file = '/path/to/server.crt';
ALTER SYSTEM SET ssl_key_file = '/path/to/server.key';

-- 兼容 Oracle 的 TNS 加密模式
ALTER SYSTEM SET tns_ssl_mode = 'prefer';

[此处为图片1]

二、PL/SQL 迁移：真正的难点集中区

如果说连接问题是“前菜”，那么 PL/SQL 的迁移才是真正考验技术深度的“主菜”。

1. 存储过程不可盲目复制

曾参与一个 ERP 系统迁移项目，其中包含超过 5000 个存储过程。初期团队采取了简单粗暴的方式：“先全量导入，再逐个修复”。结果导致：

错误日志刷屏，单日修复效率不足 50 个。

例如以下 Oracle 中常见的 RECORD 类型定义：

DECLARE
TYPE EmpRec IS RECORD (
    emp_id employees.employee_id%TYPE,
    emp_name employees.last_name%TYPE,
    salary employees.salary%TYPE
);
v_emp EmpRec;
BEGIN
SELECT employee_id, last_name, salary
INTO v_emp
FROM employees

此类语法在金仓中并不完全支持，需重构为临时表、自定义类型或拆分为多个变量处理。

大量 Oracle 特有结构如：%ROWTYPE、REF CURSOR、BULK COLLECT、SAVE EXCEPTIONS 等，在金仓中要么不支持，要么行为存在差异，必须逐一评估并重写。

更复杂的是触发器与自治事务的交互逻辑，稍有不慎就会引发数据一致性问题。

因此，PL/SQL 迁移绝非简单的语法替换，而是一次深度的代码重构过程，必须结合业务逻辑逐项分析。

在进行数据库迁移时，从 Oracle 迁移到金仓（Kingbase）的过程中，很多语法和执行逻辑存在差异。若不加以调整，极易引发性能下降或功能异常。以下是几个关键点的对比与优化建议。

一、PL/SQL 块结构及异常处理机制的差异

Oracle 中常见的匿名块写法如下：

WHERE employee_id = 100;
DBMS_OUTPUT.PUT_LINE('员工姓名: ' || v_emp.emp_name);
EXCEPTION
WHEN NO_DATA_FOUND THEN
DBMS_OUTPUT.PUT_LINE('未找到该员工');
END;

[此处为图片1]

而在金仓中，必须改写为 PostgreSQL 风格的 DO 块，并使用 RAISE NOTICE 替代输出语句。正确写法应为：

DO $$
DECLARE
v_emp RECORD;
BEGIN
SELECT employee_id, last_name, salary
INTO v_emp
FROM employees
WHERE employee_id = 100;
RAISE NOTICE '员工姓名: %', v_emp.last_name;
EXCEPTION
WHEN NO_DATA_FOUND THEN
RAISE NOTICE '未找到该员工';
END $$;

这不仅仅是语法层面的变化，更是整个过程控制模型的不同体现。

二、FORALL 与 BULK COLLECT 的性能替代方案

在 Oracle 中，批量操作常采用 BULK COLLECT 配合 FORALL 实现高效更新：

DECLARE
TYPE ID_TABLE IS TABLE OF NUMBER INDEX BY PLS_INTEGER;
v_ids ID_TABLE;
BEGIN
SELECT employee_id BULK COLLECT INTO v_ids
FROM employees
WHERE department_id = 50;
FORALL i IN 1..v_ids.COUNT
UPDATE salaries
SET bonus = bonus * 1.1
WHERE employee_id = v_ids(i);
COMMIT;
END;

[此处为图片2]

然而，在金仓中若仍采用逐条更新方式，性能将大幅下滑。正确的做法是利用集合操作实现一次性更新：

DO $$
DECLARE
v_ids INTEGER[];
BEGIN
SELECT ARRAY_AGG(employee_id) INTO v_ids
FROM employees
WHERE department_id = 50;
UPDATE salaries
SET bonus = bonus * 1.1
WHERE employee_id = ANY(v_ids);
COMMIT;
END $$;

这种“集合 + 一次性更新”的模式，是迁移过程中最容易被忽略但却对性能影响极大的环节之一。

三、JSON 函数的兼容性处理

当前业务系统广泛使用 JSON 字段，而 Oracle 与金仓在 JSON 处理函数上的写法有显著不同。

1. JSON_VALUE 的等效替换

Oracle 写法：

-- Oracle
SELECT
JSON_VALUE(customer_data, '$.name'),
JSON_VALUE(customer_data, '$.address.city')
FROM customers
WHERE JSON_EXISTS(customer_data, '$.orders[0]');

金仓标准写法需转换为 jsonb 类型并使用专用提取函数：

SELECT
jsonb_extract_path_text(customer_data::jsonb, 'name'),
jsonb_extract_path_text(customer_data::jsonb, 'address', 'city')
FROM customers
WHERE customer_data::jsonb ? 'orders';

若已启用兼容函数支持，则可保留原写法：

SELECT
json_value(customer_data, '$.name'),
json_value(customer_data, '$.address.city')
FROM customers
WHERE json_exists(customer_data, '$.orders[0]');

2. JSON_TABLE 的金仓等价实现

Oracle 使用 JSON_TABLE 解析数组结构：

SELECT jt.*
FROM orders o,
JSON_TABLE(o.order_items, '$[*]'
COLUMNS (
item_id VARCHAR2(100) PATH '$.id',
quantity NUMBER PATH '$.quantity',
price NUMBER PATH '$.price'
)
) jt
WHERE o.order_id = 1001;

在金仓中，应改为使用 jsonb_array_elements 展开数组，并通过路径访问元素：

SELECT
(item->>'id')::VARCHAR,
(item->>'quantity')::NUMERIC,
(item->>'price')::NUMERIC
FROM orders o,
jsonb_array_elements(o.order_items::jsonb) AS item
WHERE o.order_id = 1001;

四、如何有效降低迁移成本？

面对上述语法与执行模型的差异，降低迁移成本的关键在于：

• 识别核心差异点，如过程语言结构、批量处理机制、JSON 函数用法；
• 建立标准化转换规则库，统一代码重构流程；
• 优先采用金仓提供的兼容模式以减少初期改造量；
• 对性能敏感模块重点优化，避免照搬原有逻辑。

通过系统化分析与针对性调整，可在保障功能一致的前提下，最大限度地控制迁移风险与资源投入。

迁移的成本高低，关键并不在于数据库本身，而在于所采用的方法是否得当。

1. KDTS 自动迁移工具

在进行数据迁移前后，最基本的数据一致性校验可通过以下语句完成：

-- Oracle
SELECT COUNT(*), MIN(create_date), MAX(create_date) FROM orders;
-- 金仓
SELECT COUNT(*), MIN(create_date), MAX(create_date) FROM orders;

KDTS 工具的典型配置示例如下：

sources:
- dbType: oracle
  dbVersion: 19c
  url: jdbc:oracle:thin:@//192.168.1.100:1521/orcl
  username: system
  password: oracle123
  schemas: HR,SALES
target:
  dbType: KINGBASE
  dbVersion: V9
  url: jdbc:kingbase8://192.168.1.101:54321/migrated_db
  username: system
  password: kingbase123

[此处为图片1]

2. 实现零停机迁移：依赖 KFS 技术

通过订阅状态视图可实时监控延迟情况：

SELECT
  subscription_name,
  apply_lag,
  write_lag,
  flush_lag
FROM sys_stat_subscription;

为了确保数据一致，可执行并行对账操作：

WITH source_stats AS (
  SELECT COUNT(*) FROM orders@oracle_link
),
target_stats AS (
  SELECT COUNT(*) FROM orders
)
SELECT * FROM source_stats
UNION ALL
SELECT * FROM target_stats;

[此处为图片2]

五、迁移完成后才是真正挑战的开始

1. 建立性能基线

为后续性能对比提供参考依据，建议创建性能基线视图：

CREATE VIEW performance_baseline AS
SELECT COUNT(*) FROM sys_stat_activity WHERE state = 'active';

2. 慢 SQL 监控机制

及时发现影响系统响应的慢查询，使用如下查询定位耗时较高的SQL：

SELECT
  query,
  calls,
  total_time,
  mean_time
FROM sys_stat_statements
WHERE mean_time > 1000;

3. 索引使用情况分析

识别无效或未被使用的索引，优化存储与查询效率：

SELECT * FROM sys_stat_user_indexes
WHERE idx_scan = 0;

六、三条实战经验总结

? 迁移前准备阶段

• 务必执行兼容性扫描，提前识别潜在问题
• 优先选择非核心边缘系统进行试点迁移
• 搭建独立的压测环境，验证迁移后性能表现

? 迁移执行过程中

• 采取分批迁移策略，降低整体风险
• 多次反复校验数据，确保完整性与准确性
• 同步对比迁移前后的系统性能指标

? 迁移完成之后

• 实施长期运行监控，捕捉异常波动
• 定期开展性能调优工作
• 推动运维团队能力转型，适应新架构要求

写在最后

从 Oracle 向金仓的迁移，绝非简单的“一键切换”操作。它实质上是一场涵盖多维度的系统性工程，涉及：

• 技术栈的重构
• 运维体系的重建
• 团队能力的升级

然而，只要路径正确、节奏合理，一旦成功落地，便能实现：

• 成本可控
• 技术可控
• 风险可控

在当前的技术与政策环境下，这种自主可控的能力本身就具备极高的战略价值。

如果你正处于数据库迁移的过程中，或是即将启动此类项目，这条路是必然要走的。与其被动踩坑，不如主动规避，少走弯路。

扫码加我 拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

分享0 收藏0 回帖

关键词：Oracle 数据库 CLE ACL Subscription

相关内容：数据库迁移Oracle金仓