目 录
▇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 |
0 |
33 |
|
11.2.0.3.11 |
18522512 |
18706488 |
2014年7月 |
45 |
0 |
45 |
|
11.2.0.3.12 |
19121548 |
19440385 |
2014年10月 |
35 |
0 |
35 |
|
11.2.0.3.13 |
19769496 |
19971343 |
2015年1月 |
12 |
0 |
12 |
|
11.2.0.3.14 |
20299017 |
20485830 |
2015年4月 |
6 |
0 |
6 |
|
11.2.0.3.15 |
20760997 |
20996944 |
2015年7月 |
10 |
0 |
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