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