如何做一份完善的补丁分析

成熟的IT企业,往往会有自己的补丁计划。如一年打几次补丁,打哪一个补丁。

在补丁之前,需要进行补丁分析,一份比较完善补丁分析,往往能帮助企业未雨绸缪,提前将可能引发的问题先解决掉,保证生产的稳定和安全。

在这里,我和大家分享一下,如何做一份比较完善补丁分析。这可能是一篇方法论的文章,但常言道,说起来容易做起来难。虽然我能告诉了你方法论,但是在实际操作的过程中,我相信你更愿意花钱买服务。因为要阅读大量的文档,查询各种关键字,分析各种触发条件,才能做出一份比较完善的补丁分析。一次补丁分析,耗时1~2周,看几百篇文档是经常的事情。

High Level Step:
初级要求:
(1)选Release
(2)选Patch Set
(3)选PSU
高级要求:
(4)查Patch Set的known issue
(5)查PSU的recommended patch
(6)查影响性能和wrong result的补丁
(7)查影响SPM的bug
(8)查高风险的Patch
(9)查特殊平台的Patch
(10)结合历史SR查询
(11)结合别的客户SR
(12)冲突分析

(1)选Release,Doc ID 742060.1
当然了,首先你得选一般版本,是11g还是12c,是11gR1还是11gR2。你需要Release Schedule of Current Database Releases (Doc ID 742060.1)这个文档。你得去看每个release的发布时间,Patching end date,以便于你更好的获得Oracle的支持。我是指研发的支持。因为过了标准服务期,在没有买延伸服务期的情况下,你要让研发出一个补丁几乎是不可能的事情。当然,额外的情况也有,比如加入PUMA program(Proactive Upgrade and Migration Assistance),这有可能获得额外的支持。 btw说一下,PUMA开发出来的补丁,一定要用最新的opatch工具打,别用$ORACLE_HOME下原生的那个。

(2)选Patch Set,Doc ID 1454618.1
说到补丁分析,你首先会想到的肯定是这个文档:Quick Reference to Patch Numbers for Database PSU, SPU(CPU), Bundle Patches and Patchsets (Doc ID 1454618.1) 。这个文档标识了从8.1.7.4到最新的12.1.0.2的所有补丁号,包括Patch set号,PSU号,GI PSU号,SPU号,Bundle Patch号,OJVM Patch号。很多时候,客户问我,我要打11.2.0.4.5的PSU,这个补丁号是多少,我往往会推荐这个文档。




但是需要注意到是,作为补丁分析的入口,这个文档是for一般DB的,不是Exadata的。这里,以及后面的讨论我们都以一般DB为例,先不提Exadata。如果是Exadata的补丁,那是另外的一套体系,请参考Exadata Database Machine and Exadata Storage Server Supported Versions (Doc ID 888828.1)

(3)选PSU,Doc ID 756671.1
当你选好了Patch Set,你肯定想知道,基于这个patch set,我应该打哪个PSU?这里有一篇文档可以指导你:Oracle Recommended Patches -- Oracle Database (Doc ID 756671.1)。这个文档里面,不仅有PSU,还有OJVM的推荐补丁,还有一些Miscellaneous Fixes的补丁(如AIX下的),还有些EBS的补丁。



这里提一下PSU和SPU的选择,这其实是打Patch的两条路,一旦选择一条路,就不能同时走另外一条路了,也就是说,一旦我选择打PSU,我不能在PSU的基础上再打SPU,或者我一旦选择了打SPU,我不能在SPU的基础上再打PSU。

而SPU主要是安全性方面的补丁,PSU不仅包含安全性方面的内容,还包括功能性方面的修补,且又不是大功能的改变(如12.1.0.1这个patch set还没有in memory option,到12.1.0.2这个patch set才有in memory option这个功能)。对于客户来说,打PSU是low risk,high value的选择。

到了这里,一般的客户的补丁分析,就算结束了。打上了Patch set,打了PSU或SPU,就算完成任务了。但是对于高级的客户,这才是刚刚搭好了一个框架。

(4)查Patch Set的known issue,如Doc ID 1683799.1
从这里开始,就没有一篇汇总的文章让你看了,你要各个Patch set找对应的Known issue的文章。如12.1.0.2 Patch Set - Availability and Known Issues (Doc ID 1683799.1),如11.2.0.4 Patch Set - Availability and Known Issues (Doc ID 1562139.1)等等。

在这个文档中,你可以看到当前你选择的那个Patch Set的known issue,包括General Alerts / Issues的,包括Issues introduced的,你要一个一个bug去核对,bug的文档,我们叫做“点八文档”,因为bug的文档命名往往是以.8结尾,如Bug 20881450 -Doc ID 20881450.8,如Bug 20144308 Doc ID 20144308.8。随着时间的推移,Patch Set的known issue的列表会越来越长,你要核对的bug也越来越多。这就是耗费体力的地方。

我们要核对在这个Patchset上的所有known issue的bug是否在当前的PSU已经修复,是否是发生在特定的平台,是否已经有Patch了还是只是Tracking Bug Patch,是否下载次数很低,Linux下载了几次,Solaris下载了几次,AIX下载了几次,HP IA下载了几次,如果下载次数低,是否考虑将该bug的patch排除在外(因为后面涉及到一个补丁冲突的问题,越多的one-off patch,就越容易发生冲突的可能。)

而且,你还是只是你第一次做该Patchset 上的PSU的分析,如果你做下一次PSU,你还要考虑上述PatchSet的known issue是否在本PSU已经修复,没有修复的话,上次known issue的bug是one-off patch还是merge patch,如果是merge patch,在本PSU中不可用,那么就只能再申请本PSU的merge patch了。这也是你经常看到Merge Patch xxxx on top of 11.x.x.x.x 这样的request。这也是我在上面说的,如果下载次数低,说明遇到的可能性不大,可以选择不打这个patch。

(5)查PSU的recommended patch,如Doc ID 2076280.1
Patch Set会引入问题,PSU同样也会引入问题。此时,你就要去查一个叫做Oracle Database Patch Set Update 12.1.0.2.160119 Known Issues (Doc ID 2076280.1)的文档,在这个文档里面,可以看到该PSU的known issue,会有对应的Patch或者workaround。所以打了对应版本的PSU,也需要关注PSU的recommended Patch。



注意,有DB的PSU known issue,自然也有GI的PSU known issue。

一般情况下,刚刚出来的PSU没几天,这个文档上的known issue往往显示为空,因为还没有人上报issue。所以我们会建议客户不打最新的PSU,拖后几个月,看看PSU的known issue上是否有patch,即等该文档完善了PSU的recommended Patch之后再打。

另外还有一种情况,就是PSU已经很靠后面了,如10.2.0.5.18,已经到了PSU18,问题都修复的差不多了,即使等待PSU出来好久,也看不到known issue了。

(6)查影响性能和wrong result的补丁,如Doc ID 2034610.1
关键字:Poor Performance or Wrong Results ,此时你会发现一篇文档:Things to Consider to Avoid Poor Performance or Wrong Results on 12.1.0.2 (Doc ID 2034610.1),恩,这里面的补丁也很重要,需要打上。

注意,这个文档上可能会分不同的OS平台,如AIX平台,需要区分平台打上。另外,这个文档上不仅仅有bug的patch,可能还会说明一些需要设置的setting,这个在安装的时候,也建议根据文章来设置。

(7)查影响SPM的bug,如Doc ID 2035898.1
SPM也可性能密切相关,关键字:Avoid Problems with SQL Plan Management。你会找到Patches to Consider for 12.1.0.2 to Avoid Problems with SQL Plan Management (SPM) (Doc ID 2035898.1)。

(8)查高风险的Patch,如Doc ID 1914998.1
在MOS的Patches & Updates菜单,有一个Advanced搜索,选好版本和平台,增加description为“Crash”,“leak”,“spin”,“hang”你会进一步得到很多高危的bug,如Process Spins and/or ASM and DB Crash if RAC Instance Is Up For > 248 Days (Doc ID 1914998.1)

(9)查特殊平台的Patch,如Doc ID 2022559.1
有些问题,只是发生在某些特定的操作系统下,需要结合操作系统平台的关键字,进行查找。如你可以找到Recommended Bundle for AIX 12.1.0.2. with critical fixes (Doc ID 2022559.1)

(10)结合历史SR查询
结合之前遇到的问题,开过的SR,是否已经有给了Patch,这个Patch在当前版本的PSU中是否包含,是否已经被当前PSU修复,如果是,那么就采用该PSU,如果仍然没有修复,由于是本企业已知问题,需要慎重对待,需要查是否在本PSU上有one-off,如果有冲突,需要申请merge patch。

(11)结合别的客户SR
最后,如果你购买了原厂服务,原厂的工程师是可以看到别的客户的SR的,也就能查到下面的一个文档:Documented Database Bugs With High "Solved SR" Count (Doc ID 2099231.1 INTERNAL)。这个文档上记录了Prob为四级,即超过50个SR遇到了这个bug的问题。所以,还可以结合其他客户遇到的bug,遇到的问题,来提前帮你预防这些bug。

最后,当你查阅了那么多文档,做出了一份比较完善的补丁分析,这还不是终点。还需要将这些补丁进行冲突分析。目前就客户自己而言,已经可以MOS补丁冲突检测工具https://support.oracle.com/epmos/faces/PatchConflictCheck 来进行检测。而原厂工程师,可以用ARU工具http://aru.us.oracle.com:8080/ARU/ConflictCheck/get_form来进行检测。

检测完毕后,就要看哪些冲突,如何解决,是否有替换补丁,是否需要申请merge patch等等。

怎么样,看到这里,你应该相信我之前说的补丁分析是个体力活吧。但是正是因为如此细致缜密的工作,才体现出其工作的价值。

提前做好了预防,保证日常运行的稳定与安全。这就是DBA的价值。

相关文章

3条评论

  1. 真是好样的.
    你们给移动推荐了几十个没碰到的小补丁.后来陆续累积到几百个.后来真碰到问题了,然后呢,新补丁和无数的已经打上的补丁冲突.merge patch花了好几个月才做出来.
    Good job!

  2. re a: 这位兄弟对补丁分析的怨念很重呀。

    补丁分析就像打疫苗,不能说打了疫苗都是没用的疫苗,生得病都是没打到疫苗。

    我个人认为,几十个补丁的数量还能接受。几百个的话,就要看看是否所有的补丁都有必要,是不是某些one-off已经在当前版本的PSU中已经修复了?因为每次都PSU都会修复大量上个版本没有修复的bug。这就是我所说的第四点的第三段。

    另外,做完补丁分析,我们还会和客户一起review补丁分析的结果,一起看看结合客户的环境,哪些是需要的哪些是不需要的。

    至于merge patch的时间长,我同意有些merge patch确实需要太长的时间。但我相信这可能是几百个one-off在一起,增加了分析的难度。我们不会给你一个分析不彻底的merge patch,也不会给你没有测试过的merge patch。这些都需要时间。

    最后再重申一下我的观点,补丁分析有个度,既要权衡覆盖面,又要权衡补丁数量。

  3. 对于像绿盟扫出的漏洞,根本就不管是不是补丁有必要。客户就要求你去打。最后就是没完没了!哎!!!

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据