大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
数据库迁移这件事，说起来不就是"把数据从 A 搬到 B"，但真正干过的人都知道：从评估到割接，一步走错就是生产事故。
我最近完整跑了一遍 Oracle 到金仓 KingbaseES 的迁移全流程，用的是金仓自家的工具链------KDMS（评估）+ KDTS（迁移）+ KFS（文件同步）。今天把整个流程、每步踩的坑、以及最终校验结果一次讲透。
一、迁移不是从"导数据"开始的，而是从"评估"开始的
很多人上来就建目标库、跑数据导入，这是最大的误区。迁移的第一步一定是评估------你得先知道自己有多少东西"迁不过去"，才能决定工期和风险。
金仓的评估工具叫 KDMS（Kingbase 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 还是 BIGINT，VARCHAR2(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 全量 + 增量
数据迁移是 KDTS（Kingbase Data Transfer Service） 的主场。它支持全量迁移和增量迁移两种模式。
全量迁移
KDTS 的全量迁移是把源库的数据一次性搬到目标库。这里的关键参数是批处理大小（batch size）。设太大，内存吃不消；设太小，迁移速度慢。根据我实测，100 万行级别的表，batch size 设 5000-10000 是比较合适的区间。
增量迁移
如果业务不能停机，就需要全量 + 增量模式。KDTS 的增量迁移基于源库的 redo log（Oracle）或 binlog（MySQL），在全量迁移完成后，持续同步源库的变更（INSERT/UPDATE/DELETE）到目标库。
这里最容易翻车的地方是：增量同步的延迟。如果源库写入量很大，增量同步可能跟不上，导致迁移窗口被迫拉长。解决办法是在业务低峰期启动增量同步，并在正式割接前确认增量延迟降到毫秒级。
实测迁移速度参考
| 数据量 | 全量迁移耗时（千兆网络） |
|---|---|
| 10 GB | 15-30 分钟 |
| 100 GB | 2-4 小时 |
| 1 TB | 10-20 小时 |
注意这取决于网络带宽、源库写入压力、以及表结构复杂度（索引越多、约束越多，写入目标库越慢）。
四、大对象和文件迁移：KFS 上场
如果源库里有 BLOB、CLOB 大对象，或者数据库里存储了文件路径关联的实际文件，需要 KFS（Kingbase 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不愁。
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽......我们下次见~