当前数据库服务器：SQL Server 2005 - Windows Server 2003 新目标数据库服务器：SQL Server 2005 - Windows Server 2003 Enterprise - VM Ware 映像
当前数据库服务器上有 20 多个数据库，一些是应用程序数据库……其他是基础设施类型的数据库（Citrix）。我们希望将所有这些数据库移动到一个新建的虚拟化盒子中。
因此，进一步总结 - 是的，这是物理到虚拟的。 - 20 多个数据库转移到这个新的虚拟 SQL 2005 盒中。 - 这个盒上的应用程序需要最少的停机时间。
我能想到的几种方法（所有方法都会经过测试）：1.第三方物理到虚拟转换器 - 然后关闭旧盒子。
- 关注点 = SID 关联，Windows 或 SQL Server 不喜欢这样。
将所有数据库一次性移至新服务器 - 关闭旧服务器，将新虚拟箱上的主机名更改为旧主机名。
一次性全部移动但对新盒子使用不同的主机名 - 这样可以在出现故障时并行运行 - 挑战=必须在每个应用程序内更改主机名 - 可能会出现问题。
分阶段转移每个数据库 - 这也意味着一个新的主机名和一个更长、更漫长的项目。
还有人有类似的情况吗？
答案1
我们从单个 SQL 服务器迁移到新的 SQL 集群（所有新硬件）。大约 70 个数据库。我们的方法是分离数据库、复制文件，然后将数据库附加到新的 SQL 节点。
我们被迫更新主机名，但我会将旧主机名下线并使用相同的主机名。你随时可以通过这种方式切换回来。
答案2
最大程度减少停机时间的一种方法是使用从一台服务器到另一台服务器的日志传送。这需要重新指向应用程序配置，但其优点是停机时间更短。一般来说，该过程如下：
- 创建新服务器并移动作业/登录/SSIS 等。
- 设置日志传送的源数据库并开始传送。
- 停止应用程序并将数据库设置为只读。
- 备份数据库的最后一条交易日志。
- 在新服务器上恢复最后的 tran 日志，设置为不可恢复。
- 将新的数据库重新设置为读/写。
- 使重新指向的应用程序重新上线。
几点说明：
- DB Mirroring 是一个类似的解决方案。
- SAN 级别复制也类似，但它需要特殊的 SAN（如 HP EVA）。
优点：
- 最短的停机时间。
- 日志传送的设置相当容易。
- 回滚计划相当容易。
缺点：
- 更多手动步骤。
- 必须检查应用程序以确保它被正确地重新指向（更多系统管理员/DBA 工作）。
因此，虽然存在权衡，但这种方法有效，而且是一种足够常见的技术。
埃里克-
答案3
并行运行可能会在制作副本和更新副本期间发生数据更改。更新应用程序以指向新主机名也可能导致问题。
我建议使用并行设置来测试每个应用程序，但一旦对测试满意，我可能会使用 Detach/Attach：如何使用 SQL Server 中的分离和附加功能将 SQL Server 数据库移动到新位置
答案4
如果您有几美元可以花，比如 300.00 美元左右，请查看 idera admin toolset。这是一款出色的软件。我在最近的一个项目中使用了它。它移动了数据库和任何相关对象，包括用户。这是值得的。只需 3 次点击，我就移动了所有数据库。我仍然用它来来回移动数据库。我相信他们有一个试用版。您还可以获得许多其他工具，例如跨数据库移动用户或对象等。