我正在学习如何pipe理我公司的数据库，虽然我对数据库的使用有很好的理解，但我可以确定地看到，pipe理数据库是完全不同的。
我的位置是我们是一个小团队，我们以前没有人pipe理数据库服务器，如果出现问题，我们将修复它，但没有主动维护。
我正在编写一些我们应该使用的最佳实践的文档，修复发现的问题以及防止发生问题的方法。 目前，我的经理们不愿意修补数据库服务器（操作系统和数据库软件），我认为这是疯狂的，但他们是高级和“最好的”。
我们的环境是Server 2003，有5个数据库服务器，3个MSSQL 2005和2个MSSQL2000。 数据库服务器都是私有的，不会面对互联网。 他们在我们的防火墙后面。 他们不公开的事实是pipe理者不愿意修补服务器的原因。
我想知道的是：
人们如何pipe理SQL Server和OS的修补程序？ 是否有必要修补它们？ 清单项目什么时候应用补丁程序（等待几天后，等待遇到和logging的问题，其他）？ 列出您可以推荐的白皮书，技术文档，好博客等。 任何帮助将不胜感激，因为我相信他们应该补丁至less最近的SP，也许是最近的第二次Cummalative更新，但我没有任何forms的最佳实践，以此为基础，这将是最热衷于学习人们做什么
如果你需要更多的信息，请不要犹豫与我联系。
谢谢，
利马
我的build议是，给他们补丁。 正如我们在今天看到的那样，恶意内容可以并且将会进入您的内部networking。 与此相反的思想只是朴素而不负责任的。 Slammer白天让人大开眼界，为了防止这种情况，已经做了很多事情来lockingSQL，但是新的威胁引发了等等。
关于数据库服务器，它几乎是相同的，你的其他服务器。 把一个安装计划放在一起，制定一个回滚计划，在testing环境中应用这些补丁，在生产环境中舒适地使用补丁。 应该与其他所有补丁一起评估优先级。
我同意，不补丁是疯狂的。 如果您的业务依赖于这些系统，并且由于pipe理SQL Server不舒服而无法进行修补，则可以让某人进入SQLpipe理培训。
编辑：对于您的评论，在您的testing服务器上尽可能地复制您的生产环境。 要testing您的修补程序过程，请在testing服务器上执行整个过程。 如果失败了，那么还有一个体面的或更好的机会，也会在生产中失败。 在testing环境中的补丁稳定之前，不要补丁生产。
在应用程序服务器上，您还需要确保应用程序在安装补丁程序后继续按照devise工作，因此您不仅要确保系统本身能够存活补丁程序，还要运行应用程序的function。
修补数据库应该与修补任何东西没有区别。 testing，然后部署。
显然，这需要一个testing系统来打补丁，但是如果这些数据库和组织中的老年人认为是一样重要的话，我相信他们已经有testing系统已经部署，并且已经准备好进行testing了。 ;）
当人们拒绝修补系统时，我总觉得它很有趣，因为它们是“内部的”，因此是安全的。 我想你的局域网上没有可以访问互联网的计算机，而且也没有办法用一个能够触发数据破坏的软件来做一些事情，服务器在未修补软件的原始版本中崩溃。
同意以上关于“是的，你必须打补丁，是的，先testing补丁”。
不过，我会注意到，正如你提到你的团队是数据库pipe理的新手，我发现MSSQL比Windows更less需要修补程序。 对我来说，我把windows update设置为在我们的testing机器上“只下载”，然后有一天晚上当我们感到勇敢的时候，我们告诉Windows进行安装，重启，然后运行我们的回归testing。
生产机器的设置方法相同 – 只下载，不要安装补丁。 所以如果我们的testing在testing机器上顺利运行，我们会在第二天凌晨5点醒来，并告诉生产机器安装补丁，让它重新启动，然后做一些简单的testing，以确保应用程序仍在工作。 我们平时每周不要超过一次，因为我们不喜欢在早上五点醒来，但是当然如果这个补丁的描述听起来exception可怕，那么我们就会冲上去。
让人惊讶。 那么你一定要修补它们，因为SQL Slammer等人在防火墙的操作方式是这样的。不pipe怎样，“回到当天”，我会手动地将它们从在备份服务器上testing后出现的SP中手动修补。 现在，我只是让“微软更新”捕获任何SQL Server相关的修补程序。 似乎工作得很好。