SQL Server数据迁移怎么做？一次事故复盘：备份还原、bcp、CDC、KDTS全拆解

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

上周朋友带着一份安全扫描报告来找我。SQL Server 2016 已经在7月14日结束了扩展支持。他公司那套跑了快十年的老库被限期要求迁走。库几百个G，业务不能停太久。

他问我SQL Server迁移工具怎么选。我没急着答，先拉着他把账算了一遍。数据量多大、能停多久、目标环境是哪儿。三笔账算清楚，SQL Server数据迁移这件事的核心就摆出来了：把库和对象完整搬到新环境，数据不丢、业务不停、应用能跑。

一次SQL Server数据迁移事故：分离附加，库直接suspect

朋友公司的数据库就是被分离附加搞挂的。DBA图省事，把数据库从生产实例上分离，拷贝数据文件到新服务器。附加的时候卡住了，新库一直显示"正在恢复"，最后状态变成了suspect。

原因不复杂：分离时连接没断干净，数据文件和日志文件没有成对拷贝。日志对不上，数据库引擎直接拒绝承认这个库。这一挂，业务停了整整两天才缓过来。恢复的过程也折腾。DBA先重启服务，库还是suspect。再跑DBCC CHECKDB做一致性检查，报错一串。最后只能从最近一次备份还原。中间几个小时的交易数据没了，靠运营手工补录。那两天业务方天天来催，对账对到半夜。等我接手的时候，生产库已经没人敢碰了。

先算三笔账，再谈SQL Server数据迁移

我接手后的第一件事，不是选工具，是算账。三笔账：数据量、停机窗口、目标环境。数据量决定能不能跑全量，停机窗口决定要不要上增量同步，目标环境决定是不是得换数据库。

我让朋友先跑了几条SQL，把库大小和表数量拉出来。

sql 复制代码

-- 库大小（MB）
SELECT SUM(reserved_page_count) * 8 / 1024 AS size_mb
FROM sys.dm_db_partition_stats;
-- 表数量
SELECT COUNT(*) AS table_cnt FROM sys.tables;

结果很清楚：几百G的库，表快两千张，还有几十张上亿行的流水表。停机窗口，业务方只给一个周末，搬完就得切，没有反复试错的空间。目标环境上，安全部门倾向国产化替代，工具选型就得把异构转换考虑进去。数据量几百G，全量可行，但纯靠脚本肯定不行。三笔账摆平，方案长什么样我心里基本有数。

SQL Server数据迁移选型：一张决策表

选型这件事，我习惯把约束和方案摆在一张表里看。判断的维度就三条：能不能停、数据多大、目标是不是国产库。下表把这次项目碰到的约束和对应方案列清楚了。

维度	约束	对应方案
停机窗口	能停数小时	备份还原
	只能停分钟级	SSIS或物理备份
	不能停	逻辑复制CDC或KFS增量
数据量	百G以内	脚本或bcp
	百G到T级	备份还原或KDTS
	T级以上	物理备份或专业工具
目标环境	同版本跨服务器	备份还原
	上云托管	DTS
	异构/信创	KDMS评估+KDTS迁移

朋友这个项目，停机能接受、数据几百G、目标倾向国产化。对照表一查，答案很清楚：同库迁移用备份还原，信创替换走KDTS这条线。选型这一步，难的不是工具不会用，是约束没想清楚。这轮聊完，朋友心里总算有了底。

SQL Server数据迁移执行阶段：备份还原打底，bcp和CDC补位

选型定下来之后，就该动手了。朋友那个挂掉的库，最后靠备份还原救了回来，顺带完成了迁移。真正动手的时候，我把SQL Server数据迁移的方案排了个优先级。下表是这次项目实际用到和试过水的几个方案。

方案	停机	适合体量	注意点	这次项目
备份还原	要停	全量为主	目标版本不能低于源库	主方案
bcp+脚本	要停	大表提速	两端网络要稳	混合用
分离附加	要停	仅同实例	跨服务器易翻车	弃用
逻辑复制CDC	不停	增量追平	无主键/堆表受限	备用
专业工具KDTS	可不停	异构/信创	评估先行	信创方案

主方案是备份还原。源库做完整备份，生成.bak文件，拷到目标服务器还原。它能带走库内对象和权限，比文件拷贝省心。命令就两条：

sql 复制代码

BACKUP DATABASE [mydb] TO DISK = N'D:\backup\mydb.bak' WITH INIT;
RESTORE DATABASE [mydb] FROM DISK = N'D:\backup\mydb.bak' WITH REPLACE;

前提有两个：目标版本不能低于源库，还原路径提前确认。服务器级的登录名和作业不在备份里，要单独建好。备份文件我建议放独立存储，别和源库挤同一块盘。

几百G的库，纯脚本导入不现实。SSMS生成脚本，全是逐条INSERT，大表能跑到怀疑人生。AWS官方博客做过一轮公开实测，1千万行的表，脚本导入要5小时，bcp批量复制只要8分钟。我按这个思路在自己的环境也验证过，量级基本一致。所以大表走bcp，小表走脚本，混合着来。

bcp的命令很直接：

bash 复制代码

bcp mydb.dbo.big_table OUT big.dat -c -S 源服务器 -U sa -P xxx
bcp mydb.dbo.big_table IN big.dat -c -S 目标服务器 -U sa -P xxx

bcp走大容量复制接口，导入速度比脚本快一截，但要求两端网络稳定。数据含中文的话，把-c换成-w，避免字符集乱码。

朋友这个项目停机窗口能接受，全量为主，没上增量。但如果你想做不停机迁移，得看CDC这条路。源库开CDC（变更数据捕获）。增量变更通过日志实时同步到目标端。全量先迁，增量追平，切换窗口能压到分钟级。代价是配置复杂，无主键表、堆表这类场景，部分工具处理不了，实施前要先探一遍底。CDC也不是万能药，源库开变更捕获要占日志空间，表结构频繁调整的场景容易出问题，不少团队权衡完，宁可多停两小时窗口。

信创路径：SQL Server数据迁移到KES

上面讲的是同库迁移，目标还是SQL Server。如果目标不是SQL Server，而是国产数据库，方案得换一套。信创替换这条线，我花的心思最多。

有个客户要从SQL Server迁到KES，业务是核心交易系统，SQL Server 2016和2019混着用，存储过程2000多个，链接服务器300多个。这个项目最让我头疼的不是数据量，是那2000多个存储过程。SQL Server的存储过程和国产库的语法差异很大，手工改不现实。

我们先跑了一遍KDMS的兼容性评估。工具自动扫了一遍源库和业务代码，生成了一份报告：哪些能自动转、哪些要手工改、哪些得换方案。报告拿到手，心里才有底。2000多个存储过程，真正需要手工改的不到两成。

结构迁移用了KDTS。数据类型映射、排序规则对齐，datetime转TIMESTAMP、GETDATE()映射成CURRENT_TIMESTAMP，GO批处理分隔符、INSERTED/DELETED临时表引用这些SQL Server特有的写法，工具都自动处理了大部分。最让我意外的是断点续传，几百G的库跑到一半网络断了，重连之后直接从断点接着跑，不用从头再来。光这一项，省下的时间就按天算。

业务不能停的那套系统，靠金仓异构数据同步软件Kingbase FlySync（简称KFS）做增量同步。它基于日志解析实时捕获变更，持续推送到目标端，割接窗口压到了4小时。这套组合跑下来，客户从部署到迁移完成花了72小时，灰度割接4小时搞定。

SQL Server数据迁移验收阶段：三步确认真的迁完了

数据搬完，不叫迁完。验收我习惯三步走：对象对比、数据校验、业务回归。

对象对比，数两边表、视图、存储过程的个数，对不上先排查。数据校验，核心表比行数，再抽几条对关键字段。业务回归，把高频操作在目标库跑一遍，看有没有报错。别只跑查询，写入、修改、删除都要过一遍。造几条测试数据，走完整套增删改流程，再和源库对结果。核心报表重跑一遍，看耗时差多少，差太多说明目标库的索引或优化器没接住。

这一步最容易省，也最不该省。我见过太多项目，数据对得上，权限没跟上，应用一上线就报错。朋友的库迁完，我们也是按这三步走完才敢切正式。源库备份先留一个月，业务稳了再清。真出问题，源库还能还原回去，这是最后一道保险。

SQL Server数据迁移的三条教训

这次项目收尾，我把踩过的坑整理成三条，写给要做SQL Server数据迁移的人。

第一条，分离附加别碰跨服务器。它只适合同实例内挪文件，跨服务器就是给自己埋雷。文件不完整、版本不兼容、登录名丢失，哪个都能让库变suspect。朋友的库就是这么挂的。跨服务器迁移，老老实实走备份还原。

第二条，跨版本迁移先做兼容性评估。高版本备份还原不到低版本，部分特性目标版本不支持。迁移前用评估工具扫一遍，看清哪些自动迁、哪些要手工改。KDMS这类工具的价值，就是提前把风险点摆到桌面上。评估这一步省不得，返工成本比评估高得多。

第三条，登录名、作业、权限要单列一项。备份还原和分离附加都不搬这些，跨实例后应用一连接就报错。作业、链接服务器、权限全要重建，工作量不比迁数据小。先把登录名对齐，再切业务，能少踩一个坑。验收时记得把权限检查放进业务回归。

复盘完，说点实在的

复盘完这个项目，我的体会是：SQL Server数据迁移的难点，从来不在工具本身，而在约束没想清楚。数据量、停机窗口、目标环境，三笔账先算明白，方案自然浮出来。同库迁移，备份还原够用。不停机的业务，老老实实上CDC。信创替换，交给评估工具和专业迁移工具。每一条，都是这次项目用时间换来的。

如果你也在做信创场景下的SQL Server数据迁移，KES这套工具链值得重点看。KDMS管评估、KDTS管迁移、KFS管增量同步，SQL Server的五大技术难点，在SQL Server兼容版里都有适配。我自己跑完这个项目，最大的变化是不再怕迁移了。先把约束摆清楚，再选工具，心里就有底。

你在SQL Server数据迁移时踩过什么坑？评论区聊聊。

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