Microsoft 的SQL Server 升级技术指南引用了两种升级路径：in-place 和 side-by-side。
我没有看到第三个明显更可行/更方便的选项，即对服务器/SQL Server 的克隆版本进行就地升级。这就是我的意思：为什么不克隆有问题的服务器，然后执行就地升级，如果一切顺利，那么可以简单地创建一个别名，然后让所有应用程序和用户自动重新路由到新服务器. 这有什么缺点吗？有什么我没有看到的吗？使用别名来重定向用户和应用程序不明智吗？
假设：
- 我假设这是一个简单的升级案例：没有镜像，没有复制等。这只是一个服务器，有许多需要升级的数据库。
- 我假设支持直接升级。具体来说，在这种情况下，它是从 SQL Server 2008R2 到 2016。
由于 SQL Server 的主要原则之一，即事务一致性，在执行克隆操作时很难正确执行，因此我建议不要按照您建议的方式使用克隆来执行升级。在 SQL Server 服务正在运行并接受客户端连接时克隆底层计算机可能会导致克隆包含无效数据。如果您可以在 SQL Server 服务关闭时创建计算机的克隆，则您建议的解决方案可能是执行升级的可行方法。话虽如此，我倾向于不使用 VM/SAN 克隆，因为它出现严重错误的可能性非常高。正如任何物有所值的 DBA 都会告诉您的那样，不必要的风险是不可接受的。
话虽如此，使用 DNS 别名是从服务器中抽象出机器名称的绝佳方式，也是 Windows 故障转移群集用来将客户端定向到群集 SQL Server 安装中的活动节点的方法。
在您拥有 DNS 别名的情况下实现升级的高级步骤如下所示：
确保 DNS 别名具有较短的 TTL 值，这将允许客户端足够快地“看到”别名指向的 IP 地址的更改，以便在所需的时间段内连接到新机器。我会考虑 1 分钟。
根据需要使用最新版本的 Windows 和 SQL Server 创建新计算机或 VM。
备份旧服务器上的数据库，然后将它们恢复到新服务器上。
针对新服务器测试所有软件/网站/应用程序以确保兼容性。
一旦测试完成，并且您对新服务器感到满意，请禁用与旧服务器的用户连接，以确保没有人进行不会在新服务器上看到的更新。
对旧服务器上的数据库进行最终备份，然后将这些数据库还原到新服务器上。
修改 DNS 别名以指向新服务器的 IP 地址。
此时，客户端应用程序应该能够使用新服务器，而无需在客户端进行任何更改。
上述步骤假定您有一个足够长的升级窗口，以便您执行升级过程中涉及的数据库的备份和恢复。如果您没有升级窗口，即您需要 99.999% 的正常运行时间，您将需要考虑使用镜像、日志传送或故障转移集群来最大限度地减少切换到新机器期间的停机时间。