文档内容
html
用途 |
问题和答案 |
概述 |
补丁系统的改变 - Release Updates 和 Release Update Revisions |
对于年度数据库软件发布的技术支持策略 |
版本编号的变化 |
Frequently Asked Questions |
Q1: 是否每一年的初始,新功能的数据库版本发布也会同时发布? |
Q2: 在 bug 的修复被并入 Update 及新版本以前,是否仍然能够申请单独的 bug 修复? |
Q3: 替代临时补丁是否能够在Updates和Revisions上可用? |
Q4: 客户是否被要求应用新的Updates 或者 Revisions 来修复一些新的 bug? |
Q5: Update中是否会包含新特性? |
Q6: Revision中是否会包含新特性? |
Q7: 每一个Update会发布多少Revisions ? |
Q8: Revisions 是overlays补丁仍是一个彻底的补丁? |
Q9: 在没有先应用对应的Update的状况下,是否能够安装这个Update对应的Revision ? |
Q10: Update 和 Revision在补丁的内容上有什么主要的不一样? |
Q11: 客户是否能够在 Updates 和 Revisions 之间来回切换? |
Q12: 12.2.0.1会发生什么变化? |
Q13: 数据库 12.1 和 11.2 版本会受到影响吗? |
Q14: 季度的 CPU 会有什么变化? |
Q15: 安装 Update/Revision 须要多长的停库时间? |
Q16: OJVM补丁在这种新的发布模式下是否能够rolling安装? |
Q17: 在应用OJVM Update前,是否须要先安装Database Update/Revision? |
Q18: 怎样获知Updates和Revisions对应的已知问题? |
Q19: Updates中是否包含优化器修复? |
Q21: 如何查看我全部的 $ORACLE_HOME 是处于相同的安全级别? |
Q22: 是否每一个年度发布的版本都是彻底的发布/安装,不依赖以前的版本? |
Q23: Windows 平台的补丁安装模式是否有变化? |
Q24: 新的版本号码系统的3个部分具体的含义是? |
Q25: 为何我在某些文档或者数据库的输出中看到5位(而不是3位)? |
Q26:和Revision同期发布的Update是否包含Revision的内容? |
Q27: 我是否能够指望Revision (好比18.2.3)中的修复也包含在另外一个Update 里(好比18.6.0)? |
Q28: 若是一个客户当前的版本是18.2.x,那么当版本19发布时如何升级? 是否能够直接升级仍是须要临时过渡? |
Q29: Updates/Revisions和产品升级的关系? |
Q30: 对于Oracle 18版本的技术支持策略是怎样的? |
Oracle Database - Enterprise Edition - 版本 12.2.0.1 和更高版本
本文档所含信息适用于全部平台
数据库
从2017年下半年开始, Oracle开始转向一个更加灵活和主动的数据库软件发布流程。 这些改变仅仅影响数据库和Grid Infrastructure12.2 及以后版本。 安全
从2017年下半年开始, Oracle开始转向一个更加灵活和主动的数据库软件发布流程。 这些改变仅仅影响数据库和Grid Infrastructure12.2 及以后版本。 这个战略的主要目标是双重的:oracle
1. 拥抱一个更加简单的软件发布流程ide
a. Oracle每一年均可以发布一些新特性,而不是像之前同样等不少年
b. Oracle经过减小每次发布的软件的修改来提高数据库的质量oop
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 流程以及版本编号系统。ui
从计划的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 <Quarter> Release Update 12.2.0.1.<build-date>
Release Update Revision - Database <Quarter> Release Update Revision 12.2.0.1.<build-date>
在本地安装的软件(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 流程以及版本编号系统。
A: 初始的新功能版本好比18.1和19.1并不会发布Revisions
A: 是的。只要技术上可行的话,能够在支持版本的 Update 和 Revision 上申请临时补丁。
A: 替代临时补丁只在Updates上可用,在Revisions上不可用。请参考Note 1998563.1 - Proactive Replacement Interim Patches for Conflicts with Database Proactive Patches
A: 不。 - 不要求为了修复新的 bug 就去应用 Updates 或者 Revisions 。然而,Oracle 强烈建议客户尽量保持最新的 Updates / Revisions 以维持最稳定的系统,避免触发已知 bug 或者安全问题。
A:小的重要的 Cloud 特性会不按期地包含到 Update 中。
A: 不会。
A: 每一个Update会在发布后六个月内提供Revisions ,每一个Update会发布对应的2个单独的,季度发布的Revisions 。
A: Revisions 不是overlay补丁。 它们是彻底的补丁。
A: 是的. 不须要先安装Update。
A: Revision 包含对 Update 的安全性和回退修复,将 Update 的生命周期延长两个季度,可让数据库保持最新的安全修复。每一个 Revision 只针对特定的 Update。
A: 是的。 只要客户选择的版本是另外一个的累积,那么就能够在 Updates 和 Revisions 之间切换。一个简单的公式就是在相同的年度发布的状况下,把目标以及源库的版本号的后两个部分相加。若是目标版本号的后两个部分相加大于源库版本号的后两个部分相加,那么就能够应用目标版本;不然安装会失败。
例 1:
源版本 - 18.2.2 <<<<< 第二部分和第三部分的和是 "4"
目标版本 - 18.5.0 <<<<< 第二部分和第三部分的和是 "5"
结论: 目标版本 "5" 比源版本 "4" 大,因此能够应用目标版本
例 2:
源版本 - 18.2.2 <<<<< 第二部分和第三部分的和是 "4"
目标版本 - 18.3.0 <<<<< 第二部分和第三部分的和是"3"
结论: 目标版本 "3" 比源版本 "4" 小因此不能安装目标版本,会出错
A: 2017年7月对于 12.2.0.1 版本,Oracle 将发布 Database Update,Grid Infrastructure Update,OJVM Update。 12.2.0.1 版本将不会再有 PSU 或者 Bundle Patch。 2017年10月,计划发布在 Database July 2017 Release Update 上的第一个 Revision。 一样的,2018年1月,计划发布 Database July 2017 Release Update 上的第二个 Revision 。 在上面的图1中也反映了这一点。
若是须要的话,Grid Infrastructure 和 OJVM 的 Revisions 也计划以类似的方式提供。
A: 不会。本文所述的更改只适用于数据库和 GI(Grid Infrastructure)12.2 及以后版本。数据库 12.1 和 11.2 版本仍然使用传统的 PSU/BP 流程以及版本编号系统。
A: 本文中提到的Update/Revision策略既是12.2版本及更高版本的数据库软件的季度发布的CPU项目。CPU文档会列出Updates和Revision提供的安全相关的修复。对于最近的CPU文档,请参照 "Critical Patch Updates, Security Alerts and Bulletins"
A: 当经过 RAC Rolling 或者 Data Guard/GG switchover 等方式安装时,不须要停机时间。
A: Oracle数据库开发正致力于减小OJVM补丁安装时的停机影响。更新信息请参考文档 Note 2217053.1 - RAC Rolling Install Process for the "Oracle JavaVM Component Database PSU" (OJVM PSU) Patches
A: 答案会随不一样的OJVM Update而不一样。请参考要安装的OJVM Update的README的前提条件部分。
A: 对每一个 Updates和Revisions 都会有一篇 MOS 文档来列出已知问题,与当前对 PSU,BP 和 CPU 的作法同样。
A: 优化器的一些修复会改变执行计划,必须由客户有选择的启用。 详细信息,请参考 MOS NOTE 2147007.1>中的"Managing 'installed but disabled' module bug fixes"这一部分。 Q20: 什么产品将改用这种新的发布策略?
A: 在同一个季度周期中(本文图1中相同的列中列出)提供的版本 具备相同级别的安全内容。 一个简单的公式就是,对于相同年度发布版本,经过把版本号的第二部分和第三部分相加。 若是和相同,那么它们就包含相同的安全级别内容。
A: 每一个年度发布的版本都是彻底的发布/安装,不依赖以前的版本。
A:不会。Windows 平台的数据库安装补丁策略不会更改。
A: 年.更新.发布(Year.Update.Revision)
Year 是发布的年份的后两位数字。好比 “18”会用在2018年发布的版本上
Update 表明 Release Update (0, 1, 2, 3, ....)
Revision 表明Update Revision 级别 (0, 1, 2)
A: 第四位是数据库的增量版本。有时候用在Oracle云部署上,有时候Oracle Support会用它。第五位是保留位。对于大部分的客户,只使用3位的格式。
A:是的。 好比18.4.0和Revisions 18.2.2以及18.3.1同期发布,Update 18.4.0版本包含和Revisions 18.2.2以及18.3.1包含的安全内容以及回退修复。
A: 相同季度提供的版本包含相同的安全内容 (本文图1中相同的列中列出)。
A: 能够直接迁移到Oracle 19
A: Updates/Revisions和产品升级无关。他们是版本12.2以及更高版本里的补丁相关的策略。而产品的升级(好比从12.2.0.1到18.x.x)是在不一样的Oracle文档中进行处理。好比Oracle® Database Database Upgrade Guide 18c, E88788-01。
A: Oracle Database 18以及Oracle Database 19会使用12.2的技术支持策略,就像已有的版本发布策略同样。在新的年度版本发布后仍然有2年的错误修复期能够提供Updates, Revisions 和单独的 bug 修复。