问：许多数据库管理员似乎趋向于延迟更新其数据库补丁，但是与实施补丁致使的数据库崩溃或与其他应用程序的不兼容相比，推迟采用补丁的风险不是一样多吗？对于数据库补丁管理工作来说，什么样的流程才最佳呢？
 
    答：假如你遵从了安全周期管理的最佳实践，就不会发生补丁更新后的宕机或是对其他应用程序造成危害。更新你的数据库补丁与更新操作系统补丁没有不同之处；这需要按照文档化的流程来执行，以保证任务按照顺序和预定的方式执行，并且没有遗漏或未完成的事项。

    首先，你需要理解你的数据库供应商所操作的补丁程序。举例来说，Oracle Corp.是按季度发布严重补丁更新的。微软则是在每月的第二个星期二提供安全更新的。但是补丁更新并不是强制性的。某个漏洞带来的威胁也许在你的风险容忍范围内，同时还有一些补丁跟你的环境不相关联，所以测试和安装所有可能的补丁是不必要的。漏洞的严重程度是计算补丁的重要性的关键，也是修复前的这一漏洞曾被攻击过的存在证明。你可能想考虑使用Secunia Enterprise Vulnerability Manager或是 Secunia Vulnerability Intelligence Feed产品，因为他们的漏洞报告清晰地显示了每个漏洞的严重程度，并不是所有的厂商的警报都能达到如此程度。

    在所有的数据库补丁管理流程中，有一点非常重要，那就是获取一份系统清单，列出你所有设备的优先级，这样在评估某一补丁所修复的漏洞是否对你的现有环境造成威胁时，这些信息是随时可用的。一旦你决定需要部署某一补丁，你得区分它是一个常规的还是紧急的更新。你可以暂停一些不太紧急的补丁的测试工作，在时间允许的情况下再进行部署。

    测试是补丁部署的一个重要方面，特别是对数据库来说，因为补丁能够改变其他程序所依赖的服务或功能。不幸的是，实际测试过程没有真正的捷径。你不能批测试补丁。如果测试过程没有满意的结果，你必须在进一步的行动前找到这一问题的根本原因。一次性安装几个补丁会更难。向相关的网上新闻讨论寻求帮助和指导是很有用的，你会查到其他人对这一特定补丁的部署经验。

    通过完成补丁测试，你能够保证这次部署的可预见的结果。你在测试中每发现一个问题，在生产环境中就将少纠正一个问题。在可能的情况下，你最先开始部署的对象应该是不太重要的系统，而且如果它们能按预期正常运行，你就可以继续将更新推广到所有的系统。这种方法对整个过程增加了进一步的安全保障。最后，你要确保已将你的决定记录在文档中，包括安装或是拒绝安装某个补丁。这样以来，你就能够向你的审计人员保证漏洞已被识别并且相应的补丁已被安装完毕。

    虽然大多数的大型供应商都已经引入了补丁发布时间表来帮助改进数据库补丁管理流程的可管理性和可预见性，可补丁测试是需要时间和资源的。如果可能的话，可考虑使用虚拟化，因为他提供多测试配置部署的功能，反映真实生产环境。这样你的补丁测试条件将会更贴近真实的环境。