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