大家好我是小耶写功课只是为了我踩过的坑你们别再踩了数据库迁移这件事说起来不就是把数据从 A 搬到 B但真正干过的人都知道从评估到割接一步走错就是生产事故。我最近完整跑了一遍 Oracle 到金仓 KingbaseES 的迁移全流程用的是金仓自家的工具链——KDMS评估 KDTS迁移 KFS文件同步。今天把整个流程、每步踩的坑、以及最终校验结果一次讲透。一、迁移不是从导数据开始的而是从评估开始的很多人上来就建目标库、跑数据导入这是最大的误区。迁移的第一步一定是评估——你得先知道自己有多少东西迁不过去才能决定工期和风险。金仓的评估工具叫KDMSKingbase Database Migration Service它做的事情是连接源库扫描读取 Oracle 的 schema 信息包括表、视图、索引、约束、序列、存储过程、函数、触发器兼容性分析逐项比对源库对象与目标库KingbaseES的兼容程度生成评估报告输出一个清晰的清单——哪些 100% 兼容可以直接迁哪些需要语法改写哪些不支持需要重构评估报告里最关键的两项数据对象兼容率表结构、数据类型通常兼容率很高90%但存储过程和函数的兼容率可能骤降到 60%-70%取决于你源库里用了多少 Oracle 特有的包如 DBMS_OUTPUT、UTL_FILE、DBMS_JOB数据类型映射清单Oracle 的 NUMBER、VARCHAR2、DATE、BLOB 等类型如何映射到 KingbaseES 的对应类型。比如 Oracle 的 NUMBER(19,0) 对应 NUMBER 还是 BIGINTVARCHAR2(4000) 对应 VARCHAR(4000) 还是 TEXT这些细节在评估阶段就得确认踩坑提醒如果你的源库里用了 Oracle 特有的系统视图如 ALL_TABLES、DBA_USERS或者包如 DBMS_LOB、DBMS_RANDOM评估阶段一定要重点关注。这些在目标库里不一定有对应实现或者行为不完全一致。二、结构迁移DDL 先过去数据后走评估完成后KDMS 会自动生成目标库的 DDL 脚本你可以选择一键执行或手动审查后执行。这一步有几个常见的暗坑坑 1自增列的处理Oracle 12c 之前用 SEQUENCE TRIGGER 实现自增KingbaseES 支持 SERIAL 和 IDENTITY 两种语法。KDMS 会自动把 Oracle 的 SEQUENCE TRIGGER 转换成 IDENTITY但如果你的应用代码里写了SELECT seq.NEXTVAL改完后这段代码就废了。坑 2约束和索引的创建时机如果先建约束再导数据大表导数据时约束校验会很慢。建议流程是先建表结构 → 导入数据 → 再建索引和约束。KDTS 支持这个流程可以勾选数据迁移完成后再创建索引。坑 3字符集Oracle 的 AL32UTF8 和 KingbaseES 的 UTF8 看起来一样但某些生僻字符的编码行为不同。如果源库里有中文生僻字尤其是一些行业术语、人名导入后务必抽样验证避免看起来一样查不到。三、数据迁移KDTS 全量 增量数据迁移是KDTSKingbase Data Transfer Service的主场。它支持全量迁移和增量迁移两种模式。全量迁移KDTS 的全量迁移是把源库的数据一次性搬到目标库。这里的关键参数是批处理大小batch size。设太大内存吃不消设太小迁移速度慢。根据我实测100 万行级别的表batch size 设 5000-10000 是比较合适的区间。增量迁移如果业务不能停机就需要全量 增量模式。KDTS 的增量迁移基于源库的 redo logOracle或 binlogMySQL在全量迁移完成后持续同步源库的变更INSERT/UPDATE/DELETE到目标库。这里最容易翻车的地方是增量同步的延迟。如果源库写入量很大增量同步可能跟不上导致迁移窗口被迫拉长。解决办法是在业务低峰期启动增量同步并在正式割接前确认增量延迟降到毫秒级。实测迁移速度参考数据量全量迁移耗时千兆网络10 GB15-30 分钟100 GB2-4 小时1 TB10-20 小时注意这取决于网络带宽、源库写入压力、以及表结构复杂度索引越多、约束越多写入目标库越慢。四、大对象和文件迁移KFS 上场如果源库里有 BLOB、CLOB 大对象或者数据库里存储了文件路径关联的实际文件需要KFSKingbase File Sync来同步。KFS 做的事情是把源库的大对象数据提取出来写入目标库对应的字段同时保证数据一致性。这个工具单独跑是因为大对象迁移的逻辑和普通表数据不同——它需要按流读取、按块写入不能走普通的 INSERT 批处理。坑大对象迁移期间源库的 IO 压力会显著上升。建议在业务低峰期跑并且在 KDTS 的数据迁移和 KFS 的大对象迁移之间留出时间窗口避免资源冲突。五、数据校验不校验等于没做迁移完成后数据一致性校验是必须做的一步。不要相信工具说成功就等于成功。校验的核心动作行数比对每个源表和目标表的COUNT(*)必须一致关键字段抽样比对金额类字段、时间类字段、主键外键关联抽样 10-20 条数据逐字段比对CHECKSUM 校验对核心表做CHECKSUM TABLE或按主键分段做SUM(ORA_HASH(字段))比对存储过程和函数调用验证挑 3-5 个最常用的存储过程在目标库执行对比返回结果金仓工具链的优势是KDTS 内置了数据校验功能可以自动比对源库和目标库的数据一致性生成差异报告。但自动校验不能完全替代人工抽样——尤其是业务逻辑相关的字段还得靠人来判断。六、业务割接和回切方案割接不是把应用连接字符串一改就完事。标准流程是停写源库停止写入或切只读追增量KDTS 把最后一段增量数据追完最终校验确认数据一致性切换应用把应用连接指向目标库冒烟测试核心业务流程跑一遍确认正常观察期跑 1-2 天确认没有隐性 bug回切方案必须有如果割接后发现重大问题需要有回切方案——把目标库新增的数据同步回源库把应用切回去。KDTS 支持双向同步割接前需要配置好回切通道。回切的前提是割接期间目标库的变更也能实时同步回源库。所以割接不是单向迁移而是双向同步 单向为主。七、总结完整的数据库迁移流程可以用一句话概括评估先行工具辅助校验兜底回切保底。金仓的 KDMS KDTS KFS 工具链把评估、迁移、校验串成了一条流水线。但工具再好流程不对、校验不细、回切不配照样可能翻车。数据库迁移没有零风险但零翻车是可以通过严谨的流程做到的。小耶在手SQL不愁。还有什么想了解的欢迎留言小耶一定知无不言言无不尽……我们下次见~
