迁移核心流程概览
整个过程可以分为以下五个主要阶段：
（图片来源网络，侵删）
- 规划与评估
- 迁移前准备
- 执行迁移
- 迁移后验证与优化
- 回滚计划与上线
第一阶段：规划与评估
这是整个迁移项目最关键的一步,决定了后续所有工作的方向和成功率。
明确迁移目标
- 为什么迁移？ 是因为硬件老化、操作系统升级、云化转型、成本优化，还是需要更高的性能/可用性？
- 目标是什么？ 将本地服务器迁移到云、将 SQL Server 2025 升级到 2025、将多个实例合并到一个新实例等。
评估当前环境
- 收集资产清单：
- 服务器信息： 操作系统版本、CPU、内存、硬盘配置（类型、大小、RAID级别）。
- SQL Server 信息： 版本、 edition (Standard/Enterprise)、实例名称、版本级别 (RTM/SP/CU)、集群 AlwaysOn 配置。
- 数据库信息： 所有数据库名称、恢复模式、兼容级别、文件路径和大小。
- 对象信息： 登录账户、作业、链接服务器、SQL Agent 作业、维护计划、服务器配置选项。
- 评估性能与负载：
- 使用 SQL Server Profiler 或 Extended Events 监控一段时间，了解高峰期的负载（CPU、I/O、内存）。
- 分析 查询性能，找出性能瓶颈。
- 评估磁盘 I/O 吞吐量，确保目标环境能满足需求。
选择迁移策略
根据你的目标和环境,选择最合适的迁移方法：
| 迁移方法 | 描述 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 备份和还原 | 在源服务器上备份数据库。 将备份文件传输到目标服务器。 在目标服务器上还原数据库。 |
最简单、最常用，可靠性高，能保证数据一致性。 | 需要较长的停机时间来完成备份、传输和还原。 | 版本内迁移、跨服务器迁移、灾难恢复。 |
| 分离和附加 | 在源服务器上分离数据库。 复制数据库文件（.mdf, .ldf）。 在目标服务器上附加数据库。 |
速度快，停机时间短（主要是复制文件的时间）。 | 不适用于 AlwaysOn、数据库镜像或事务复制的环境，文件路径必须一致。 | 同一版本下的快速迁移，文件系统可以访问的情况。 |
| 导入和导出 | 使用 SQL Server Integration Services (SSIS) 或 BCP 实用工具在不同数据库之间传输数据。 | 灵活性极高，可以进行数据转换、筛选。 | 可能会丢失部分对象（如视图、存储过程依赖），数据类型可能不兼容。 | 跨版本、跨数据库引擎（如 SQL Server 到 MySQL）的迁移，或需要数据转换的场景。 |
| 使用“生成脚本向导” | 在源服务器上生成所有数据库对象的脚本（架构+数据），然后在目标服务器上执行。 | 版本兼容性最好，能处理跨大版本升级。 | 速度慢，不适合大型数据库，可能因脚本语法问题导致失败。 | 小型数据库迁移、跨大版本升级的辅助工具。 |
| 数据库复制 | 使用 SQL Server 复制功能将数据从源服务器同步到目标服务器。 | 可以实现零停机或最小停机的迁移，数据可保持最新。 | 配置复杂，会增加源服务器的负载。 | 需要业务连续性，无法长时间停机的场景。 |
| 使用第三方工具 | 如 Redgate SQL Compare/Data Compare, Quest Migration Manager, AWS/Azure/GCP 的数据库迁移服务。 | 通常自动化程度高，功能强大，能处理复杂场景，支持异构迁移。 | 成本较高，需要学习和适应工具。 | 大型企业、复杂环境、云迁移或预算充足的项目。 |
制定详细计划
- 时间表： 制定详细的甘特图，明确每个任务的开始和结束时间，特别是停机窗口。
- 资源分配： 明确项目团队成员及其职责（DBA、网络工程师、应用负责人等）。
- 沟通计划： 通知所有相关方（业务部门、应用开发团队、最终用户）迁移计划、停机时间及回退方案。
- 风险评估与应对： 预测可能出现的风险（如数据丢失、时间超支、应用不兼容）并制定应对措施。
第二阶段：迁移前准备
准备工作越充分,迁移过程就越顺利。
- 搭建目标环境：
- 安装与源环境兼容或更高版本的 SQL Server。
- 配置服务器角色、服务账户、TCP/IP 端口等。
- 创建与源服务器结构一致的用户和登录名（重点关注
sysadmin角色的用户）。 - 规划并创建数据库文件路径,确保有足够的磁盘空间。
- 数据备份：
- 在执行任何操作前,务必对源服务器进行完整备份！这是最后的救命稻草。
- 预迁移测试：
- 在测试环境中完整演练一遍迁移流程。
- 验证数据库能否成功还原/附加，应用能否正常连接和操作。
- 检查所有对象（存储过程、视图、作业）是否工作正常。
- 准备脚本和工具：
- 准备好用于创建登录、链接服务器等服务器级对象的脚本。
- 准备好用于验证数据库完整性的查询脚本。
第三阶段：执行迁移
这是将计划付诸行动的阶段。
（图片来源网络，侵删）
- 通知与停机：
- 按照沟通计划,正式通知用户开始停机。
- 停止所有连接到源数据库的应用程序。
- 执行迁移操作：
- 备份还原法：
- 在源服务器上执行
BACKUP DATABASE。 - 将备份文件（.bak）安全、快速地传输到目标服务器。
- 在目标服务器上执行
RESTORE DATABASE，使用WITH MOVE选项将文件移动到新路径。
- 在源服务器上执行
- 分离附加法：
- 在源服务器上分离数据库 (
sp_detach_db)。 - 复制数据文件和日志文件到目标服务器。
- 在目标服务器上附加数据库 (
sp_attach_db或通过 SSMS)。
- 在源服务器上分离数据库 (
- 升级场景： 如果是原地升级，运行 SQL Server 安装程序，选择“升级”选项，并按照向导操作。
- 备份还原法：
- 迁移服务器级对象：
- 手动或通过脚本创建登录账户、作业、链接服务器等，这些对象无法通过数据库备份还原。
- 对于登录账户,可以使用脚本生成工具（如
sp_help_revlogin）生成创建脚本，然后在目标服务器上执行。
第四阶段：迁移后验证与优化
迁移完成不代表项目结束,验证是确保业务正常的关键。
- 基本验证：
- 检查数据库是否为
ONLINE状态。 - 检查文件路径和大小是否正确。
- 检查数据库的兼容级别是否正确。
- 检查数据库是否为
- 功能验证：
- 使用测试应用或手动执行关键业务流程,验证数据读写、增删改查是否正常。
- 检查所有存储过程、视图、函数是否执行正确。
- 验证 SQL Agent 作业能否成功运行。
- 性能验证：
- 监控目标服务器的资源使用情况（CPU、内存、I/O）。
- 对比迁移前后的关键查询性能,确保没有性能下降。
- 根据需要,在目标服务器上创建必要的索引和统计信息。
- 权限验证：
抽样测试不同角色的用户,确保其权限设置与源服务器一致。
- 清理工作：
- 将源服务器重命名或隔离,作为临时回退环境。
- 更新所有应用程序连接字符串,指向新的数据库服务器。
- 更新文档,记录新的服务器信息。
第五阶段：回滚计划与上线
- 制定并测试回滚计划：
- 如果迁移后出现严重问题,必须有明确的回滚方案。
- 回滚方案： 将应用重新指向源服务器（如果源服务器保留），或在目标服务器上从备份中还原旧数据库。
- 在测试环境中演练回滚流程,确保其可行。
- 正式上线：
- 通知用户迁移完成,服务已恢复。
- 在最初的几天内,密切监控系统状态和用户反馈，快速响应可能出现的问题。
特别注意事项
- AlwaysOn 可用性组： 如果源服务器是 AlwaysOn 的主副本，需要先将次要副本同步到最新，然后故障转移到一个健康的次要副本，再将该副本升级或迁移到新环境，不能直接分离 AG 中的数据库。
- 跨版本升级： 从低版本（如 2008 R2）升级到高版本（如 2025）时，必须使用备份还原或升级向导，分离附加法不适用。
- 混合身份验证： 如果使用 SQL Server 身份验证，确保在迁移时正确传输了登录名及其密码哈希值。
- 加密： 如果数据库使用 TDE (透明数据加密) 或列级加密，需要在目标服务器上正确配置证书或密钥。
SQL Server 服务器迁移是一个技术与管理并重的项目。周密的规划是成功的基石，严谨的执行是过程的关键，彻底的验证是质量的保证，可靠的回滚是安全的底线，遵循以上步骤，可以最大限度地降低风险，确保迁移工作顺利完成。
（图片来源网络，侵删）
