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、看看自己的的数据库还有没有支持服务

从上面表格来看，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年也将会停止新补丁服务。

梳理各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补丁了。

梳理各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的数量，评估评估您的数据库中究竟埋着多少“定时炸弹”吧。

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

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

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

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

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

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

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

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

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

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

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

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

转载于:https://www.cnblogs.com/jzssuanfa/p/7146758.html

你可能感兴趣的文章