目 錄
▇1、ORACLE資料庫版本知識
▇2、看看自己的資料庫還有沒有支援服務
▇3、看11.2.0.3版本各PSU的釋出時間與解決BUG數量清單
▇4、看11.2.0.4版本各PSU的釋出時間與解決BUG數量清單
▇5、資料庫版本定期檢視與更新标準化工藝
1、oracle資料庫版本知識
第一位數字：
Major DatabaseRelease Number（主要的資料庫版本号）：
第一個數字是最一般的辨別符。這是一個重大的新版本，它包含了重要的新功能的軟體。
第二位數字：
DatabaseMaintenance Release Number（資料庫的維護版本号）：
第二數字代表一個維護版本水準。也代表包含一些新的功能，例如12C R1、12C R2，期中的R1、R2在oracle database release number中展現在第二位，被展現成12.1、12.2
第三位數字：
Fusion MiddlewareRelease Number（融合中間件的版本号）
第三數字反映了Oracle融合中間件的release級别，在9i以前版本中有此位為非0的版本，在9i以後，筆者沒有見過第三位數字為非0的版本。
第四位數字：
Component-SpecificRelease Number（特定元件版本号）
第四位數字辨別一個特定的元件級别，此版本同樣會包含重大功能的釋出。
第五位數字：
Platform-SpecificRelease Number（更新檔集号）
第五位，就是傳說中的PSU了，oracle每三個月釋出一個PSU，将所發現的BUG的更新檔合并在一起，打成一個包。該位數字不會存在新功能的釋出，隻是為了解決BUG而生。
2、看看自己的的資料庫還有沒有支援服務
| Oracle 資料庫各版本支援服務時限 | |||||
| 大版本 | 目前更新檔集 | 下一更新檔集 | 标準服務結束日期 | 擴充服務結束日期 | 注釋 |
| 12.1.0.X | 無 | 12.1.0.2 | - | - | 基版本為 12.1.0.1。 |
| 11.2.0.X | 11.2.0.4 | 無 | 2015年1月 | 2018年1月 | 基版本為 11.2.0.1。 |
| 擴充服務第一年（2015年1月到2016年1月）的費用取消 | |||||
| 11.2 每一個更新檔集都是完整安裝程式包 | |||||
| 11.2.0.1 在2011年9月13日後停止提供新的更新檔 | |||||
| 11.2.0.2 在2013年10月31日後停止提供新的更新檔 | |||||
| 11.2.0.3 在2015年8月27日後停止提供新的更新檔 | |||||
| 11.1.0.X | 11.1.0.7 | 無 | 2012年8月 | 2015年8月 | 基版本為 11.1.0.6。 |
| 11.1.0.7 是 11.1 的最終更新檔集 | |||||
| 10.2.0.X | 10.2.0.5 | 無 | 2010年7月 | 2013年7月 | 10.2.0.5 是 10.2 的最終更新檔集。 |
| 自2013年8月至2015年7月提供有限的擴充服務 | |||||
| 免費的擴充服務在2011年7月31日結束。 | |||||
| 10.1.0.X | 10.1.0.5 | 無 | 2009年1月 | 2012年1月 | 10.1.0.5 是 10.1 的最終更新檔集。 |
| 10.1 的擴充服務已經結束 | |||||
| 9.2.0.X | 9.2.0.8 | 無 | 2007年7月 | 2010年7月 | 9.2.0.8 是 9.2 的最終更新檔集。 |
| 自2010年7月至2012年7月提供有限的擴充服務。 | 免費的擴充服務在2008年7月31日結束。 |
從上面表格來看，10.2版資料庫（10.2系列的終極版10.2.0.5），于2015年7月就已經停止了更新檔服務，如果您還依然使用此版本，在遇到新問題時，就準備“自生自滅”吧
而11.2系列，目前很多機關在使用的11.2.0.3版，也在2015年8月27日後停止提供新的更新檔，如果您還依然使用此版本，在遇到新問題時，就準備“自生自滅”吧。但是11.2.0.4（11.2系列的終極版）在2020年也将會停止新更新檔服務。
3、看11.2.0.3版本各PSU的釋出時間與解決BUG數量清單
梳理各PSU解決的BUG及其總數量的思路，得益于白鳝（老白）先生的指導。
| ORACLE 11.2.0.3各版本PSU釋出日期與解決BUG數量 | ||||||
| Oracle 版本号 | database PSU号 | GRID PSU号 | 釋出日期 | 解決資料庫的bug數量（個） | 解決GRID的bug數量（個） | 共解決的bug數量合計（個） |
| 11.2.0.3.0 | 2011年9月 | |||||
| 11.2.0.3.1 | 13343438 | 13348650 | 2012年1月 | 21 | 93 | 114 |
| 11.2.0.3.2 | 13696216 | 13696251 | 2012年4月 | 26 | 54 | 80 |
| 11.2.0.3.3 | 13923374 | 13919095 | 2012年7月 | 33 | 65 | 98 |
| 11.2.0.3.4 | 14275605 | 14275572 | 2012年10月 | 36 | 70 | 106 |
| 11.2.0.3.5 | 14727310 | 14727347 | 2013年1月 | 42 | 26 | 68 |
| 11.2.0.3.6 | 16056266 | 16083653 | 2013年4月 | 42 | 33 | 75 |
| 11.2.0.3.7 | 16619892 | 16742216 | 2013年7月 | 50 | 18 | 68 |
| 11.2.0.3.8 | 16902043 | 17272731 | 2013年10月 | 57 | 26 | 83 |
| 11.2.0.3.9 | 17540582 | 17735354 | 2014年1月 | 53 | 21 | 74 |
| 11.2.0.3.10 | 18031683 | 18139678 | 2014年4月 | 33 | 33 | |
| 11.2.0.3.11 | 18522512 | 18706488 | 2014年7月 | 45 | 45 | |
| 11.2.0.3.12 | 19121548 | 19440385 | 2014年10月 | 35 | 35 | |
| 11.2.0.3.13 | 19769496 | 19971343 | 2015年1月 | 12 | 12 | |
| 11.2.0.3.14 | 20299017 | 20485830 | 2015年4月 | 6 | 6 | |
| 11.2.0.3.15 | 20760997 | 20996944 | 2015年7月 | 10 | 10 | |
| 總計（個）： | 907 |
看到上面各PSU解決BUG的數量，評估評估您的資料庫中到底埋着多少“定時炸彈”吧。
11.2.0.3于2015年7月以後不再提供PSU更新檔了。
4、看11.2.0.4版本各PSU的釋出時間與解決BUG數量清單
梳理各PSU解決的BUG及其總數量的思路，得益于白鳝（老白）先生的指導。
| ORACLE 11.2.0.4各版本PSU釋出日期與解決BUG數量 | ||||||
| Oracle 版本号 | database PSU号 | GRID PSU号 | 釋出日期 | 解決資料庫的bug數量（個） | 解決GRID的bug數量（個） | 共解決的bug數量合計（個） |
| 11.2.0.4.0 | 2013年8月 | |||||
| 11.2.0.4.1 | 17478514 | 2014年1月 | 17 | 17 | ||
| 11.2.0.4.2 | 18031668 | 18139609 | 2014年4月 | 67 | 41 | 108 |
| 11.2.0.4.3 | 18522509 | 18706472 | 2014年7月 | 55 | 28 | 83 |
| 11.2.0.4.4 | 19121551 | 19380115 | 2014年10月 | 57 | 30 | 87 |
| 11.2.0.4.5 | 19769489 | 19955028 | 2015年1月 | 71 | 32 | 103 |
| 11.2.0.4.6 | 20299013 | 20485808 | 2015年4月 | 70 | 28 | 98 |
| 11.2.0.4.7 | 20760982 | 20996923 | 2015年7月 | 13 | 13 | 26 |
| 11.2.0.4.8 | 21352615 | 21523375 | 2015年10月 | 4 | 36 | 40 |
| 11.2.0.4.9 | 21948347 | 22191577 | 2016年1月 | 17 | 22 | 39 |
| 總計： | 601 |
看到上面各PSU解決BUG的數量，評估評估您的資料庫中到底埋着多少“定時炸彈”吧。
5、資料庫版本定期檢視與更新标準化工藝
從上面4上章節内容的分析來看，如果在一個大型資料中心，資料庫一安裝起來後再也不管大版本的更新、定期PSU更新檔的更新，一定會遇到今天這個資料庫遇到這個BUG而意外當機，明天那個資料庫遇到另外一個BUG而意外當機，再後天又有一個老版本資料庫出了不明故障當機，求天天不應，求地地不靈的尴尬局面。
當然，大版本的更新，以及部分第4位版本的更新，是存在一定的風險的，但是，此風險是可控的。而第5位版本的更新，則要有一定的規律政策。
為了解決這個問題，筆者總結有資料庫版本審查更新、更新檔定期更新方法論，包括什麼版本該更新，什麼時候更新，升哪個更新檔集，怎樣升安全的工作标準規範。以及，總結出一套資訊系統資料庫更新解決方案，亦可稱為資料庫版本定期檢視與更新标準化工藝，如：
◆需求調研階段：需對應用、……、接口等等進行調研；
◆方案制訂階段：最少要包含更新方式、更新路徑、……資料安全調整方案等等；
◆更新測試階段：最少要包含軟體環境更新測試 、應用聯調測試、……、性能測試等等；
◆更新實施階段：最少包含更新、應用驗證、……、接口調整等等。
對于上述方法論與标準化工藝，有興趣的機關與朋友，可以與筆者聯系。
寫了一篇文章，傳遞了一些知識，打了一次廣告。哈哈！
本文作者：黎俊傑（網名：踩點），從事”系統架構、作業系統、儲存設備、資料庫、中間件、應用程式“六個層面系統性的性能優化工作
歡迎加入 系統性能優化專業群 ，共同探讨性能優化技術。群号：258187244