大家好我是数据库小学妹 前段时间一家制造企业找到我们要把跑了七年的Oracle系统迁到国产数据库。我接了评估报告一看心里没底。数据类型对不上存储过程全要改数据还不能丢。这是硬仗。今天我把这次迁移踩过的坑、趟出来的路原原本本写下来。朋友如果你也在做异构数据库迁移这篇或许能帮你少走弯路。为什么说异构迁移最难的不是数据而是习惯很多人觉得迁移就是导数据。其实数据导出导入反而是最简单的。真正难的是应用层的适配。Oracle用了一千多个存储过程两百多个触发器几十个定时任务。这些代码里藏着大量Oracle特有的语法。换库不改代码直接报错。我做迁移的第一步不是导数据而是做应用兼容性评估。把每一段PL/SQL拆开看逐行标记不兼容的地方。评估维度Oracle特性迁移难度备注存储过程PACKAGE/PROCEDURE/FUNCTION★★★★语法差异大逐行改写同义词/DBLINKSYNONYM/DBLINK★★★目标库可能不支持数据类型NUMBER/CLOB/NCLOB/BLOB★★☆需目标库逐一对应序列/自增SEQUENCE★★☆可替换为AUTO_INCREMENT异常处理EXCEPTION WHEN★★☆语法不同逻辑可迁移触发器TRIGGER★★☆语法差异逻辑迁移评估完我才知道这次迁移的工作量比预期大了三倍。数据类型映射从NUMBER到VARCHAR2逐一对照Oracle和MySQL以及兼容MySQL的国产数据库在数据类型上的差异比我想象的大。NUMBER类型。Oracle的NUMBER可以表示整数、小数、浮点数一个类型通吃。到了MySQL要拆开看。整数用BIGINT或INT。带小数的用DECIMAL(M,D)。我一开始图省事把NUMBER全转成DECIMAL(20,6)。上线后发现索引效率掉了不少。原因很简单DECIMAL是字符串存储索引查找比整数慢。该用BIGINT的地方必须用BIGINT。正确的映射方式是这样的-- Oracle 源端CREATETABLEorders(order_id NUMBER(19),-- 订单号amount NUMBER(12,2),-- 金额quantity NUMBER(10),-- 数量statusNUMBER(2)-- 状态码);-- MySQL/国产数据库 目标端CREATETABLEorders(order_idBIGINT,-- 订单号19位整数amountDECIMAL(12,2),-- 金额保留2位小数quantityINT,-- 数量10位整数足够statusTINYINT-- 状态码2位用TINYINT);VARCHAR2的坑。Oracle的VARCHAR2默认按字节计算长度。VARCHAR2(10)能存10个英文字母但存中文可能只能存3个。转到UTF-8编码的目标库要按字符重新计算。我的做法是先查源端最大实际长度再乘以3UTF-8最大字节数最后向上取整到标准值。DATE和TIMESTAMP。Oracle的DATE包含时分秒相当于MySQL的DATETIME。这个好办。但Oracle的TIMESTAMP(6)带6位微秒精度目标库如果只支持秒级精度毫秒数据就丢了。我搞错过一次。把一个TIMESTAMP(6)的字段直接转成了DATETIME上线后客户反馈时间戳对不上。排查半天才发现是微秒截断导致的。CLOB和TEXT。Oracle的CLOB能存4GB文本。MySQL的TEXT也够大。但CLOB的读写方式不同。Oracle用DBMS_LOB包操作MySQL直接当字符串处理。这意味着所有读写CLOB的代码都要改。-- Oracle 读写CLOBDECLAREv_clob CLOB;BEGINSELECTcontentINTOv_clobFROMarticlesWHEREid1;DBMS_LOB.APPEND(v_clob,追加内容);UPDATEarticlesSETcontentv_clobWHEREid1;END;-- 迁移后MySQL/国产数据库UPDATEarticlesSETcontentCONCAT(content,追加内容)WHEREid1;存储过程改写PL/SQL到标准SQL的翻译过程这是迁移工作量最大的部分。我把改写的规则整理成了一张表Oracle语法改写方式难度PACKAGE拆分存储过程函数去掉包体★★★CONNECT BY递归替换为WITH RECURSIVE★★★EXCEPTION WHEN改用DECLARE … HANDLER★★☆SYS_REFCURSOR改为游标或直接查询返回★★☆DUAL表去掉FROM DUAL★☆☆DECODE()替换为CASE WHEN★☆☆NVL()替换为IFNULL()或COALESCE()★☆☆SYSDATE替换为NOW()★☆☆ROWNUM替换为LIMIT★☆☆实际改写时最难的是带PACKAGE的复杂存储过程。一个包体里有几十个过程和函数互相调用层层嵌套。我的做法是先理清调用关系画出依赖图然后逐个拆解。把PACKAGE拆成独立的存储过程去掉包级别的变量改为参数传递。来看一个实际例子-- Oracle 原始包定义CREATEORREPLACEPACKAGE pkg_orderASPROCEDUREcreate_order(p_customer_idINNUMBER,p_product_idINNUMBER,p_quantityINNUMBER,p_order_idOUTNUMBER);FUNCTIONget_order_status(p_order_idINNUMBER)RETURNVARCHAR2;ENDpkg_order;-- Oracle 包体CREATEORREPLACEPACKAGE BODY pkg_orderASg_seq_counter NUMBER :0;-- 包级变量PROCEDUREcreate_order(p_customer_idINNUMBER,p_product_idINNUMBER,p_quantityINNUMBER,p_order_idOUTNUMBER)ISv_stock NUMBER;BEGIN-- 检查库存SELECTstockINTOv_stockFROMinventoryWHEREproduct_idp_product_id;IFv_stockp_quantityTHENRAISE_APPLICATION_ERROR(-20001,库存不足);ENDIF;-- 生成订单g_seq_counter :g_seq_counter1;p_order_id :TO_NUMBER(TO_CHAR(SYSDATE,YYYYMMDD)||LPAD(g_seq_counter,6,0));INSERTINTOorders(order_id,customer_id,product_id,quantity,create_time)VALUES(p_order_id,p_customer_id,p_product_id,p_quantity,SYSDATE);UPDATEinventorySETstockstock-p_quantityWHEREproduct_idp_product_id;COMMIT;EXCEPTIONWHENNO_DATA_FOUNDTHENRAISE_APPLICATION_ERROR(-20002,产品不存在);WHENOTHERSTHENROLLBACK;RAISE;ENDcreate_order;FUNCTIONget_order_status(p_order_idINNUMBER)RETURNVARCHAR2ISv_status VARCHAR2(20);BEGINSELECTstatus_nameINTOv_statusFROMorder_statusWHEREorder_idp_order_id;RETURNv_status;EXCEPTIONWHENNO_DATA_FOUNDTHENRETURN未知;ENDget_order_status;ENDpkg_order;改写后的版本去掉了包体把两个过程拆成独立单元。包级变量改为自增列加时间戳组合。异常处理改为HANDLER。RAISE_APPLICATION_ERROR改为SIGNAL-- 迁移后拆分为独立存储过程DELIMITER//-- 订单创建过程CREATEPROCEDUREsp_create_order(INp_customer_idBIGINT,INp_product_idBIGINT,INp_quantityINT,OUTp_order_idBIGINT)BEGINDECLAREv_stockINT;DECLAREv_existsINTDEFAULT0;-- 声明异常处理器替代Oracle的EXCEPTIONDECLAREEXITHANDLERFORSQLEXCEPTIONBEGINROLLBACK;SIGNAL SQLSTATE45000SETMESSAGE_TEXT订单创建失败;END;STARTTRANSACTION;-- 检查产品是否存在SELECTCOUNT(*)INTOv_existsFROMinventoryWHEREproduct_idp_product_idFORUPDATE;IFv_exists0THENROLLBACK;SIGNAL SQLSTATE45000SETMESSAGE_TEXT产品不存在;ENDIF;-- 检查库存SELECTstockINTOv_stockFROMinventoryWHEREproduct_idp_product_id;IFv_stockp_quantityTHENROLLBACK;SIGNAL SQLSTATE45000SETMESSAGE_TEXT库存不足;ENDIF;-- 生成订单号日期自增IDINSERTINTOorders(customer_id,product_id,quantity,create_time)VALUES(p_customer_id,p_product_id,p_quantity,NOW());SETp_order_idLAST_INSERT_ID();-- 扣减库存UPDATEinventorySETstockstock-p_quantityWHEREproduct_idp_product_id;COMMIT;END//-- 订单状态查询函数CREATEFUNCTIONfn_get_order_status(p_order_idBIGINT)RETURNSVARCHAR(20)DETERMINISTICREADSSQLDATABEGINDECLAREv_statusVARCHAR(20);SELECTstatus_nameINTOv_statusFROMorder_statusWHEREorder_idp_order_id;RETURNIFNULL(v_status,未知);END//DELIMITER;CONNECT BY递归查询的改写。这是另一个重灾区。Oracle用CONNECT BY做树形查询目标库要用WITH RECURSIVE替代。-- Oracle 部门层级查询SELECTdepartment_id,department_name,parent_id,LEVELFROMdepartmentsSTARTWITHparent_idISNULLCONNECTBYPRIOR department_idparent_id;-- 迁移后WITH RECURSIVE递归CTEWITHRECURSIVE dept_treeAS(-- 锚点根节点SELECTdepartment_id,department_name,parent_id,1ASlevelFROMdepartmentsWHEREparent_idISNULLUNIONALL-- 递归子节点SELECTd.department_id,d.department_name,d.parent_id,dt.level1FROMdepartments dINNERJOINdept_tree dtONd.parent_iddt.department_id)SELECT*FROMdept_tree;迁移验证数据对了才算完改完代码只是第一步。真正的考验是数据验证。我做了三层校验。第一层行数对比。源端和目标端每张表的行数必须一致。用脚本批量比对-- 批量生成行数校验SQLSELECTCONCAT(SELECT ,table_name, AS tbl, COUNT(*) AS cnt FROM ,table_name, UNION ALL)FROMinformation_schema.tablesWHEREtable_schemayour_databaseORDERBYtable_name;第二层抽样比对。随机抽取每条表的100行数据逐字段对比。重点关注NUMBER转DECIMAL后的精度、日期转DATETIME后的时分秒。第三层业务校验。用核心业务SQL在两端分别执行比对结果。比如订单汇总金额、客户余额、库存总数。这些数字对不上说明迁移有问题。实际迁移时第三层校验帮我发现了一个隐藏问题。Oracle的NVL和MySQL的IFNULL在空字符串处理上行为不同。Oracle把空字符串当NULLMySQL不这么认为。这导致一个汇总查询的结果差了几十万。迁移避坑清单别低估字符集转换的影响。Oracle源端如果是WE8MSWIN1252编码转到UTF-8时中文可能乱码。迁移前一定要先确认两端的字符集和排序规则。我做迁移时吃过这个亏导完数据才发现中文变成了问号。Oracle的空字符串等于NULL别忘记这个陷阱。这是Oracle和其他数据库最大的差异之一。VARCHAR2(10) 在Oracle里等同于IS NULL。迁移后如果目标库不这么处理所有涉及空字符串判断的逻辑都要改。我搞错过一次上线后花了半天才定位到这个问题。存储过程里的隐式类型转换要逐一排查。Oracle的隐式类型转换比MySQL宽松得多。NUMBER和VARCHAR互相转换在Oracle里能自动完成在目标库可能直接报错。迁移时要把所有隐式转换显式化用CAST函数明确指定类型。对了迁移过程中我还了解到金仓数据库有专门的Oracle兼容模式。他们的异构数据同步软件Kingbase FlySync简称KFS在Oracle迁移场景下提供了自动化迁移工具能自动识别不兼容的PL/SQL语法并给出改写建议。这对大规模迁移来说确实能节省不少前期评估时间。不过工具归工具最终还是要逐行验证。自动化只是辅助不是替代。迁移总结异构数据库迁移不是简单的导数据。它是应用代码的翻译、数据类型的映射、业务逻辑的校验三位一体。我的建议是先做兼容性评估再制定数据类型映射规则然后逐段改写存储过程最后做三层数据校验。顺序不能乱。迁移完成后至少并行运行两周。两端同时接单比对结果。稳定后再切流量。朋友你在数据库迁移过程中遇到过什么坑是数据类型对不上还是存储过程改不完欢迎在评论区聊聊。我是数据库小学妹咱们下篇见