你好穆尼斯，

如果您是在物理机或虚拟机管理程序（VMware，Hyper-V，KVM，XEN等）上运行Windows 2008 R2（我想是指2008 R2），您没有写过吗？

您没有提到数据库供应商吗？

但是您写道：" ...环境是至关重要的生产..."

这就是您问题的答案。 如果启动Windows Server 2016 Setup.exe，并且由于任何原因将无法正确升级，那么您将失去生产系统！

如果您使用的是群集，则无法通过就地升级对其进行升级（仅当所有群集节点均基于Windows Server 2012 R2时）。

如果您已经在运行Windows虚拟化，我通常建议使用就地升级方法，那么您可以在就地升级之前创建快照，以防万一它不起作用，那么您很快就会回来 组态。 还有一件事：必须对此进行测试！

请勿在生产系统上进行测试。

最诚挚的问候，

Kalle

嗨，穆尼什，

过去，我是通过就地升级来升级HP服务器的。 确保首先卸载（！）防病毒解决方案。 然后进行就地升级，然后按Windows Update，直到完全修补为止，然后不要忘记为芯片组驱动程序，智能阵列，HP ILO，HP管理等安装最新的HP服务支持包（!!!）。

关于MS SQL 2012：Microsoft不支持通过就地升级的升级方法。 这并不意味着它不起作用。 这意味着，当您遇到问题时，Microsoft会说："不支持。"

群集：Windows setup.exe在检测到此主机是故障转移群集的一部分时，将拒绝就地升级。 因此，您无法升级Windows 2008、2008 R2或2012上的群集节点。如果主机位于Windows 2012 R2上，则可以将其就地升级到2016。这在注释2419847中进行了说明。 它工作得很好（除了删除ASCS实例的启动服务的问题外……请参见注释）。 自2016年以来，Microsoft就针对此问题打开了一个错误案例...

因此，对于Windows 2008 R2群集没有就地升级的解决方案。 Windows setup.exe将不允许升级。

最诚挚的问候，

Kalle

Munish，

还请参见注释 1494740 （从较早的Windows迁移SAP系统 向较新版本发布）。 需要注意的一件事是，在过去，如果安装了任何第三方应用程序，则Microsoft不支持Windows Server 的就地升级。 在这种情况下，SAP将成为第三方应用程序。 因此，仅非生产系统支持使用SAP对Windows进行就地升级。 我认为，至少在最新版本的Windows Server中，Microsoft的限制现在已经放宽，并且从Notes中发现，群集服务器就地升级的限制似乎也已经放宽了（尽管此过程更加复杂） ）。

也就是说，仍然建议至少考虑系统迁移而不是就地升级。 升级操作系统可能会对您的应用程序设置产生影响，尽管通常可以正常进行，但如果应用程序是本身是"全新安装"的操作系统之上的"全新安装"，则可能会更安全（并且更可预测）。 "

此外，操作系统升级是硬件更新的绝佳机会。 您没有提到您是在虚拟硬件上还是在物理服务器上，但是如果您在物理上，这是您用更新更快的模型替换这些模型或考虑虚拟化的巨大机会。

您提到总体停机时间是一个主要问题，当然是这样。 但是，我不确定Windows就地升级是否会比系统副本的"分离/附加"或"备份/还原"版本快得多。 实际上，我认为它可能会更慢。 当然，4 TB是要移动的大量数据，但是首先，您可以通过一些选定的修剪（很多有关此说明）或归档（如果尚未删除）来减小数据库的整体大小。 ）。 而且，如果您的数据库文件总大小中的大部分都被数据库的可用空间所占用，那么备份/还原方法（或在复制之前减少可用空间，然后在以后增加可用空间）可能会减小文件的大小。 复制过来。

在这种情况下，您可以在旧系统仍在运行的同时，在新硬件上完成新OS和DBMS的安装，然后仅在最后一刻关闭生产性操作，分离数据库（您不必 提及您正在使用的DBMS，所以我以SQL Server为例），将其复制，附加，然后通过系统复制过程运行SWPM"目标系统"安装。 而且，如果在系统复制过程中出现问题，此过程将使您保留原始系统，以防万一。

干杯，
马特

感谢您分享博客，它很棒。 非常详尽的博客。 我也想接受您的答案，也可以接受，但是我只能接受一个答案作为正确答案。

我发现您的答案非常有用且相关，我会根据您的建议为我的POC服务。 我一定会尝试的。 谢谢你的时间。

感谢与问候

牧师

你好穆尼斯，

对于操作系统升级/迁移，最好使用同类系统复制过程（认为数据库与目标上的源数据库相同）。

此致

Manjunath

你好Manjunath，

感谢您的回复。 是否有人在生产系统（集群和独立环境）上完成此操作

问候

Munish

Hello Manjunath，

感谢您的回复。

我知道同质系统副本是更好的解决方案。 但是在我的情况下，数据库大小大于4 TB，以进行系统复制，所需的预期停机时间将无法在生产系统上使用。 所以这是最后一个选择。 解决方法是，我们可以继续进行新的系统构建并稍后刷新数据库。

我说过，一些SAP Notes建议我们可以这样做。

除了上述解决方案之外，我还在寻找就地操作系统升级的建议。 无需新SAP服务器构建或系统复制的额外工作，即可解决所有问题。 它将照原样完成。

致谢

Munish Jindal。