国产数据库迁移技术规范是信创改造里技术密度最高的部分。从Oracle、SQL Server迁到达梦、人大金仓、高斯，不是把数据导过去就行，SQL语法、数据类型、存储过程、事务隔离级都有差异。按照结构迁移、对象改写、数据搬迁、双写校验四个阶段推进，才能把风险压到最低，避免上线后业务数据对不上才紧急回退。

一、结构迁移与数据类型映射

字段类型对照

每张表都要做类型映射。Oracle的NUMBER对应国产库的数值类型，VARCHAR2要注意长度单位是字节还是字符，CLOB、BLOB要确认国产库大字段限制。常见坑是默认日期时间精度不一致，迁完发现秒级数据丢了，财务对账时才暴露，返工代价极大。

主键、索引、约束、分区策略要一并迁移，不要只搬表结构。索引漏迁的话，迁完系统必慢，因为所有查询都走全表扫描，现场加索引又会锁表，非常被动。

对象依赖梳理

视图、触发器、序列、同义词都要列出清单，逐个评估改造难度。存储过程数量大的系统，建议先用迁移评估工具扫描一遍，生成改造工作量报告，再据此排期。很多项目前期低估存储过程改造量，排期只留两周，实际改了两个月。

二、SQL与存储过程改写

方言差异处理

分页写法、字符串函数、日期函数在不同数据库里不一样。原系统里写死的SQL要逐条扫描改写，应用层尽量换成标准JDBC写法。建议把高频慢SQL挑出来单独优化，不要等迁完再统一调，那时业务已经跑在新库上，优化窗口很难找。

除了SQL语句，JDBC驱动、连接字符串、事务隔离级别也要逐一核对。有些国产数据库默认隔离级别与原库不同，迁完可能出现脏读或幻读，业务逻辑要相应调整测试用例。

存储过程重写

存储过程是硬骨头。Oracle的PL/SQL语法、异常处理、动态SQL在国产库里写法不同，要逐段迁移并配回归测试。复杂业务逻辑如果重写成本太高，可以考虑在新库里用存储过程包一层兼容接口，把调用方改动降到最小。

三、数据搬迁与双写切换

全量加增量

搬迁分两步：切换前全量导出导入，切换窗口内追增量日志。大表分片搬，避免锁表。千万级以上的表还要提前重建统计信息，否则迁完查询计划走歪，性能掉一半，业务部门一用就投诉。

搬迁过程中要记录每张表的行数和校验和，作为切换当晚对账依据。导完先比对总行数，行数对不上就不用往下走，直接查原因；行数对上再抽关键字段比对，最后跑业务汇总报表做交叉验证。

双写校验

正式切换前安排一段时间双写：业务同时写新旧两库，批量比对两边数据。行数、关键字段、汇总金额三层校验，差异率达标后再切读流量。切流也要灰度，先切查询、后切写入，出问题时影响面小。

四、迁移后性能基线

迁完要做一轮性能压测，和原系统建立基线对比。慢查询加索引，连接池参数按国产数据库官方建议调整。不少企业反映迁完慢，其实不是国产库不行，而是统计信息没收集、索引没重建，优化器拿着错误的统计信息选了烂执行计划。

压测还要覆盖备份恢复。迁移后第一次全量备份要实际跑一遍，恢复时间是否在窗口内、日志归档是否正常，都要记录。平时没人演练恢复，真出问题时才发现备份脚本早就坏了，是最惨痛的教训，也是很多项目验收后才暴露的隐患。

数据库迁移是系统工程，不是一次性导数据。建议保定企业保留旧库只读运行一个月，新库稳定满月后再正式退役。按结构、对象、数据、校验四步走，迁移基本都能做到数据零差异、业务无感切换。

迁移期间还要安排专人盯业务侧反馈。新库上线第一周，每天抽一小时和业务部门对齐使用感受，慢查询、报表差异、权限问题统一收集、分批修复。两周后问题量自然下降，系统也就真正坐稳了，运维团队再按季度做巡检和性能回顾即可，形成长期稳定的运行节奏，避免新库上线后又慢慢退化。