是否可以将 SQL Server 2005 数据库移动到运行 SQL Server 2008 的其他服务器而无需停机？系统是 24/7 全天候运行的，必须移动到具有不同存储的其他服务器。
我们尝试复制数据库，但这并不能使整个数据库在过程结束时保持同步。
答案1
零停机时间不是。但是通过仔细规划，您可以实现接近零停机时间。
选项1：
- 在现有 2005 和新 2008 服务器之间设置日志传送。
- 仔细规划切换 IP 和/或主机名。
- 确保在最终切换之前完成最终的尾部日志备份。
选项 2（工作量增加，停机时间减少）：
- 如果您的 2008 盒子是新的，那么请先将 2005 安装到与您的产品盒子相同的 sp 上。
- 设置数据库镜像，第一阶段异步以避免性能开销。
- 设置客户端，使故障转移伙伴包含在连接字符串中
- 更改为同步数据库镜像并故障转移到新框
- 按照“滚动升级步骤”对 2005-2008 进行数据库镜像设置就地升级
当然，为了做到这一点，你需要进行测试并确保在实际操作时没有遗漏任何东西:)
答案2
不，抱歉。我找不到不停机移动数据库的方法。数据库里有什么内容是你连一个小时都无法投入的，比如复活节假期？
答案3
这是一个非常复杂的方法......（几乎）
- 将服务器 P2V 到 VMware 集群。无停机时间。
- 创建第二台服务器并创建主动/被动集群。
- 将被动节点升级到 2008 并进行故障转移。
- 利润？
显然，这里的所有内容都需要测试，还有很多详细步骤没有提到。
或者 - 让管理层同意停机，并提前向客户公布。然后反复练习和测试升级！
向管理层解释试图以“低成本”实现这一目标的技术困难。这是您在首次构建完整的 27x7 架构时构建到系统中的东西。
即使最大的系统也有计划停机。你更需要担心的是计划外停机。
答案4
恐怕仅使用 SQL Server 无法实现这一点。我过去曾使用过一款名为 Double Take 的产品，它允许您将数据库克隆到另一台服务器，然后在方便时进行故障转移。
当服务在新机器上启动时，故障转移过程仍会导致一些停机时间。