Annual release document 2285040.1

23/06/2020 Document 2285040.1
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=f1ldbmy16_102&id=2285040.1 1/10
Copyright (c) 2020, Oracle. All rights reserved. Oracle Confidential.
Release Update Introduction and FAQ (Doc ID 2285040.1)
In this Document
Purpose
Questions and Answers
Overview
Patching Changes - Release Updates and Release Update Revisions
Lifetime Support Policy for Database Feature Releases
Release Version Numbering Changes
Frequently Asked Questions
Q1: Will the initial production releases also have Revisions?
Q2: I need a bit more information about the initial production release, and when an on premise release of the
software will be available for Oracle non-Cloud customers.
Q3: Will individual Bug fixes be available until they are incorporated into a feature release or an Update?
Q4: Will replacement interim patches be available on Updates and Revisions?
Q5: Are customers required to apply Updates or Revisions in order to obtain new bug fixes?
Q6: Are new features ever included into a Update?
Q7: Are new features ever included into a Revision?
Q8: How many Revisions are going to be released per Update?
Q9: How many Updates are going to be released per annual new features Release?
Q10: Will Revisions be overlays or full patches?
Q11: Is it possible to install only a Revision without first applying its associated Update ?
Q12: Are Release Updates cumulative in nature?
Q13: What is the major difference between patch content of Update and Revision?
Q14: Can Customers switch back and forth between Updates and Revisions?
Q15: What about moving from an Update to a Revision within the same quarter, for example from 18.5.0 to
18.4.1? The sum of the 2nd and 3rd fields are 5 in both (5+0=4+1), but it would be going backward one quarter
from a "high-priority non-security fixes" point of view?
Q16: What has changed in 12.2.0.1?
Q17: So 12.2.0.2 and 18c are essentially the same thing, correct?
Q18: Will database version 12.1 and 11.2 be affected?
Q19: What happens to the quarterly Critical Patch Update (CPU) program?
Q20: What database downtime does Update/Revision installation require?
Q21: Will the OJVM patch be rolling installable with the new release model?
Q22: Is it required to apply Database Update/Revision, prior applying OJVM Update ?
Q23: How do I find out about known issues with Updates and Revisions?
Q24: Are optimizer fixes included into Updates?
Q25: What lines of business are changing to this new feature release strategy?
Q26: How can I easily see if all of my $ORACLE_HOMEs are at the same security level.
Q27: Is each feature release a full release / install, or is it in any way dependent upon a prior feature release?
Q28: Will the Windows patching model change with the new release model?
Q29: What does the new 3 field version numbering system mean?
Q30: Why do I still see all 5 fields (instead of just 3 fields) in some documents and some Database outputs?
Q31: Will the Update that is released at the same time as Revisions, include the Revision content?
Q32: When should I expect fixes in one Revision (such as 18.3.2) are merged in another Update (like 18.6.0)?
Q33: If a customer stays on 18.2.x, what is the upgrade path once 19 comes out? Do they have to take

23/06/2020 Document 2285040.1
intermediate Updates or can they go straight to 19?
Q34: How do the Updates and Revisions tie into product upgrades?
Q35: What is the lifetime support policy for the Oracle 18 release?
References
APPLIES TO:
Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Backup Service - Version N/A and later
Information in this document applies to any platform.
PURPOSE
Beginning in July 2017, Oracle has transitioned to a more flexible and responsive strategy for the database software
release process. These changes only affect Database and Grid Infrastructure release 12.2 or later.
QUESTIONS AND ANSWERS
Overview
Beginning in July 2017, Oracle has transitioned to a more flexible and responsive strategy for the database software
release process. These changes only affect Database and Grid Infrastructure release 12.2 or later. The primary goals of
this strategy are twofold:
1. Embrace a less complex software release process
a. Oracle wants to get new features to market every year instead of waiting several years
b. Oracle desires to improve database release quality by reducing the number of software changes released at
one time
2. Provide customers with a more flexible way to both:
a. Efficiently adopt Bug fixes when needed and decrease the need for interim one-offs (like the DB Proactive BP
provides for 12.1.0.2)
b. Efficiently keep current with Quarterly Security Updates once their environment becomes stable (like the PSU
provides for 11.2.0.4 and 12.1.0.2)
To accomplish the goals of this strategy, the following database software changes are being implemented:
Database version 12.1 and 11.2 will continue to use the legacy PSU/BP process and version numbering systems.
Patching Changes - Release Updates and Release Update Revisions
Beginning with the next Database release (originally designated 12.2.0.2) planned for 2018, new feature releases of the
database product are being provided annually, and patchsets are no longer being released.

23/06/2020 Document 2285040.1
To support both security-related fixes and high-priority non-security fixes to each feature release, quarterly Release
Updates (Updates) are being provided each January, April, July and October. Oracle's quarterly Updates contain fixes for
the bugs that customers are most likely to encounter:
Query optimizer bug fixes, which were not allowed in PSU's and BP's from earlier releases are included disabled by
default in the Updates.
Updates include fixes for security vulnerabilities.
Updates go through extensive testing at Oracle, covering functional, stress, performance, and destructive testing
scenarios.
Applying Updates in a timely manner reduces the likelihood of rediscovery of known issues.
Updates can be installed with zero down time via RAC rolling.
In addition to quarterly Updates, Release Update Revisions (Revisions) are being issued on the same quarterly basis to
augment the Updates with fixes for known regressions and to include the latest security vulnerability fixes as well.
Each Update is followed by up to two separate Revisions for the six months after the Update is released. For
example, Release.Update.1 and Release.Update.2, where "1" and "2" represent the Revision iterations.
Oracle recommends that customers stay current with Updates. By doing this they minimize the chance of encountering
known bugs and security vulnerabilities. Staying current with Updates reduces the likelihood of requiring separate interim
one-off patches which lead to unique software baselines and potential for ongoing costly patch maintenance.
Some customers may have reached a stable state and want to prioritize security updates over functional fixes. In such
cases, they may choose to apply Revisions. When they apply Revision Release.Update.1, they lag with the Update content
by 3 months. When they apply Revision Release.Update.2, they lag with the Update content by 6 months. By choosing to
lag on taking new Update content by 3 or 6 months, customers can take a more conservative approach to Database
software maintenance, but they still risk the chance of hitting known issues fixed in the most recent Updates.
It is possible to move back and forth from Updates to Revisions. However, there are some restrictions as the new patch
level must be a super set of the previous. To avoid surprises with patch conflicts, customers should aim to stick to a
consistent policy of always taking the same Revision level (i.e. Release.Update.0, Release.Update.1 or Release.Update.2)
for their quarterly maintenance cycles.
The Update and Revision strategy replaces the legacy Patchset Update (PSU) and the legacy Database Bundle Patch
(DBBP) for 12.2.0.1 database software and subsequent feature releases. As of July, 2017, the legacy terms 'Patchset',
'Patchset Update', and "Database Bundle Patch' are not used for 12.2.0.2 database software and subsequent feature
releases. Note that for Database versions 12.1 and 11.2 Oracle continues to release quarterly PSUs and BPs.
Figure 1: 12.2.0.1 Database Release - Naming convention for 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>

23/06/2020 Document 2285040.1
Lifetime Support Policy for Database Feature Releases
Most feature releases are supported for 2 years after the succeeding release becomes available on on-prem (non-
Engineered System) platforms. Periodically, a release is designated as an "Extended Support Release" and is supported for
8 years. The support life of each release is documented in the Lifetime Support Policy document.
Release Version Numbering Changes
Beginning in 2018, a new numbering schema for the database software is implemented. Instead of a legacy nomenclature
such as 12.2.0.2, a three (3) field format consisting of: Year.Update.Revision is used, such as 18.1.0. This allows clear
indication of:
the feature release designation of the database software (the first field)
the quarterly Update (the second field)
the quarterly Revision (the third field)
Disclaimer:
The dates published in this document are for planning and discussion purposes only. It is intended solely to help you
plan your I.T. projects. The dates are not a firm development plan. The release and timing of any platforms are
subject to change at any time and at Oracle's sole discretion.
Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Software
License and Service Agreement, which has been executed and with which you agree to comply. This document and
information contained herein may not be disclosed, copied, reproduced or distributed to anyone outside of the licensed
organization without prior written consent of Oracle. This document is not part of your license agreement nor can it be
incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.

23/06/2020 Document 2285040.1
Figure 2: Release and Update Timeline
Please note that the changes described in this NOTE are only for Database and Grid Infrastructure release 12.2 and
beyond. Database version 12.1 and 11.2 will continue to use the legacy PSU/BP process and version numbering
systems.
Frequently Asked Questions
Q1: Will the initial production releases also have Revisions?
A: No Revisions are planned for the initial production releases, such as 18.1 and 19.1
Q2: I need a bit more information about the initial production release, and when an on premise release of the
software will be available for Oracle non-Cloud customers.
A: Revisions are not planned for the initial production release (aka 18.1, 19.1, etc.) because the initial production release
will only be for Oracle Cloud deployments. The following quarter, on premise releases for non-Cloud customers will
become available, as release 18.2 in 2018, or 19.2 in 2019, etc. It is not possible for Oracle to be more specific as to
exactly when these on premise releases for non-Cloud customers will become available.
Q3: Will individual Bug fixes be available until they are incorporated into a feature release or an Update?

23/06/2020 Document 2285040.1
A: Yes. Interim patches are delivered on request on top of any Update or Revision for a supported release as long as
technically feasible
Q4: Will replacement interim patches be available on Updates and Revisions?
A: Replacement interim patches will be available for Updates, but not Revisions. Refer to Proactive Replacement Interim
Patches for Conflicts with Database Proactive Patches (Note 1998563.1) for further information on Replacement Interim
Patches.
Q5: Are customers required to apply Updates or Revisions in order to obtain new bug fixes?
A: No - there is no requirement to apply Updates or Revisions in order to get new bug fixes. However, Oracle Support
strongly encourages customers to stay as current as possible with Updates / Revisions to maintain the most stable systems
and avoid hitting known bugs and security issues.
Q6: Are new features ever included into a Update?
A: Small, important Cloud features may infrequently be released into a Update.
Q7: Are new features ever included into a Revision?
A: No.
Q8: How many Revisions are going to be released per Update?
A: Each Update is followed by up to two, separate, quarterly, revisions for the six months after the Update is released.
Q9: How many Updates are going to be released per annual new features Release?
A: Updates will be issued for as long as the annual release is supported, which is a minimum of 2 years AFTER the next
annual Release comes out. This means that each annual new features Release should get Updates for at least 3 years.
Q10: Will Revisions be overlays or full patches?
A: Revisions are not overlay patches. They are full patches.
Q11: Is it possible to install only a Revision without first applying its associated Update ?
A: Yes. You are not required to first apply a prior Update.
Q12: Are Release Updates cumulative in nature?
A: Yes. For example, the July Release Update patch includes the contents of all previously Release Updates.

23/06/2020 Document 2285040.1
Q13: What is the major difference between patch content of Update and Revision?
A: Revisions are an extension (a revision) to a specific Update and contain additional security and regression fixes. They
can extend the Update’s lifetime up to two quarters by allowing the database to stay up-to-date on security fixes.
Q14: Can Customers switch back and forth between Updates and Revisions?
A: Yes. Customers can move from Updates to Revisions and back again as long as they choose versions that are
cumulative of one another. A simple formula to determine cumulativeness within the same feature release is to add the
second and third fields of the version for the source and destination update. If the sum of these fields for the destination
update is greater than or equal to the sum for the source, it is OK to move. If not, a patch application error is issued.
Example 1:
source - 18.2.2 <<<<< sum of second and third fields is "4"
destination - 18.5.0 <<<<< sum of second and third fields is "5"
conclusion: destination "5" is greater than or equal to source "4" so it is OK to move
Example 2:
source - 18.2.2 <<<<< sum of second and third fields is "4"
destination - 18.3.0 <<<<< sum of second and third fields is "3"
conclusion: destination "3" is less than source "4" so a patch application error is issued
Q15: What about moving from an Update to a Revision within the same quarter, for example from 18.5.0 to
18.4.1? The sum of the 2nd and 3rd fields are 5 in both (5+0=4+1), but it would be going backward one quarter
from a "high-priority non-security fixes" point of view?
A: You are forgetting that Revisions are specific to a particular Update. 18.4.1 is only designed to be installed on top of
18.4.0. Likewise, 18.4.2 is only designed to be installed on top of 18.4.x. Since Revisions are full patches and not just
overlays, it is also true that a Revision like 18.4.1 will install fine on an unpatched system, as well as on top of a Release
18 Update or Revision from several quarters ago, such as 18.2.x
If you attempt to go backward one or more quarters from a "high-priority non-security fixes" point of view (such as your
question suggests) the Opatch tool will report that the desired Revision is a subset of the installed Update, and terminate
with a conflict message.
Q16: What has changed in 12.2.0.1?
A: For 12.2.0.1 in July 2017, Oracle released a Database Update, a Grid Infrastructure Update, and an OJVM Update.
There are no PSUs or Bundle Patches for the 12.2.0.1 Release. For October 2017, a first Revision for the Database July
2017 Release Update was released. Likewise, for January 2018, a second Revision for the Database July 2017 Release
Update was released, as well as a first Revision for the Database October 2017 Release Update. This is also reflected in
Figure 1 above.
Revisions for Grid Infrastructure and OJVM are provided in a similar manner, as necessary.
Q17: So 12.2.0.2 and 18c are essentially the same thing, correct?
A: No, they are not. You are going to confuse yourself if you only think of 18c as just a different marketing label for
12.2.0.2. You need to think of 12.2.0.1 as the terminal release of 12.2, and realize that there is no such thing as Oracle
Database 12.2.0.2. Instead of 12.2.0.2, Oracle completely changed the paradigm for releasing Oracle Database software.
That new paradigm is what is described in this document.

23/06/2020 Document 2285040.1
Q18: Will database version 12.1 and 11.2 be affected?
A: No. The changes described in this NOTE are only for Database and Grid Infrastructure release 12.2 and beyond.
Database version 12.1 and 11.2 will continue to use the legacy PSU/BP process and version numbering systems.
Q19: What happens to the quarterly Critical Patch Update (CPU) program?
A: The Update/Revision strategy that is discussed in this note is the quarterly CPU Program for Database software version
12.2 and beyond. CPU documentation lists the Updates and Revisions that deliver the security content. Refer to "Critical
Patch Updates, Security Alerts and Bulletins" for the latest CPU documentation.
Q20: What database downtime does Update/Revision installation require?
A: Zero application downtime is required when applied via RAC Rolling or Data Guard/GG switchover techniques.
Q21: Will the OJVM patch be rolling installable with the new release model?
A: Oracle Database development is working to improve the experience for installing OJVM patches to minimize downtime
impact. Refer to Note 2217053.1 - RAC Rolling Install Process for the "Oracle JavaVM Component Database PSU" (OJVM
PSU) Patches for the latest information.
Q22: Is it required to apply Database Update/Revision, prior applying OJVM Update ?
A: The answer can vary for each OJVM Update. Please refer to the Prerequisites Section of the README file for the
particular OJVM Update that you are interested in.
Q23: How do I find out about known issues with Updates and Revisions?
A: A MOS note is maintained for known issues with each Update and Revision similar to what is done for PSU’s, BP’s and
SPU’s.
Q24: Are optimizer fixes included into Updates?
A: Query optimizer fixes that can change execution plans may be included but will need to be selectively enabled by the
customer. For more details, please see the section entitled "Managing 'installed but disabled' module bug fixes" of MOS
Note 2147007.1
Q25: What lines of business are changing to this new feature release strategy?
A: Except for non-rolling upgradeable fixes, this new strategy combines most patches normally included in the Oracle
Database Bundle Patches for Oracle Database (general), Oracle Engineered Systems, Oracle E-Business Suite, Oracle
Fusion Applications, and SAP products. Oracle Engineered Systems include Exadata, SPARC SuperCluster, MiniCluster and
ZDLRA.
Q26: How can I easily see if all of my $ORACLE_HOMEs are at the same security level.

23/06/2020 Document 2285040.1
A: Versions that are provided in the same quarterly cycle (listed in the same columns of the figures in this NOTE) all have
the same security and regression content. A simple formula to determine security and regression level equality within the
same feature release is to add the second and third fields for each of the various $ORACLE_HOMEs. If these sums are the
same, then the security and regression level content is the same.
Q27: Is each feature release a full release / install, or is it in any way dependent upon a prior feature release?
A: Each feature release is a full release / install, and is independent of any prior feature release.
Q28: Will the Windows patching model change with the new release model?
A: No, it will not. Windows patching will continue to use Bundle Patches, in the same way that these happen today.
Q29: What does the new 3 field version numbering system mean?
A: Year.Update.Revision.
Year is last two digits of year a release is delivered. For example “18” is used for the release that ships in 2018
Update tracks Release Update (0, 1, 2, 3, ....)
Revision tracks the associated Update Revision level (0, 1, 2)
Q30: Why do I still see all 5 fields (instead of just 3 fields) in some documents and some Database outputs?
A: The fourth field is the Oracle Database increment version. An increment version is occasionally used in Oracle Cloud
deployments, and occasionally used at the direction of Oracle Support. The fifth field is reserved for future use. For most
customers, the 3 field format is all they will ever need.
Q31: Will the Update that is released at the same time as Revisions, include the Revision content?
A: Yes. For example, Update 18.4.0 is released at the same time as Revisions 18.2.2 and 18.3.1. Update 18.4.0 contains
the security and regression content that is included in Revisions 18.2.2 and 18.3.1.
Q32: When should I expect fixes in one Revision (such as 18.3.2) are merged in another Update (like 18.6.0)?
A: A new security fix in one Revision will also be in all of the versions that are provided in the same quarterly cycle (listed
in the same columns of the figures in this NOTE). All have the same security and regression content.
Q33: If a customer stays on 18.2.x, what is the upgrade path once 19 comes out? Do they have to take
intermediate Updates or can they go straight to 19?
A: They can upgrade directly to Oracle 19
Q34: How do the Updates and Revisions tie into product upgrades?
A: They are unrelated to upgrades. Updates and Revisions are the "patching" strategy for release 12.2 and beyond. A
product "upgrade" (i.e. from 12.2.0.1 to 19.x.x) is handled in separate Oracle Documentation, such as Oracle® Database
Database Upgrade Guide 19c, E96252-11.

23/06/2020 Document 2285040.1
Q35: What is the lifetime support policy for the Oracle 18 release?
A: Oracle Database 18, and Oracle Database 19, fall under the umbrella of the Database 12.2 lifetime support policy. They
are treated just like patch set releases under existing release models and will have a 2 year error correction grace period
for delivery of new associated Updates, Revisions and interim patches once the succeeding release becomes available on
on-prem (non-Engineered System) platforms. The support life of each release is documented in the Lifetime Support Policy
document.
REFERENCES
NOTE:2365470.1 - 12.2 Updates and Revisions Patching Path
NOTE:742060.1 - Release Schedule of Current Database Releases
Didn't find what you are looking for?

Annual release document 2285040.1

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (10)

Semelhante a Annual release document 2285040.1

Semelhante a Annual release document 2285040.1 (20)

Último

Último (20)

Annual release document 2285040.1