成熟的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的价值。