📌今日关键词：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 PLCREATEPROCEDUREget_order_total(INp_order_idINT)BEGINDECLAREv_totalDECIMAL(12,2);DECLAREv_statusVARCHAR(20)DEFAULT'active';SETv_total=0;SELECTSUM(amount)INTOv_totalFROMorder_itemsWHEREorder_id=p_order_idANDstatus=v_status;CALLDBMS_OUTPUT.PUT_LINE('Total: '||CAST(v_totalASVARCHAR(20)));END@-- KES（Oracle兼容模式）CREATEORREPLACEPROCEDUREget_order_total(p_order_idINNUMBER)ASv_total NUMBER(12,2);v_status VARCHAR2(20):='active';BEGINv_total :=0;SELECTSUM(amount)INTOv_totalFROMorder_itemsWHEREorder_id=p_order_idANDstatus=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游标DECLAREcur_ordersCURSORFORSELECTid,amountFROMordersWHEREstatus='pending';OPENcur_orders;LOOPFETCHcur_ordersINTOv_id,v_amount;IFSQLCODE=100THENLEAVE;ENDIF;-- 处理逻辑ENDLOOP;CLOSEcur_orders;-- KES游标（Oracle兼容模式）CURSORcur_ordersISSELECTid,amountFROMordersWHEREstatus='pending';OPENcur_orders;LOOPFETCHcur_ordersINTOv_id,v_amount;EXITWHENcur_orders%NOTFOUND;-- 处理逻辑ENDLOOP;CLOSEcur_orders;DB2用SQLCODE = 100判断游标结束，KES用%NOTFOUND。DB2的游标在BEGIN块内DECLARE，KES在AS块内声明。
3.2 自增字段和序列映射
DB2的自增字段有两种模式：
-- DB2自增字段CREATETABLEorders(idINTEGERGENERATED ALWAYSASIDENTITY(STARTWITH1,INCREMENTBY1),amountDECIMAL(10,2));GENERATED ALWAYS不允许手动插入ID值，GENERATED BY DEFAULT允许但不推荐。已迁移到KES为例，需要用SEQUENCE替代：
-- KES改造方案CREATESEQUENCE orders_seqSTARTWITH1INCREMENTBY1;CREATETABLEorders(id NUMBERPRIMARYKEY,amount NUMBER(10,2));-- 用触发器自动填充CREATEORREPLACETRIGGERorders_bi BEFOREINSERTONordersFOR EACH ROWBEGINIF:NEW.idISNULLTHEN:NEW.id :=orders_seq.NEXTVAL;ENDIF;END;数据迁移时还需要处理自增序列的当前值，确保迁移后不会和已有数据冲突。用LOAD命令加modified by identityoverride参数可以强制覆盖目标表的自增序列。
3.3 数据类型映射
DB2有一些独特的数据类型需要处理：
| DB2类型 | KES映射 | 注意事项 |
|---|---|---|
| DECIMAL/NUMERIC | NUMBER | 精度和小数位保持一致 |
| VARCHAR(n) | VARCHAR2(n) | 字符集注意UTF-8对齐 |
| CLOB | CLOB | 基本兼容 |
| BLOB | BLOB | 基本兼容 |
| GRAPHIC/VARGRAPHIC | NVARCHAR2 | DB2特有的双字节字符类型 |
| DECFLOAT | NUMBER | 浮点精度需验证 |
| TIMESTAMP WITH TIME ZONE | TIMESTAMP WITH TIME ZONE | 时区处理逻辑需测试 |
| ROWID | ROWID | 基本兼容 |
- GRAPHIC和VARGRAPHIC是DB2特有的双字节定长字符类型，主要用于存储中文等CJK字符。迁移到KES时需要转为NVARCHAR2，并验证字符集是否对齐。
- DECFLOAT（十进制浮点）建议先评估应用中是否用到DECFLOAT特有的舍入和精度逻辑，若涉及严格十进制运算，需在KES中验证NUMBER类型能否完全替代。
3.4 SQL语法差异
除了存储过程，普通SQL也有差异：
🚩分页查询：
-- DB2分页（FETCH FIRST）SELECT*FROMordersORDERBYidFETCHFIRST20ROWSONLY;-- DB2分页（ROW_NUMBER）SELECT*FROM(SELECTROW_NUMBER()OVER(ORDERBYid)ASrn,t.*FROMorders t)WHERErnBETWEEN21AND40;-- KES分页（Oracle兼容）SELECT*FROMordersORDERBYidOFFSET20ROWSFETCHNEXT20ROWSONLY;🚩合并操作：
-- DB2的MERGE INTOMERGEINTOtarget tUSINGsource sONt.id=s.idWHENMATCHEDTHENUPDATESETt.val=s.valWHENNOTMATCHEDTHENINSERT(id,val)VALUES(s.id,s.val);-- KES语法基本一致，Oracle兼容模式原生支持MERGEDB2的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秒以内。
六、迁移避坑清单
| 序号 | 坑点 | 后果 | 正确做法 |
|---|---|---|---|
| 1 | 不做评估直接开迁 | 到处报错，工期失控 | 先用KDMS扫描源库，量化兼容性问题再排工期 |
| 2 | 存储过程照搬不改 | 语法不兼容，上线直接报错 | SQL PL逐个改写为PL/SQL，重点测游标和异常处理 |
| 3 | 自增字段没处理 | ID冲突或跳号 | 用SEQUENCE+TRIGGER替代，迁移时identityoverride |
| 4 | 忽略GRAPHIC类型 | 中文数据乱码 | GRAPHIC转NVARCHAR2，验证字符集对齐 |
| 5 | 一步到位直接切换 | 出问题没回退方案 | 双轨并行+灰度切换，保留DB2做回滚 |
| 6 | 不做数据校验 | 迁移后数据不一致 | 用KDC逐表自动比对源端和目标端数据一致性 |
| 7 | wait_timeout设太短 | 连接频繁断开重建 | 迁移期间适当调大超时时间 |
| 8 | 只迁数据不迁权限 | 迁完发现应用连不上 | 权限和角色同步迁移，提前配置 |
总结
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要迁吗？遇到最头疼的问题是什么？评论区聊聊。
我是数据库小学妹，咱们下篇见 👋
