我正在学习如何管理公司的数据库，虽然我对使用数据库有相当好的了解，但我可以肯定地看到管理数据库是完全不同的。
我的立场是，我们是一个小团队，以前没有人管理数据库服务器，如果出现问题，我们会修复它，但没有主动维护。
我正在整理一些我们应该使用的最佳实践、发现的问题修复以及防止问题发生的方法的文档。目前，我的经理不愿意修补数据库服务器（操作系统和数据库软件），我认为这是疯狂的，但他们是资深人士，而且“最了解情况”。
我们的环境是 Server 2003，有 5 个数据库服务器，3 个 MSSQL 2005 和 2 个 MSSQL2000。数据库服务器都是私有的，不面向互联网。它们在我们的防火墙后面。它们不是公开的，这是管理人员不愿意修补服务器的原因。
我想知道的是：
人们如何管理 SQL 服务器和操作系统的修补？是否有必要修补它们？列表项您何时应用补丁（立即应用，等待几天后遇到问题并记录下来，其他）？列表项您可以推荐的白皮书、技术文档、优秀博客等。任何帮助都将不胜感激，因为我认为它们应该至少修补到最新的 SP 和第二个最近的累积更新，但我没有任何形式的最佳实践来作为基础，因此非常想了解人们的做法。
如果您需要更多信息，请随时与我联系。
谢谢，
利马
答案1
我的建议是：是的，修补它们。正如我们今天所看到的那样，恶意内容能够并且将会进入您的内部网络。与此相反的想法简直是幼稚和不负责任的。Slammer 在过去令人大开眼界，并且已经做了很多工作来锁定 SQL 以防止这种情况发生，但新的威胁出现了等等。
至于数据库服务器，它与其他服务器基本相同。制定安装计划，制定回滚计划，在测试环境中应用补丁，在方便时在生产环境中应用它们。它们应与所有其他补丁一起评估优先级。
我同意，不打补丁是疯了。如果你的企业依赖这些系统，而他们又因为不习惯管理 SQL Server 而不打补丁，那么就找人接受 SQL 管理员培训吧。
编辑：针对您的评论，您在测试服务器上尽可能地复制生产环境。要测试您的修补过程，您需要在测试服务器上执行整个过程。如果失败，那么在生产中失败的可能性很大。在测试环境中的补丁稳定之前，不要修补生产环境。
在应用服务器上，您还需要确保您的应用在安装补丁后能够继续按设计运行，因此您不仅要确保系统本身能够在补丁安装后继续运行，还要确保应用程序的所有功能都能正常运行。
答案2
修补数据库应该与修补任何其他东西没什么不同。测试，然后部署。
显然，这需要先修补一个测试系统，但如果这些数据库像组织中的高层人员认为的那样重要，我相信他们已经部署了测试系统并准备好进行测试。;)
我总是觉得很有趣的是，人们拒绝修补系统，因为它们是“内部专用”的，因此是安全的。我猜你的局域网上没有可以访问互联网的计算机，也不可能用某个软件做任何事情，从而触发未打补丁的原始软件版本中数据损坏、服务器崩溃的错误。
答案3
同意上述关于“是的，您必须修补，是的，先测试补丁”的观点。
不过，我要指出的是，正如您提到的，您的团队是数据库管理方面的新手，我发现 MSSQL 需要的补丁频率低于 Windows。我的做法是，我将测试机器上的 Windows 更新设置为“仅下载”，然后某个晚上，当我们感到有勇气时，我们会告诉 Windows 继续安装、重新启动，然后运行我们的回归测试。
生产机器的设置方式相同 - 仅下载，不安装补丁。因此，如果我们的测试在测试机上顺利进行，我们会在第二天早上 5 点醒来，并告诉生产机器也安装补丁，让它重新启动，然后进行一些简单的测试以确保应用程序仍在运行。我们通常每周这样做不超过一次，因为我们不喜欢在早上 5 点醒来，但如果补丁的描述听起来异常可怕，我们当然会匆忙完成。
答案4
哎呀。你肯定想修补它们，因为 SQL Slammer 等在防火墙后面运行，所以……无论如何，“过去”我会在备份服务器上测试后，从不时出现的 SP 中手动修补它们。现在我只是让“Microsoft Update”捕获任何与 SQL Server 相关的补丁。似乎工作得很好。