目 录

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月

20121

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)。于20157月就已经停止了补丁服务。假设您还依旧使用此版本号,在遇到新问题时。就准备“自生自灭”吧

    而11.2系列,当前非常多单位在使用的11.2.0.3版,也在2015827日后停止提供新的补丁,假设您还依旧使用此版本号。在遇到新问题时。就准备“自生自灭”吧。可是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.320157月以后不再提供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