如何安全地将SQL Server数据库完整迁移到新服务器？

SQL Server服务器迁移是一项常见但至关重要的数据库管理任务，旨在将数据库及其相关组件从一台服务器移动到另一台，无论是为了硬件升级、系统更新、数据中心迁移还是向云端过渡，一个周密规划的迁移方案都是确保业务连续性和数据完整性的基石，成功的迁移不仅仅是数据的复制，更涉及配置、权限、作业和应用程序连接等多个层面的无缝衔接。

在启动迁移之前,详尽的准备工作不可或缺，需要全面评估源服务器和目标服务器的环境，包括SQL Server版本、补丁级别、硬件配置（CPU、内存、磁盘I/O）以及网络带宽，确保目标服务器的性能至少不低于源服务器，甚至要预留未来的增长空间，必须对所有计划迁移的数据库进行一次完整的、经过验证的备份，这不仅是迁移的基础，也是在迁移失败时能够快速回滚的唯一保障，详细记录源服务器上的所有配置信息，如网络协议设置、服务器角色、链接服务器、SQL Server代理作业及操作员、以及自定义的错误消息等，这些都是迁移后需要重建的关键元素。

核心的迁移方法有多种,选择哪一种取决于业务对停机时间的容忍度、数据库大小以及技术复杂度。

备份与还原
这是最常用且推荐的方法，其核心流程是：在源服务器上对数据库执行一次完整备份；随后，如果允许停机，则直接将备份文件传输到新服务器并执行还原操作，为了最大限度地减少停机时间，可以在完整备份后，持续执行事务日志备份，在计划的停机窗口期，执行最后一次事务日志备份（备份日志尾部，WITH NORECOVERY），然后将所有备份文件（完整备份和所有日志备份）按顺序在新服务器上还原，最后恢复数据库（WITH RECOVERY），此方法灵活、安全，且允许在迁移前进行多次还原测试。

分离与附加
此方法相对简单直接，操作步骤为：在源服务器上分离数据库，这会关闭数据库并移除其在SQL Server实例中的引用；然后将数据库的数据文件（.mdf）和日志文件（.ldf）复制到目标服务器的相应位置；最后在目标服务器上附加这些文件，此方法的最大缺点是，在数据库分离和附加期间，数据库完全不可用，会造成较长的停机时间，因此不适用于对可用性要求高的核心业务系统。

高可用性技术迁移
对于要求近乎零停机时间的业务系统，可以利用SQL Server的高可用性功能，可以配置日志传送或Always On可用性组，将目标服务器配置为辅助副本，通过持续同步事务日志或数据，使其与主服务器（源服务器）保持近乎实时的一致，在迁移时，只需执行一个计划内的故障切换，将辅助副本提升为主角色，并更新应用程序的连接字符串即可，整个过程停机时间极短，通常只有几分钟。

为了更直观地选择合适的方法,可以参考下表：

迁移方法	优点	缺点	适用场景
备份与还原	安全可靠，可测试，停机时间可控	流程相对复杂，需仔细规划日志备份	大多数场景，尤其是可接受短暂计划内停机的系统
分离与附加	操作简单，直接移动文件	停机时间长，风险较高，无法在迁移中测试	小型非核心数据库，或可接受长时间停机的维护窗口
高可用性技术	停机时间极短，可实现平滑过渡	配置复杂，对技术要求高，需要额外资源	对可用性要求极高的核心业务系统（7×24小时）

完成数据库的迁移上线后,工作并未结束，迁移后的任务同样关键，首要处理的是登录名和用户的映射问题，由于SQL Server的登录名存储在master数据库中，而数据库用户存储在用户数据库中，直接迁移数据库会导致“孤立用户”，即用户存在但无法登录，需要使用sp_change_users_login存储过程或在新服务器上重新创建登录名并映射到数据库用户来解决，需要将记录在案的SQL Server代理作业、操作员、链接服务器等在新服务器上重新创建和配置，务必通知所有相关应用程序团队，更新其连接字符串，将数据库主机名指向新的SQL Server服务器，并进行全面的回归测试，确保所有功能正常。

SQL Server服务器迁移是一个系统性工程，它要求周密的计划、严谨的执行和全面的验证，通过选择正确的迁移策略，并细致处理迁移前后的每一个环节，可以确保整个过程平稳、高效，将业务影响降至最低。

---

相关问答FAQs

如何将SQL Server迁移过程中的停机时间降到最低？
解答： 要将停机时间降至最低，推荐使用“备份与还原”方法并结合事务日志备份链，或直接采用高可用性技术，在使用备份与还原时，在正式迁移前先执行一次完整备份并还原到目标服务器进行验证，在计划的停机窗口期，对源数据库执行一次事务日志尾部备份（BACKUP LOG ... WITH NORECOVERY），这个备份非常快，将这个最后的日志备份在目标服务器上还原，数据库即会恢复到与源服务器分离时完全一致的状态，整个过程停机时间可压缩到分钟级别，对于要求零停机的系统，Always On可用性组是最佳选择，通过一次计划内故障切换即可完成迁移。

数据库迁移到新服务器后，应用程序报告“登录失败”，但用户名和密码都是正确的，这是为什么？
解答： 这是典型的“孤立用户”问题，当您只迁移了用户数据库，而没有迁移master数据库中的登录名时，就会出现此情况，数据库中的用户（user_app）与SQL Server实例级别的登录名（login_app）是通过一个安全标识符（SID）关联的，在新服务器上，即使您创建了同名的登录名 login_app，它也会被分配一个新的SID，导致它无法与数据库中旧的SID为 user_app 的用户匹配，从而无法登录。
解决方法： 最常用的方法是使用 sp_change_users_login 存储过程，在目标服务器上，进入该用户数据库，执行 EXEC sp_change_users_login 'Auto_Fix', 'user_app'，系统会自动将数据库中的 user_app 用户与同名的登录名 login_app 关联起来，更好的做法是在迁移前，在源服务器上生成创建所有登录名的脚本（包括密码和SID），在新服务器上执行此脚本，这样就能完美保留SID，从根源上避免孤立用户问题。