大家好，我是数据库小学妹 👋我踩过的坑，你别再踩。

我第一次做信创迁移，评估报告上写着兼容率 95%，功能测试全绿。上线两周后，客服反馈同一个单据被录入两次。我第一反应是不可能。数据是脚本一条条搬过去的，条数能对上，怎么会多出来。

后来把两边的数据摊开，一条条比。问题不在搬，在搬完之后。有一类带空值的联合唯一键，在原来那边算冲突，到新库这边却不算了。就这一条差异，脚本搬得再准也救不回来。

那次教训让我记住了一句话：**数据迁移这件事，搬得动只是及格，搬得对才算过关。** 今天我们不聊某个工具怎么用，聊一件更靠前的事：数据迁移到底怎么做，才不至于上线两周后又返工。

## 一、先给结论：数据迁移是一条六步闭环，少一步就得返工

回答上面那个问题，我的答案只有一句：**把它当成一条六步闭环，每一步都有过关标准，不过关就不许往下走。**

六步分别是评估、转换、迁移、校验、割接、回退。前两步管会不会返工，中间两步管搬得对不对。出事了退不退得回来，看的是最后两步。下面这张表是全文骨架。

| 步骤 | 要回答的问题 | 过关标准 | 金仓对应能力 |
|:---|:---|:---|:---|
| ① 评估 | 到底要改多少？ | 逐条 SQL 的不兼容清单 | KDMS 迁移评估 |
| ② 转换 | 改完跑得对吗？ | 末梢语义用例逐条过 | KDTS 自动转换 + 兼容开关 |
| ③ 迁移 | 数据怎么搬干净？ | 全量与增量无缝衔接 | KDTS 全量 + Kingbase FlySync 增量 |
| ④ 校验 | 怎么证明搬对了？ | 存量加增量全量比对 | KFS 不停机全量校验 |
| ⑤ 割接 | 什么时候切？ | 双轨并行，灰度切 | KFS 双轨并行 |
| ⑥ 回退 | 出事怎么回去？ | 回退通道演练过 | KReplay 负载回放 |

![01-six-step-loop-1.5x.png](https://developer.qcloudimg.com/http-save/yehe-12362123/b2a932f21f7b68a1d3593ee2f447ae63.png)

## 二、第一步和第二步：兼容率 95% 是最危险的数字

先说评估。很多项目的评估，是把表、存储过程、触发器数量数一遍，再按"经验比例"估个改造量。我一开始也这么干，觉得心里有数。后来才明白，对象数量说明不了改造量。有的存储过程上千行，早没人调用了；有的触发器只有十几行，却卡在核心交易链路上。只看数量等于没看，真正要盘的是业务依赖度。

兼容率更麻烦。**它不是一个数字能概括的，而是要分层。** 我把它拆成四层，你可以拿去当验收尺：

1. **语法级**：语句能不能解析、会不会报语法错。这是门槛，不是目标
2. **基础语义级**：函数返回值、运算符优先级、隐式转换规则，结果对不对得上
3. **末梢语义级**：那 5% 藏身的地方，只在生产的高并发和边界条件下才暴露
4. **性能级**：语义对齐之后还得跑得动，跑批窗口能不能按时关

第三层最难。开头那个空值唯一键的坑，就出在这层。国产数据库想替掉 Oracle，兼容这关必须过。金仓的做法是把差异一个个列成开关：

| 兼容开关 | 影响的语义点 |
|:---|:---|
| `ora_input_emptystr_isnull` | 空串是否按 NULL 处理 |
| `ignore_zero_number` | number 类型输出是否忽略末尾连续的 0 |
| `trunc_compatible` | trunc 函数返回的 timestamp 是否与原库一致 |
| `nls_length_semantics` | 字符串长度按 char 还是 byte 计 |
| `ora_numop_style` | integer 操作符是否按 numeric 处理 |
| `ora_open_cursors` | 同一会话可同时打开的游标上限 |

![02-compatibility-layers-1.5x.png](https://developer.qcloudimg.com/http-save/yehe-12362123/8c34df453f8360860ce57461846a0869.png)

我第一次看到这张表时愣了一下。空串算不算 NULL，number 输出带不带末尾的零，这些细枝末节居然要单独设开关。后来才想通：**要一字不差地对齐，就得把差异一条条列出来，而不是含糊地说"高度兼容"。** 好处也在这儿：对不上翻个开关就行，不用回头改业务代码。评估阶段要做的，就是拿这张表逐条确认业务要哪种行为。

评估这关过了，才轮到转换。我的体会只有一句：**改得越少，风险越小。**

改多少，取决于兼容做到了哪一层。语法级靠工具自动转换，语义级得人工啃硬骨头。我在一个真实项目里见过一份改造清单，全是对象类型上的差异：类型继承、子对象赋值给父对象、`treat` 函数做类型转换、`order` 函数做实例比较、方法重载。这些在源库能跑，到目标库就得改写。触发器也一样，`TRIGGER_NESTLEVEL()` 得换成 `SYS_TRIGGER_DEPTH()`，功能等价，名字变了。

这类活靠人工一条条改，太慢也不保险。金仓配了对应的工具：KDMS 出清单，KDTS 做自动转换。KDMS 的评估数据来自三层：静态扫描代码文件里的 SQL、动态追踪应用运行时真正执行的 SQL、再从历史日志里挖存量负载。扫描完生成一份评估报告，哪些语法不兼容、要改多少、工作量大在哪，都能量化、能复核。我的习惯是，报告出来先不急着信，自己抽几十条最复杂的 SQL 对着看一遍。报告是路线图，不是终点。

## 三、第三步：全量搬完只是开始，增量衔接才是关键

开搬之前先做个取舍：**停服迁移，还是不停服迁移。** 停服简单、干净，代价是业务要停；不停服复杂，但业务不停。判断的尺子只有一把：停机窗口有多长。数据量小、窗口宽裕，停服就够了；核心系统动不动几个 T，窗口只有几十分钟，那就得走不停服。

不停服的思路不复杂：**先做全量，再接增量。** 全量把存量搬过去，增量把搬迁期间产生的新变更追上去。最容易出问题的是衔接点：全量结束的那一瞬间，增量从哪里开始追。衔接没对准，要么漏数据，要么重复。

全量和增量，得分成两件事来配工具。金仓的分工是：全量搬运用 KDTS，增量同步用 KFS（Kingbase FlySync，金仓异构数据同步软件）。KDTS 做全量时支持数据类型映射匹配。哪条搬失败了，整批不会跟着停，回头单独补那一条就行。KFS 负责把增量实时追平，迁移期间业务照常写。

![[配图/251-数据迁移六步闭环/03-full-incremental-timeline.svg]]![03-full-incremental-timeline-1.5x.png](https://developer.qcloudimg.com/http-save/yehe-12362123/e9a290887763fb7e6943079099576eb3.png)

传统增量是另一套做法，基于触发器加中间表：源表一变，触发器把主键写进中间表，再写个程序不停扫。这套能用，但要往源库上挂触发器，对业务有侵入。KFS 走的是日志层捕获，基本无侵入。医疗、金融这类核心系统更愿意用它做增量，原因就在这儿。

全量搬迁本身也有性能讲究。KDTS 的性能调优手册里给过一个理想值：200G/H。实际跑不跑得到，得看瓶颈在哪一端。用 jstack 看迁移进程的线程状态就能判断，读线程一直占着，瓶颈在读取端；写线程一直占着，瓶颈在写入端。搬迁日志里也有现成数据，取一段，用「最后一条大小减第一条大小」除以「最后一条时间减第一条时间」，实时速率就出来了。这些数字才是停机窗口够不够的依据。

还有个细节容易漏。同构的物理迁移，比如单实例迁到集群，很多人直接拷 data 目录。拷之前得先手工建一次检查点，wal 日志大的先备份再清理；跨主机拷贝的时间，要按网络带宽和节点数算进去。这几步不做，停机窗口就是拍脑袋拍出来的。

## 四、第四步：校验，最容易糊弄，也最不能糊弄

到校验这一步，很多团队就开始赶工期了。做法通常是抽样比对：抽几千行出来，对得上，就算过了。**抽样比对最大的问题，是它永远抽不到边界值。** 而边界值恰恰是最容易出差异的地方。开头说的那个带空值的联合唯一键，抽样抽一百次也未必碰到一次。

所以校验的正确做法是**全量比对，不是抽样。** 存量数据全量比一遍，增量数据也得比。更彻底的做法，是把它放到不停机的前提下去做：业务还在写，比对还在跑，最后把差异项拉出来逐条修复。要做到这一步，并不轻松。金仓的 KFS 里配了一整套方案，业务不用停，存量加增量一起验。

工具能帮你把活干完，但替不了你做决定：**差异出现了，哪些必须修、哪些可以接受，得业务方来定。** 我在这里也失误过一次。当时为了保证工期，我把校验范围缩小到了几个核心表，觉得其他表"逻辑简单，不会有事"。结果上线后出问题的，正是一张看起来最简单的字典表，它的排序规则和原来不一样。这件事之后我改了做法：**校验范围由业务方和 DBA 一起定，不接受我一个人的判断。**

## 五、第五步和第六步：割接与回退，退路比速度重要

校验通过，到了最要命的一步：割接。割接就是一刀切，切过去发现性能不达标，业务方已经炸了，这时候想回去，回滚窗口可能早过了。**所以割接的第一原则不是切得快，是留退路。**

留退路分两层。第一层是能不能回退。做法是双轨并行：新老两套库并行跑，数据实时同步，业务先灰度切一部分过去，稳了再全量切。真出问题，反向同步切回去。这套实时同步靠的，就是金仓的 KFS。官方的割接流程里，最后一步写的就是"割接后观察或回退"，观察期建议覆盖三个完整业务周期以上。

第二层是切之前到底验没验过。这个我一开始也不当回事，觉得压测脚本写得好就行。后来看了一个真实的迁移复盘才改观：团队把生产环境 24 小时的完整负载抓下来，在 1:1 的测试环境里原样重放，加压减压各来一轮。除了显性报错，还翻出一批平时压不出来的差异，都在上线前暴露了。这些，人手写的压测脚本基本覆盖不到。对应的工具是 KReplay，负载回放。

六步走完，我把它压成三句话，你可以贴在项目文档第一页：

- **评估不定量不迁**——拿不出逐条 SQL 清单，就别谈工期
- **校验不全量不切**——抽样过的库，不算验过
- **回退没通道不上**——没有回退方案的割接，就是赌博

## 六、一个案例：2TB 核心系统，六步怎么走完

理论说完了，拿一个公开案例把六步串一遍。某三甲医院的临床数据中心，核心业务原来跑 Oracle 11g，要迁到金仓 KES。医疗系统容不得中断，又是信创替换的重点场景，选型上没多少余地。

规模不算小：数据量超 2TB，日均增量超 1GB，日均事务 1200 万以上，忙时 3 万 TPM 以上，高峰活动连接不低于 300。从选型适配到上线切换，历时 7 个月。

这六步他们大致是这么走的。**评估**做量化扫描，把改造量算清楚。**转换**靠高兼容性把改动压到最小。**迁移**拉双轨并行，同步延迟压在 1 秒以内。**校验**把全量迁移后的库，用原有备库变成一套准生产测试环境，挑 5 个关键业务场景手工测处理速度，取多次平均。结论很坦率：5 个场景新旧库互有高低，但都小于或接近 100 毫秒，没有数量级落差。**割接**用灰度切换，整体花了一个月，每个模块上线的业务暂停控制在 5 分钟以内。**回退**通道全程留着。上线后稳定运行超过 9 个月，数据量长到 2.34TB。

我看完最大的感受是：真正把项目做稳的，不是某个工具多强，是**每一步都留了验证和回退**。工具能把活干到八成，剩下两成的判断得人来做。

## 七、数据迁移启动前，先问自己三个问题

**第一，改造量有没有量化报告？** 要的是逐条 SQL 的不兼容扫描结果，不是一张对象数量清单。也别只看兼容率那个数字，尤其别信"完全兼容"，抽最复杂的几十条 SQL 实测，看执行计划和响应时间。

**第二，全量和增量怎么衔接？** 衔接点定在哪、怎么验证没漏没重，要能说出具体方案。校验是全量还是抽样，也在这一步定死。只做抽样的，等于没验。

**第三，割接有没有双轨并行和明确的回退方案？** 回退的判断依据、谁有权启动、窗口多长，都得提前写死。

再补一句：**项目交付后，团队里谁还接得住？** 这个问题不想清楚，前面做得再好，后面也可能还回去。金仓这套工具链在这件事上帮了忙：KDMS 管评估、KDTS 管迁移、KFS 管同步和校验、KReplay 管负载验证、KStudio 管日常运维，评估到运维能串起来，不用东家买一个西家凑一个。工具链降低了门槛，接得住的人自然就多了。

## 八、数据迁移避坑清单

**别用抽样比对代替全量校验。** 抽样永远抽不到边界值，而差异几乎都藏在边界上。我那次空值唯一键的坑，就是这么漏过去的。

**评估报告出来先抽检。** 工具扫描的逻辑和业务人工盘点的逻辑不一样，两边对一遍，能捞出差出来的对象。这一步花半天，能省后面好几周。

**观察期别太短。** 有些问题一个月才露一次头，比如月末结账、季度报表。我当时的项目只留了两周，事后回想是真冒险。官方建议观察期覆盖三个完整业务周期以上，这个建议很实在。

## 写在最后

回到开头那个问题：数据迁移怎么做才不返工？我的答案是，**别把它当成一次"搬数据"，把它当成一条六步闭环**：评估、转换、迁移、校验、割接、回退，每一步都有过关标准。

我在这条路上真正借上力的，是有人把"不确定"变成了"可测"。评估用 KDMS 出量化报告，迁移有 KDTS 管全量、KFS 管增量，校验能不停机做全量比对，割接有双轨并行随时回退，上线前还有 KReplay 拿真实负载验一遍。金仓这套工具链做的事，是把每个环节的不可控往可控的方向拉一点点。串成一句话，就是**改得少、搬得准、验得全、退得回**。这四个词我写在了自己复盘模板的第一页。但工具管的是"有没有退路"，怎么设计退路，还得靠人。

我现在养成一个习惯：每上一个高风险方案，先写回退方案，再写实施步骤。实施步骤写错了是加班，回退方案没写，可能是过年加班。

你们做数据迁移的时候，最怕的是哪一环？欢迎评论区聊聊，我也想听听你们踩过的坑。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见 👋

我第一次做信创迁移，评估报告上写着兼容率 95%，功能测试全绿。上线两周后，客服反馈同一个单据被录入两次。我第一反应是不可能。数据是脚本一条条搬过去的，条数能对上，怎么会多出来。

数据迁移方案怎么落地：六阶段闭环、迁移校验与回退设计

数据迁移不是把数据搬过去就完事。本文把数据迁移拆成评估、转换、迁移、校验、割接、回退六步闭环，讲清每一步的过关标准和最常见的翻车点，附KES工具链的落地对照与实测案例。

数据库

运维

后端

数据迁移防返工需走六步闭环：评估、转换、迁移、校验、割接、回退。重点在于兼容率分层评估、全量校验替代抽样、双轨并行留退路。避免空值唯一键等边界差异，需逐条SQL量化评估与真实负载验证。工具链KDMS/KDTS/KFS/KReplay助力全流程可控。

数据迁移

数据同步

数据中心

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

数据迁移方案怎么落地：六阶段闭环、迁移校验与回退设计-腾讯云开发者社区-腾讯云

数据迁移方案怎么落地：六阶段闭环、迁移校验与回退设计

数据迁移方案怎么落地：六阶段闭环、迁移校验与回退设计

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐