目 录
▇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