合 Oracle补丁包RU(Release Update)介绍以及FAQ (Doc ID 2289879.1)
- 适用于:
- 用途
- 概述
- 补丁系统的改变 - Release Updates 和 Release Update Revisions
- 对于年度数据库软件发布的技术支持策略
- 版本编号的变化
- Frequently Asked Questions
- Q1: 是否每年的初始,新功能的数据库版本发布也会同时发布?
- Q2: 我想了解更多的信息,比如对于non-Cloud用户来说 初始版本 的发布日期。
- Q3: 在 bug 的修复被并入 Update 及新版本之前,是否仍然可以申请单独的 bug 修复?
- Q4: 替代临时补丁是否可以在Updates和Revisions上可用?
- Q5: 客户是否被要求应用新的Updates 或者 Revisions 来修复一些新的 bug?
- Q6: Update中是否会包含新特性?
- Q7: Revision中是否会包含新特性?
- Q8: 每个Update会发布多少Revisions ?
- Q9: 对于每个 annual new features Release 会发布多少 Updates?
- Q10: Revisions 是overlays补丁还是一个完全的补丁?
- Q11: 在没有先应用对应的Update的情况下,是否可以安装这个Update对应的Revision ?
- Q12: Release Updates 是累积的吗?
- Q13: Update 和 Revision在补丁的内容上有什么主要的不同?
- Q14: 客户是否可以在 Updates 和 Revisions 之间来回切换?
- Q15: 从 Update 转换向相同季度发布的 Revision 会怎样?比如,从 18.5.0到18.4.1? 虽然后两位的数的和都是5,但是从 "high-priority non-security fixes" 的角度来看,却是倒退了一个季度?
- Q16: 12.2.0.1会发生什么变化?
- Q17: 那么12.2.0.2和18c本质上是同一件事,对吗?
- Q18: 数据库 12.1 和 11.2 版本会受到影响吗?
- Q19: 季度的 CPU 会有什么变化?
- Q20: 安装 Update/Revision 需要多长的停库时间?
- Q21: OJVM补丁在这种新的发布模式下是否可以rolling安装?
- Q22: 在应用OJVM Update前,是否需要先安装Database Update/Revision?
- Q23: 怎样获知Updates和Revisions对应的已知问题?
- Q24: Updates中是否包含优化器修复?
- Q25: 哪些产品使用了这个新的patch策略?
- Q26: 如何查看我所有的 $ORACLE_HOME 是处于相同的安全级别?
- Q27: 是否每个年度发布的版本都是完全的发布/安装,不依赖之前的版本?
- Q28: Windows 平台的补丁安装模式是否有变化?
- Q29: 新的版本号码系统的3个部分具体的含义是?
- Q30: 为什么我在某些文档或者数据库的输出中看到5位(而不是3位)?
- Q31:和Revision同期发布的Update是否包含Revision的内容?
- Q32: 我是否可以期望Revision (比如18.2.3)中的修复也包含在另一个Update 里(比如18.6.0)?
- Q33: 如果一个客户当前的版本是18.2.x,那么当版本19发布时如何升级? 是否可以直接升级还是需要临时过渡?
- Q34: Updates/Revisions和产品升级的关系?
- Q35: 对于Oracle 18版本的技术支持策略是怎样的?
适用于:
Oracle Database Exadata Express Cloud Service - 版本 N/A 和更高版本
Oracle Cloud Infrastructure - Database Service - 版本 N/A 和更高版本
Oracle Database Cloud Exadata Service - 版本 N/A 和更高版本
Oracle Database Backup Service - 版本 N/A 和更高版本
Oracle Database Cloud Service - 版本 N/A 和更高版本
本文档所含信息适用于所有平台
用途
从2017年下半年开始, Oracle开始转向一个更加灵活和主动的数据库软件发布流程。 这些改变仅仅影响数据库和Grid Infrastructure12.2 及之后版本。
概述
从2017年下半年开始, Oracle开始转向一个更加灵活和主动的数据库软件发布流程。 这些改变仅仅影响数据库和Grid Infrastructure12.2 及之后版本。 这个战略的主要目标是双重的:
- 拥抱一个更加简单的软件发布流程
a. Oracle每年都可以发布一些新特性,而不是像以前一样等很多年
b. Oracle通过减少每次发布的软件的修改来提升数据库的质量
2.可以提供给客户一个更灵活的方式来:
a. 在需要时有效的提供 bug 修复(就像 12.1.0.2的DB Proactive BP 目前所提供的)
b. 当客户环境稳定时,有效的提供季度安全更新(就像11.2.0.4以及12.1.0.2上的 PSU 目前所提供的)
为了实现这个目标,如下的数据库软件修改被实施:
数据库 12.1 和 11.2 版本仍然使用传统的 PSU/BP 流程以及版本编号系统。
补丁系统的改变 - Release Updates 和 Release Update Revisions
从计划的2018年的下一个数据库发布(本来预计是12.2.0.2)开始,数据库产品的新版本发布改为每年一次,并且不再发布补丁集。
为了支持与安全相关的修复以及高优先级的非安全修复,将在每年的1月,4月,7月和10月每个季度发布一个 Release Updates (Updates)。 Oracle的季度发布的Updates包含客户最有可能遇到的错误的修复:
- 查询优化器错误修复,在之前版本的PSU以及BP中并不包含的这些修复被加入到Updates中,但是默认是禁用的。
- Updates包含安全相关的补丁。
- Updates会经过 广泛的测试,包括功能测试,压力测试,性能测试以及破坏性测试。
- 及时应用Updates可以降低碰到已知问题的可能性。
- Updates在RAC环境下可以使用rolling的方式不停机安装。
除了季度性发布的Updates, Release Update Revisions (Revisions) 也会每个季度发行,包含对Updates的回退修复以及包含最新的安全方面的修复。
- 在每个Update发布后的六个月内,会有2个针对这个Update的Revisions 。比如, Release.Update.1 和 Release.Update.2,这里"1" 和 "2"代表的是Revision。
Oracle推荐客户保持应用最新的Updates,这样可以避免很多已知的问题。并且可以避免申请很多小补丁,并显著降低更多的补丁维护的操作。
某些客户可能已达到稳定状态,并希望优先考虑安全更新而不是功能修复。在这种情况下,他们可能选择应用 Revisions。当他们应用 Release.Update.1,他们落后Update的内容3个月。 当他们应用 Revision Release.Update.2,他们落后Update的内容6个月。通过选择延迟3或6个月的新Update的内容,客户可以采取更保守的方法来进行数据库软件维护,但是他们仍有可能会碰到已在最新Update中包含的已知问题。
在Updates和Revisions 之间来回切换是可能的。但是是有限制的,新的patch必须是之前patch的超集。为了避免补丁冲突,客户应该坚持一贯的政策,即在每季维护周期中始终采用相同的Revision级别 (比如 Release.Update.0, Release.Update.1 或者 Release.Update.2)
从12.2.0.1 数据库软件以及更新的版本开始,Update 和 Revision策略取代了之前的 Patchset Update (PSU) 和 Database Bundle Patch (DBBP) 策略。从2017年7月开始,之前的术语'Patchset', 'Patchset Update', 以及"Database Bundle Patch' 不再适用于 12.2.0.2 及更高版本。注意,数据库版本12.1 和11.2 仍然会每季度发布 PSUs 和 BPs。
图1: 12.2.0.1 数据库版本 - Update/Revision的命名规则
- Release Update - Database
Release Update 12.2.0.1. Release Update Revision - Database
Release Update Revision 12.2.0.1.
对于年度数据库软件发布的技术支持策略
在本地安装的软件(non-Engineered System)版本被发布后,大部分的年度软件发布版本会被支持2年。定期的会有一个版本被定义为“扩展支持版本”,并且会被支持8年。关于每个版本的支持年限被详细记载在 技术支持策略文档.
版本编号的变化
从2018年开始,开始使用一个新的数据库软件版本编号系统。和以往的编号系统(比如12.2.0.2)不同,会使用3个数字编码格式:年.更新.发布 (Year.Update.Revision),比如18.1.0。这样可以清楚的表示:
- 软件是哪年发布的 (第一个部分)
- 哪个季节发布的Update (第二个部分)
- 哪个季节发布的Revision (第三个部分)
声明:
对文档中公布的日期仅用于规划和讨论的目的。它的目的纯粹是为了帮助您规划 I.T. 项目。该日期并不是一个确认的开发计划。任何平台的发布和时间如有变更,在任何时候,由 Oracle 自行决定。
您访问和使用此机密资料应遵守您的Oracle软件许可和服务协议的条款和条件。未经Oracle事先书面许可,不得将本文档及其中包含的信息披露,复制,复制或分发给许可组织外的任何人。 本文档不属于您的许可协议的一部分,也不能包含在与Oracle或其子公司或关联公司的任何合同中。
Figure 2: Release and Update Timeline
请注意,本文所述的更改只适用于数据库和 GI(Grid Infrastructure)12.2 及之后版本。 数据库 12.1 和 11.2 版本仍然使用传统的 PSU/BP 流程以及版本编号系统。
Frequently Asked Questions
Q1: 是否每年的初始,新功能的数据库版本发布也会同时发布?
A: 初始的新功能版本比如18.1和19.1并不会发布Revisions
Q2: 我想了解更多的信息,比如对于non-Cloud用户来说 初始版本 的发布日期。
A: 没有计划针对初始生产版本(也称为18.1、19.1等)发布Revisions,因为初始生产版本仅适用于Oracle Cloud部署。然后在下一个季度里,on premise的版本才会发布,比如 release 18.2 在 2018, 或者 19.2 在 2019, 等等。 Oracle不能更具体地确定何时为非Cloud客户提供这些本地版本
Q3: 在 bug 的修复被并入 Update 及新版本之前,是否仍然可以申请单独的 bug 修复?
A: 是的。只要技术上可行的话,可以在支持版本的 Update 和 Revision 上申请临时补丁。