Azure微软云购买：使用Azure Database Migration Service实现本地SQL Server零迁移迁移

在企业 IT 架构向云原生演进的过程中，最让 CIO 睡不着觉、让 DBA 掉光头发的业务场景，莫过于核心数据库迁移上云。

很多公司在面对几十个 GB 甚至数个 TB 的本地 SQL Server 数据库时，往往采用最原始的“停机断网、备份导出、跨网传输、云端还原”四部曲。这种做法在小作坊式的边缘业务里勉强能跑通，但在面对金融、电商、或者 24 小时高频运转的生产系统时，无异于一场自杀式的豪赌：光是把几百个 GB 的备份文件通过公网或专线跨海传输，就需要好几个小时。在这期间，整个公司的业务必须完全停摆、挂起“系统维护”的白屏。一旦传输中断或者云端还原报错，漫长的回滚过程不仅会拖垮当季度的 KPI，更会让企业面临难以承受的财务损失。

为了彻底降维打击这种“停机时间长、迁移风险高”的行业痛点，微软云（Azure）掏出了一款专为数据库现代化量身定制的无缝搬家神器——Azure Database Migration Service（DMS，数据库迁移服务）。

它的核心逻辑强硬且优雅：利用在线数据流持续复制（Online Migration），实现近乎“零停机时间（Near-Zero Downtime）”的平滑迁移。 它的工作原理非常像在本地和云端数据库之间插了一根“实时输血管”：在迁移开始时，它会先做一次全量的数据底盘同步；随后，本地数据库即便依然在疯狂接收新订单、改写新数据，DMS 也会通过读取事务日志，把这些增量数据以毫秒级的延迟实时“倒灌”到云端的 Azure SQL Database 中。等到两边的数据完全对齐、差异压缩到几秒钟时，你只需要挑一个夜深人静的时刻，点击“断开切流”，业务便能在几秒钟内平滑切换到云端。

今天我们拒绝任何官方概念的堆砌，不扯无聊的教科书参数。直接从最硬核的现代化生产实战切入，手把手带你用大厂规范，10 分钟在云端布设好这根实时输血管，将本地的 SQL Server 完美、零风险地送上云端。

第一阶段：深度拆解，在线零停机迁移的“三维管道模型”

在动手去 Azure 控制台点鼠标之前，你必须在脑子里建立起 DMS 在线迁移底层的数据流动模型。很多人在配置时频繁报错，就是因为没搞懂这三者之间是如何对齐暗号的：

1. 源头阵地：本地物理机/虚拟机中的 SQL Server：这是你的生产命脉。为了实现“在线不掉线”的增量同步，本地数据库必须开启完全恢复模式（Full Recovery Model），并且必须进行过至少一次完整的备份。这是为了让 DMS 能够顺藤摸瓜，通过读取你的事务日志（Transaction Log）来捕捉每一名用户刚刚发生的下单或改密动作。
2. 黄金搬运工：Azure DMS（全托管迁移引擎）：这是坐镇在云端的一个高防、高并发的 PaaS 计算集群。它就像一辆不知疲倦的数字大卡车。为了能同时拉到本地数据库和云端数据库的手，DMS 实例必须被部署在能够通过物理专线（ExpressRoute）或高防 VPN 穿透进入你本地内网的虚拟网络（VNet）中。
3. 云端接盘侠：Azure SQL Database（或 SQL 托管实例）：这是迁移的终点站。在迁移正式开启前，它就像一个空房间。DMS 会先在这里像素级克隆出和本地一模一样的表结构、索引和约束，然后开始源源不断地接纳倒灌进来的数据流。

第二阶段：实战演练——10 分钟平地起高楼，架设 DMS 实时输血管

请确保你已经提前在 Azure 上建好了一个干净的终点站：Azure SQL Database（或者 Azure SQL Managed Instance），并且本地机房与 Azure 虚拟网络（VNet）之间的 VPN 专线已经完全打通。

步骤 1：开辟 DMS 全托管迁移工作区

1. 登录 Azure 门户网站（Portal）。
2. 在上方搜索栏输入 “Azure Database Migration Services”，点击进入核心控制台。
3. 点击顶部的 “+ Create”：基本信息：选好你的资源组，给迁移服务起名叫 dms-core-prod，地域选择离你本地机房最近的（如 East Asia 香港）。服务模式（Service Mode）：极其关键，必须选择“Azure Resource Manager”。定价层（Pricing tier）：如果想要玩转“近乎零停机”的在线增量复制，必须精准选中“Premium”（高级版，支持 4 核算力）。标准版只支持离线单次导出，只有高级版才能解锁在线输血管黑科技，而且微软目前针对该服务提供了非常优厚的基础测试免费额度。虚拟网络（Virtual Network）：精准选中那条与你本地机房通过 VPN/专线互联的 VNet。

点击创建。微软的无服务器编排引擎会在后台为你打磨这个迁移网关，大约 3 分钟左右服务就会满血在线。

第三阶段：实战演练二——降维打击，开启在线实时数据倒灌

当 DMS 实例的状态亮起绿色的 Succeeded 时，最硬核的搬家战役正式打响。点击进入该 DMS 实例。

1. 新建迁移大盘项目（New Migration Project）

1. 点击顶部的 “+ New Migration Project”。
2. Project name：起名叫 proj-sql-to-azure。
3. Source server type：选择 SQL Server。
4. Target server type：选择 Azure SQL Database（根据你的云端接收端选择）。
5. Choose type of activity（选择活动类型）：注入灵魂的一步，必须、坚决选中“Online data migration”（在线数据迁移）。

2. 对齐两界接头暗号

点击下一步，来到源站和目标站的凭据填写页面：

1. Source details（源详细信息）：输入你本地 SQL Server 的内网 IP 地址、端口号，以及具有 sysadmin 权限的 DBA 账号密码。
2. Target details（目标详细信息）：输入你 Azure SQL Database 的服务器域名（例如 sql-prod-srv.database.windows.net）以及云端的管理员账号密码。
3. 选择数据库：系统会自动隔空抓取本地 SQL Server 里的所有数据库列表。勾选你需要搬家的核心业务库（如 db_ecommerce）。

3. 布设中间中转站（网络共享路径）

在线迁移需要一个本地和云端 DMS 都能读写的中转站，用来临时存放事务日志备份。

1. 在网络位置表单里，输入一个你本地机房里的 SMB 网络共享路径（如 \\local-nas\sql_backup）。
2. 输入能够读写该路径的域账号密码。DMS 会通知本地 SQL Server 把增量日志源源不断地吐到这个共享目录里，然后 DMS 再从这里把日志抓取、解析、并高频重放到云端。

连续点击下一步，最后按下 “Start Migration”（启动迁移）。

第四阶段：见证奇迹的现场——秒级断联，业务无缝抢滩登陆

点击启动后，点击进入这个激活的迁移任务（Migration Activity）详情页。

你会看到一个非常直观的流式监控大盘：

• 全量加载阶段（Full Load）：DMS 正在后台疯狂把本地现存的存量数据打包、闪电般克隆到云端。
• 增量同步阶段（Incremental Sync）：全量跑完后，状态会变成 Syncing。此时，你让开发在本地数据库里故意插入一条测试订单，你会发现大盘里的 “增量更新计数器” 瞬间跳动，在不到 1 秒钟内，这条新订单就已经在几千公里外的 Azure 云端数据库里安稳落盘。两边的数据差（Downtime Time Capacity）被死死压缩在 2 秒以内。

终极切流切线时刻（Cutover）

当状态死死保持在 Ready to Cutover（准备好切换）时，说明上云的冲锋号已经吹响。

1. 下达行政命令：通知前端开发，将本地 APP 或网站的连接池临时变更为“只读”，或者短暂挂起前端几秒钟，确保本地数据库不再产生任何新的数据写入。
2. 等待大盘里的“未迁移事务”彻底清零、延迟变成 0 秒的瞬间。
3. 一键飞升：在 DMS 详情页顶部，果断按下 “Complete Cutover”（完成切换） 按钮。DMS 会把最后两秒钟的残留日志强行重放完毕，然后彻底安全地斩断两界通道。
4. 运维全速将前端 APP 的数据库连接字符串（Connection String），一键修改指向云端的 sql-prod-srv.database.windows.net，重启前端服务。

全过程从停机、切流、到云端满血复活，整条业务线的实质性停机时间被强行压缩在了短短的 15 秒到 1 分钟之内。海外买家甚至只是感觉手机上的网页轻微刷新了一下，整座企业的数字帝国大后方就已经神不知鬼不觉地在微软云的顶级高防机房里顺利会师、抢滩登陆成功。

第五阶段：工业级零停机迁移下的避坑血泪史

这套迁移方案在实战中的优雅程度堪称艺术。但要在真正的企业级大流量、严苛的生产审计战场里稳定活下来，作为首席数据库架构师，你必须在合拢电脑前，顺手焊死以下两个由于在线同步引发的现实大坑：

1. 致命的“本地磁盘被爆满”隐患（Log Chain Broken）

在线迁移期间，DMS 需要高频地去本地读取和清理事务日志备份。

• 灾难发生：如果你的本地生产库并发极高（比如每秒几万条写入），而你本地机房分给共享备份目录（SMB Path）的磁盘空间非常局促。一旦由于跨国网络轻微抖动，导致云端的 DMS 抓取日志的速度变慢了，本地的 SQL Server 依然在疯狂地把日志吐进这个目录，在几个小时内就会把本地存储空间彻底塞爆（Disk Full），直接反向导致你本地的生产数据库当场因缺空间而脑死亡挂掉。
• 大厂标准免死金牌规范：在开启 DMS 前，必须给本地共享备份盘划出至少 2 倍于日常日志产生量的富余空间，并且利用 Powershell 写一个定时脚本：只要 DMS 已经成功确认重放（Acknowledged）了某批日志，就自动在本地将其物理粉碎擦除。用饱满的物理预算去对冲网络不确定性。

2. 严禁让外键约束和触发器在全量加载期“帮倒忙”

如果你的本地数据库里设计了极其复杂的外键约束（Foreign Keys）或者触发器（Triggers）（比如插入 A 表时，触发器会自动去修改 B 表）。

• 内幕曝光：当 DMS 在执行第一步全量加载（Full Load）时，它是多线程并行向云端砸数据的。如果云端的表结构默认开启了高频触发器，DMS 刚塞进去一条数据，触发器就会在云端自作聪明地去改别的表，这不仅会导致数据产生严重的两重冲突、账目对不上，还会把云端数据库的 CPU 在一瞬间活生生顶爆，让全量同步的速度慢得像乌龟爬。
• 硬核加固规范：先脱衣，后穿衣。在编写云端 DDL 脚本时，先在云端创建不带外键约束、不带触发器的“裸表”。让 DMS 全速、无阻碍地把所有海量数据以最高并发全部倒灌进去。在点击 Cutover（切换）的前夕，再通过一段标准的 SQL 脚本，一键把外键约束、触发器和高频索引在云端“满血恢复复活”。顺应数据库的底层吞吐胃口去设计流水线，它才会给你回报真正的零失误响应。

总结

利用 Azure Database Migration Service 实现本地 SQL Server 的在线零停机迁移，核心的工业级精髓其实简化为十六个字：全量打底，增量倒灌，日志牵线，秒级切流。

你彻底告别了过去每次给数据库搬家都要天天看网络带宽脸色、提心吊胆怕文件损坏、深夜拉着全公司熬夜停机打持久战的原始作坊苦海。把所有繁杂的分布式校验和高频重放，完全托管给云大厂的 PaaS 级数据大脑。坐在电脑前，看着两端数据在眨眼间像素级对齐，优雅地敲一下回车，迎接云原生时代的满血进化。