DB2迁移到国产数据库怎么做？SQL改写、对象兼容与数据迁移全流程实操指南

📌今日关键词：DB2迁移、DB2迁移到国产数据库、DB2存储过程改写、DB2数据迁移工具、信创替代、金仓KES

大家好，我是数据库小学妹 👋

前阵子一个DBA朋友找我倒苦水：公司DB2的年度维保续费单下来了，价格看得他血压飙升。跑了快十五年的系统，License费年年涨，硬件还绑着IBM小型机，每年运维成本够买好几台x86。

正好赶上信创推进，领导拍板：年内换成国产库。

他问我一句话："DB2那十几万行存储过程，迁到别的库能直接跑吗？"我说这得看你怎么定义"直接跑"了。

后来我专门研究了一下DB2迁移这件事，发现坑比想象中多。存储过程的SQL PL语法和主流数据库差别不小，自增字段机制完全不一样，GRAPHIC这种DB2特有的数据类型也得处理。今天把梳理的结果分享出来，从"为什么迁"到"怎么迁"，遇到的坑和应对办法一起讲。

一、DB2为什么要迁

DB2本身是个好数据库，在金融、电信、制造业的核心系统里跑了二三十年，稳定是真稳定。但现在要迁的原因也很明确。

信创政策是头号驱动力。金融、能源、电信、政务这些行业，关键基础设施的数据库被要求逐步替换为国产数据库。DB2作为IBM的商业数据库，自然在替换名单上。

成本是第二个原因。DB2的License费用不低，加上绑定IBM小型机（AIX/Power），硬件维护也是一笔开支。很多企业上了年纪的DB2系统，每年运维成本比迁移成本还高。

第三个原因是技术生态。DB2在云原生和容器化方面的支持相对滞后，微服务架构下扩展不方便。很多新业务模块没法高效集成。

说白了，不是DB2不好，是整个技术环境变了。

二、DB2迁国产数据库，这几个点必须提前想清楚

DB2迁国产库，不是导个脚本跑一遍就完事的。有几个地方如果不提前处理，后面全是坑。

先摸家底。 迁移前第一件事是盘点源库对象。表有多少张，存储过程多少个，自增字段有多少，哪些表用了GRAPHIC类型，哪些依赖MQT做查询加速。这些数量直接决定工期和人力。几十张表和几千张表，完全是两个量级的事。单表数据量也得看——几十亿行的大表和几百万行的小表，迁移策略完全不同。

存储过程是工作量最大的部分。 DB2用SQL PL写存储过程，和国产库主流的PL/SQL差别不小。变量声明位置、赋值语法、游标结束判断、异常捕获机制，几乎每个环节都不一样。十几万行存储过程逐个改写，这是DB2迁移里投入人力最多的环节，没法跳过，也没法自动全搞定。

自增字段得重新设计。 DB2的GENERATED ALWAYS AS IDENTITY不允许手动插ID值，和国产库的SEQUENCE机制完全两条路。迁过去得改成SEQUENCE加触发器，数据迁移时还得用特殊参数把历史ID灌进去，否则序列起始值和已有数据冲突，新插入的记录ID就乱了。

数据类型别想当然。 DB2有些类型在国产库里没对标的——GRAPHIC和VARGRAPHIC是DB2特有的双字节定长字符类型，存中文数据的表不少用它。迁过去得转成NVARCHAR2，还得验证字符集有没有对齐，光比行数不够。DECFLOAT浮点精度也得单独验证。

MQT和报表逻辑得重建。 DB2靠MQT（物化查询表）做性能优化，很多复杂报表查询全靠它加速。国产库里没有完全对等的东西，得改成物化视图，刷新策略也得重新设计。这块容易被忽略，上线后才发现报表变慢就晚了。

别漏了边角对象。 DBLink联邦查询、Event Monitor、特定的隔离级别提示（WITH UR），用到的企业不多，但碰上了不处理就报错。

与其靠人肉盘，不如拿迁移评估工具扫一遍源库。像金仓的KDMS就能自动扫描DB2源库里所有对象——表、存储过程、函数、视图、触发器、序列，一份兼容性报告出来，哪些能直接搬、哪些要改、哪些得重建，一目了然。有制造业项目用KDMS扫完，发现大量兼容性问题，工具自动翻译转换率达95%以上。先评估再动手，比干到一半才发现问题强太多了。

三、DB2迁移的技术难点

对象盘点完，就该面对真正的硬骨头了。DB2迁移到国产数据库，核心思路是把SQL PL改写为目标库能跑的PL/SQL。以KES为例，它在Oracle兼容模式下原生支持PL/SQL语法，DB2的存储过程逻辑可以平移过来，不需要从头重写。难点主要在以下几个地方。

3.1 存储过程改写：DB2 SQL PL → PL/SQL

这是DB2迁移中投入人力最多的环节。DB2的存储过程用SQL PL编写，语法和Oracle的PL/SQL有明显差异。

⭐变量声明和赋值：

— DB2 SQL PL
CREATE PROCEDURE get_order_total(IN p_order_id INT)
BEGIN
DECLARE v_total DECIMAL(12,2);
DECLARE v_status VARCHAR(20) DEFAULT 'active';

SET v_total = 0;

SELECT SUM(amount) INTO v_total
FROM order_items
WHERE order_id = p_order_id
AND status = v_status;

CALL DBMS_OUTPUT.PUT_LINE('Total: ' || CAST(v_total AS VARCHAR(20)));
END@

— KES（Oracle兼容模式）
CREATE OR REPLACE PROCEDURE get_order_total(
p_order_id IN NUMBER)
AS
v_total NUMBER(12,2);
v_status VARCHAR2(20) := 'active';
BEGIN
v_total := 0;

SELECT SUM(amount) INTO v_total
FROM order_items
WHERE order_id = p_order_id
AND status = v_status;

DBMS_OUTPUT.PUT_LINE('Total: ' || TO_CHAR(v_total));
END;

主要差异点：

• DB2用BEGIN…END@结尾（@是语句终止符），KES用BEGIN…END;
• DB2的DECLARE在BEGIN之后，KES的变量声明在AS和BEGIN之间
• DB2用DEFAULT赋默认值，KES用:=
• DB2用CAST做类型转换，KES用TO_CHAR/TO_NUMBER
• DB2的DECIMAL在KES中改为NUMBER
• DB2的VARCHAR在KES中改为VARCHAR2

⭐游标和循环：

— DB2 SQL PL游标
DECLARE cur_orders CURSOR FOR
SELECT id, amount FROM orders WHERE status = 'pending';

OPEN cur_orders;
LOOP
FETCH cur_orders INTO v_id, v_amount;
IF SQLCODE = 100 THEN LEAVE; END IF;
— 处理逻辑
END LOOP;
CLOSE cur_orders;

— KES游标（Oracle兼容模式）
CURSOR cur_orders IS
SELECT id, amount FROM orders WHERE status = 'pending';

OPEN cur_orders;
LOOP
FETCH cur_orders INTO v_id, v_amount;
EXIT WHEN cur_orders%NOTFOUND;
— 处理逻辑
END LOOP;
CLOSE cur_orders;

DB2用SQLCODE = 100判断游标结束，KES用%NOTFOUND。DB2的游标在BEGIN块内DECLARE，KES在AS块内声明。

3.2 自增字段和序列映射

DB2的自增字段有两种模式：

— DB2自增字段
CREATE TABLE orders (
id INTEGER GENERATED ALWAYS AS IDENTITY
(START WITH 1, INCREMENT BY 1),
amount DECIMAL(10,2)
);

GENERATED ALWAYS不允许手动插入ID值，GENERATED BY DEFAULT允许但不推荐。已迁移到KES为例，需要用SEQUENCE替代：

— KES改造方案
CREATE SEQUENCE orders_seq START WITH 1 INCREMENT BY 1;

CREATE TABLE orders (
id NUMBER PRIMARY KEY,
amount NUMBER(10,2)
);

— 用触发器自动填充
CREATE OR REPLACE TRIGGER orders_bi
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
IF :NEW.id IS NULL THEN
:NEW.id := orders_seq.NEXTVAL;
END IF;
END;

数据迁移时还需要处理自增序列的当前值，确保迁移后不会和已有数据冲突。用LOAD命令加modified by identityoverride参数可以强制覆盖目标表的自增序列。

3.3 数据类型映射

DB2有一些独特的数据类型需要处理：

• GRAPHIC和VARGRAPHIC是DB2特有的双字节定长字符类型，主要用于存储中文等CJK字符。迁移到KES时需要转为NVARCHAR2，并验证字符集是否对齐。
• DECFLOAT（十进制浮点）建议先评估应用中是否用到DECFLOAT特有的舍入和精度逻辑，若涉及严格十进制运算，需在KES中验证NUMBER类型能否完全替代。

3.4 SQL语法差异

除了存储过程，普通SQL也有差异：

🚩分页查询：

— DB2分页（FETCH FIRST）
SELECT * FROM orders
ORDER BY id
FETCH FIRST 20 ROWS ONLY;

— DB2分页（ROW_NUMBER）
SELECT * FROM (
SELECT ROW_NUMBER() OVER(ORDER BY id) AS rn, t.*
FROM orders t
) WHERE rn BETWEEN 21 AND 40;

— KES分页（Oracle兼容）
SELECT * FROM orders
ORDER BY id
OFFSET 20 ROWS FETCH NEXT 20 ROWS ONLY;

🚩合并操作：

— DB2的MERGE INTO
MERGE INTO target t
USING source s
ON t.id = s.id
WHEN MATCHED THEN UPDATE SET t.val = s.val
WHEN NOT MATCHED THEN INSERT (id, val) VALUES (s.id, s.val);

— KES语法基本一致，Oracle兼容模式原生支持MERGE

DB2的MERGE INTO语法和Oracle/KES基本兼容，这块改动不大。但DB2特有的OPTIMIZE FOR n ROWS、WITH UR（脏读隔离级别）这些需要逐个处理。

四、DB2数据迁移：全量+增量双通道

对象改完之后，数据怎么搬？

4.1 全量迁移

DB2自带的导出工具可以配合使用：

• db2look 导出表结构DDL
• db2move 导出数据（IXF格式）
• export 按表导出（DEL/IXF格式）

小体量数据（几十GB以内）用db2move导出后在目标库导入就行。大体量数据建议用专业迁移工具，支持多线程并行读写，效率高得多。

通过迁移工具KDTS，可以把DB2的结构和数据一起搬过去。DB2的DDL里有不少需要特殊处理的对象——存储过程的SQL PL语法要转PL/SQL，GENERATED ALWAYS AS IDENTITY要映射为SEQUENCE，这些转换如果靠手写，几百张表能写到怀疑人生。KDTS能配合完成DDL转换，再从DB2并行导出数据批量灌入目标库，存储过程、视图、触发器等逻辑对象在KDMS完成评估和翻译后，由KDTS一并迁移。小体量数据可以直接用db2move导出IXF格式再导入，几十GB以上建议上迁移工具的并行通道，效率差得不是一点半点。

全量跑完之后，数据校验不能省。用数据比对工具KDC自动逐表比对源端DB2和目标端KES的数据一致性，比人工抽查靠谱。

4.2 增量同步和双轨并行

核心系统没法停机迁移，得上双轨并行。

DB2的增量同步走的是DB2日志捕获路线，和PostgreSQL基于WAL的机制完全不同。通过金仓异构数据同步软件（Kingbase FlySync，简称KFS）从DB2事务日志里实时抓取数据变更，同步到目标库。有个省运营商资源中心的项目，日均数据增量4.5TB，KFS做到了秒级同步延迟。双轨期间两个库同时跑，业务侧无感知，但DBA得盯住一件事：GENERATED ALWAYS的自增字段在目标库走的是SEQUENCE，双写阶段两边的ID生成逻辑不同，得确保不会冲突。

数据校验也是DB2迁移里容易翻车的环节。DB2的GRAPHIC类型转到NVARCHAR2后，字符存储宽度可能有细微差异，光比行数不够，得逐字段校验核心表的关键数据。KDC可以自动化完成源端和目标端的数据比对，不用一条条人工对。

4.3 灰度切换

DB2系统普遍跑了十几年，周边依赖比你想象的多——ETL任务、报表系统、对接的上游应用，都绑着DB2。切换时得把这些一起考虑进去。业内把这套打法叫"三低一平"——低难度、低风险、低成本，加上平滑迁移。工具自动处理大部分改造，双轨并行兜底风险，灰度切换控制节奏，业务侧基本无感。

建议的切法是：先把报表和查询类的读流量引到新库，写请求继续走DB2。这个阶段重点观察新库的SQL执行计划和存储过程表现，DB2特有的WITH UR脏读逻辑在新库里得改成正确的隔离级别。跑稳了再按业务模块逐个切写流量，每切一个模块就做一轮数据校验。全部切完进入观察期，DB2先别关，留着当回滚后路。观察个两三周没问题，再正式下线。

五、真实迁移场景

场景一：金融行业核心系统替换

以某金融核心系统迁移为例，数百个存储过程需要从DB2的SQL PL改写为PL/SQL，自增字段需映射为SEQUENCE+TRIGGER。迁移团队先用KDMS扫描，量化出兼容性差异，大部分DDL转换由KDTS配合KDMS自动完成。双轨并行期间每天跑数据校验，SQL PL特有的WITH UR脏读逻辑逐个改掉。最终灰度切换完成，核心交易性能持平，信创审计一次通过。

场景二：制造业ERP系统迁移

在制造业ERP系统从DB2迁移过程中，典型挑战包括：MQT（物化查询表）需改造为物化视图并重新设计刷新策略；GRAPHIC类型字段需转为NVARCHAR2并验证字符集对齐；双轨并行期间需每日校验数据一致性。迁移完成后运维成本通常可显著降低。

场景三：电信行业计费系统

电信计费系统数据量大、并发高、对一致性要求严苛。迁移时可采用KDMS评估 + KDTS全量迁移 + KFS增量同步的全链路方案。通过双轨并行保持业务连续，切换后系统可用性可达99.999%，故障切换时间可控制在30秒以内。

六、迁移避坑清单

总结

DB2迁移说到底就三件事：搞清楚要改什么，选对工具搬数据，别一步到位直接切。

先评估。有多少存储过程要改、多少自增字段要映射、多少DB2特有类型要处理，量化出来再排工期，比直接开干靠谱得多。

再迁移。自动化工具能搞定大部分结构转换和数据搬迁，但SQL PL到PL/SQL的改写还是得有经验的DBA上。增量同步保持双库一致，灰度策略平滑切流。

以KES为例，整条链路的工具都配齐了：KDMS做迁移评估，自动扫描DB2源库的对象和兼容性问题；KDTS负责结构迁移和全量数据搬迁，DDL转换、并行导出、断点续传一站搞定；KFS从DB2事务日志实时抓变更做增量同步，支撑双轨并行；KDC自动比对源端和目标端数据一致性，不用人工一条条对。这套工具链配合KES的Oracle兼容模式，SQL PL改写成PL/SQL后直接跑，覆盖评估、改造、迁移、同步、校验全流程。业内管这叫"三低一平"——低难度、低风险、低成本、平滑迁移。

金融、制造、能源、电信这些行业都有从Oracle、MySQL、PostgreSQL迁到KES的落地案例，DB2迁移虽在具体细节上有所差异，但其**“三低一平”迁移方法论和工具链是通用的，可有效支撑DB2迁移项目。

大家的系统有DB2要迁吗？遇到最头疼的问题是什么？评论区聊聊。

我是数据库小学妹，咱们下篇见 👋