目 录

▇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月	月	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日结束。

从上面表格来看，月就已经停止了补丁服务。假设您还依旧使用此版本号，在遇到新问题时。就准备“自生自灭”吧

而11.2系列，当前非常多单位在使用的日后停止提供新的补丁，假设您还依旧使用此版本号。在遇到新问题时。就准备“自生自灭”吧。可是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			年9月
11.2.0.3.1	13343438	13348650	2012年1月	21	93
11.2.0.3.2	13696216	13696251	2012年4月	26	54
11.2.0.3.3	13923374	13919095	2012年7月	33	65
11.2.0.3.4	14275605	14275572	2012年10月	36	70
11.2.0.3.5	14727310	14727347	2013年1月	42	26
11.2.0.3.6	16056266	16083653	2013年4月	42	33
11.2.0.3.7	16619892	16742216	2013年7月	50	18
11.2.0.3.8	16902043	17272731	2013年10月	57	26
11.2.0.3.9	17540582	17735354	2014年1月	53	21
11.2.0.3.10	18031683	18139678	2014年4月	33	0
11.2.0.3.11	18522512	18706488	2014年7月	45	0
11.2.0.3.12	19121548	19440385	2014年10月	35	0
11.2.0.3.13	19769496	19971343	2015年1月	12	0
11.2.0.3.14	20299017	20485830	2015年4月	6	0
11.2.0.3.15			年7月
	总计（个）：

看到上面各PSU解决BUG的数量。评估评估您的数据库中究竟埋着多少“定时炸弹”吧。

月以后不再提供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			年8月
11.2.0.4.1	17478514		2014年1月	17
11.2.0.4.2	18031668	18139609	2014年4月	67	41
11.2.0.4.3	18522509	18706472	2014年7月	55	28
11.2.0.4.4	19121551	19380115	2014年10月	57	30
11.2.0.4.5	19769489	19955028	2015年1月	71	32
11.2.0.4.6	20299013	20485808	2015年4月	70	28
11.2.0.4.7	20760982	20996923	2015年7月	13	13
11.2.0.4.8	21352615	21523375	2015年10月	4	36
11.2.0.4.9	21948347	22191577	2016年1月	17	22
	总计：

看到上面各PSU解决BUG的数量，评估评估您的数据库中究竟埋着多少“定时炸弹”吧。

5、数据库版本号定期检视与升级标准化工艺

从上面4上章节内容的分析来看，假设在一个大型数据中心。数据库一安装起来后再也无论大版本号的升级、定期PSU补丁的更新。一定会遇到今天这个数据库遇到这个BUG而意外宕机，明天那个数据库遇到另外一个BUG而意外宕机，再后天又有一个老版本号数据库出了不明故障宕机。求天天不应。求地地不灵的尴尬局面。

当然，大版本号的升级，以及部分第4位版本号的升级，是存在一定的风险的，可是，此风险是可控的。而第5位版本号的升级，则要有一定的规律策略。

为了解决问题，笔者总结有数据库版本号审查升级、补丁定期升级方法论，包含什么版本号该升级，什么时候升级，升哪个补丁集。如何升安全的工作标准规范。

以及，总结出一套信息系统数据库升级解决方式，亦可称为数据库版本号定期检视与升级标准化工艺，如：

◆需求调研阶段：需相应用、……、接口等等进行调研；

◆方案制订阶段：最少要包括升级方式、升级路径、……数据安全调整方案等等；

◆升级測试阶段：最少要包括软件环境升级測试 、应用联调測试、……、性能測试等等；

◆升级实施阶段：最少包括升级、应用验证、……、接口调整等等。

对于上述方法论与标准化工艺，有兴趣的单位与朋友。能够与笔者联系。

写了一篇文章，传递了一些知识，打了一次广告。哈哈。

本文作者：黎俊杰（网名：踩点），从事”系统架构、操作系统、存储设备、数据库、中间件、应用程序“六个层面系统性的性能优化工作

欢迎增加
系统性能优化专业群 ，共同探讨性能优化技术。群号：258187244