验证 SQL Service Pack 安装还有多远？

Question

将 Service Pack 应用到生产 SQL 服务器时，我通常有一个大约 30 分钟的计划停机时间窗口。

之前被咬过，并发现所需的前提条件（如补丁）没有到位，这可能会使您的停机时间窗口增加几分钟（并且可能会使您越过窗口，或强制重新安排时间）。

现在，当更新处于规划阶段时，我将 Service Pack 移动到服务器并通过“检查正在使用的文件”或“准备更新”进行测试。我在那时取消了更新，并且在更新过程中尽可能自信，我不会超过计划的停机时间窗口。

您可以从任一屏幕取消，但由于“准备更新”上的“更新”按钮与“检查正在使用的文件”上的“下一步>”按钮位于同一位置，因此意外双击可能会意外启动更新，在验证时。

我的问题：

我应该在“检查正在使用的文件”还是“准备更新”时停止验证？我是否在“检查使用中的文件”结束时验证了所有我能做的事情？“准备更新”是否会增加验证的价值？

Answer 1

理想的情况是拥有一台在操作系统和其他软件方面与生产环境完全匹配的服务器，您可以在其上先执行更新。这样你就知道所有需要的东西。

这最好是一个可以创建快照的虚拟机，因此如果您遇到并修复问题，您可以恢复到快照并重新开始更新的过程。重复此操作，直到升级过程正常运行并且您知道重新启动要求等，然后计划在生产中重复该过程。

如果您拥有开发/测试虚拟机之一，那么它们可能是理想的选择（即，如果您的开发/测试/发布过程不仅仅是“将代码组合在一起并直接投入生产”！）。通过这种方式，您基本上将服务包与您自己的错误修复或功能发布之一相同，这意味着您可以在将服务包应用于测试环境后对应用程序执行完整的回归测试（以确保 MS '没有引入任何错误或对您的应用程序所依赖的未定义行为的更改 - 或者他们尚未修复您的代码所依赖的错误！）。

显然，这种“理想”可能比其他选择更耗时……

Answer 2

我应该在“检查正在使用的文件”或“准备更新”时停止验证吗？在“检查使用中的文件”结束时我是否已验证了所有内容？

只需继续单击NEXT并应用服务包，您就可以安全地忽略此过程。检查files in use process是为了处理最终用户在应用服务包后不想重新启动的情况，在这种情况下，您需要确保所有此类进程都已停止，但无论如何，我强烈建议启动您正在应用的 Windows 计算机/节点服务包。

唯一可能发生的事情是成功升级后您需要启动 Windows 计算机。这本身不会导致 SP 失败

进入“准备更新”会给验证增加价值吗？

准备更新基本上显示了您将要更新的所有功能，仅此而已。您必须单击update此处，它不会添加任何值，只会显示您选择的配置