Oracle Database and Other

Technology Products
Error Correction Policy
Major/Minor and Annual Releases
Oracle Databases11g, 12c, 18c

August 02, 2023

Version 2.1
Copyright © 2023, Oracle and/or its affiliates
Public
Table of contents

1 OVERVIEW 5
1.1 Basic Policy Concepts 5
1.2 Oracle Database Release Models 5
1.2.1 Annual Releases 5
1.2.2 Major Releases / Patch Sets 5
1.3 Patching Eligibility 6
1.3.1 Grace Period 6
1.4 Patching Models 7
1.4.1 Proactive Maintenance Annual Releases (12.2.0.1) 7
1.4.2 Proactive Maintenance Patch Set Releases (11.2.0.4/12.1.0.2) 7
1.4.3 Reactive Maintenance with Interim Patches 7
2 ERROR CORRECTION END DATES 9
2.1 Global Exceptions 9
2.2 Market Driven Support (MDS) / Upgrade Support 9
3 PROACTIVE PATCHING 10
3.1 Definitions 10
3.2 Recommended Patches 10
3.3 Release Update (RU) 10
3.3.1 Testing 11
3.3.2 Scope 11
3.4 Release Update Revision (RUR) - Deprecated 11
3.4.1 Testing 11
3.4.2 Scope 11
3.5 Patch Set Update (PSU) 11
3.5.1 Testing 12
3.5.2 Scope 12
3.5.3 Patch Set Update (PSU) Patch Eligibility 12
3.5.4 For Which PSUs Can Interim Patches Be Created? 13
3.5.5 Conflicts between PSUs and Previously Installed Interim Patches 13
3.8 Bundle Patches 13
3.7 Critical Patch Update Program 13
3.7.1 Versions covered under CPU patches 13
3.7.2 Patch Conflict Resolution for SPUs 14
3.8 Security Patch Updates 14
3.8.1 Testing 14
3.8.2 Scope 14
2 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
4 INTERIM PATCHES 15
4.1 Testing 15
4.2 Supported Releases 15
4.2.1 Criteria for Considering Interim Patch Requests 15
4.2.2 Interim Patches 16
4.3 Regressions Due to Interim Patch 17
4.4 Interim Fixes Included in Future RUs and Releases 17
4.5 Customer Considerations 17
4.6 Interim Patches Available via Self-Service 17
5 DIAGNOSTIC PATCHES 19
5.1 Install Only on Problem System 19
5.2 Diagnostic Patch Version 19
5.3 Deinstallation 19
6 TERMINOLOGY 20
6.1 Bundle Patch (BP) 20
6.2 Conflicting Patch 20
6.3 Critical Patch Update (CPU) Program 20
6.4 Cumulative Patch 20
6.5 Diagnostic Patch 20
6.6 Grace Period 20
6.7 Innovation Release 20
6.8 Interim Patch 21
6.9 Long Term Release 21
6.10 Major Release 21
6.11 Merge Patch 21
6.12 Patch Conflict Resolution 21
6.13 Patch Set Release 22
6.14 Patch Set Update (PSU) 22
6.15 Regression 22
6.16 Release Update (RU) 22
6.17 Release Update Revision (RUR) 22
6.18 Security Patch Update (SPU) 23
7 ADDITIONAL DATABASE RESOURCES 24
APPENDIX A– OTHER TECHNOLOGY PRODUCTS 25
A.1. ENTERPRISE MANAGER: Base Platform and Plug-ins 25
EM Base Platform (Cloud Control) 25
EM Plug-ins 25
A.2 TIMES TEN IN-MEMORY DATABASE 26
A.3 ESSBASE 26
3 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
Connect with us 27

4 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
1 OVERVIEW

1.1 Basic Policy Concepts

The Lifetime Support Policy (LSP) defines the types of support delivered during each stage of a product’s
lifecycle (Premier, Extended, and Sustaining.) The LSP for Oracle Database is: Lifetime Support Policy for
Technology Support Products

The Error Correction Policy (ECP) works alongside the LSP and defines the types of patches that will be
produced and most importantly establishes an end-date when patches and proactive bundles will no longer be
produced for a given Database version. This ECP document provides details on patching the Oracle Database
and covers releases 11g, 12c, and 18c. Oracle Database 19c and onward are covered in a separate ECP
document.

1.2 Oracle Database Release Models

The Oracle Database release model has transitioned from a Major release with Patch Set releases to Annual
releases and then to Long Term releases with interim Innovation releases. This document covers Oracle
Database 11g through 18c or Major release with Patch Set releases to Annual releases. The ECP policy for
Long Term and Innovation releases are covered in a separate ECP document.

1.2.1 Annual Releases

In an effort to get new features out more quickly, Oracle released annual releases of the database
beginning with 12.2 and including 18c. This release model only lasted two cycles before establishing
the Long Term Release with interim Innovation Releases. Support for Annual releases included at
least 2 years of Premier Support but did not provide Extended Support.

1.2.2 Major Releases / Patch Sets

The Major release model was the primary model used by Oracle Database until version 12.2.0.1. With
Major releases which included 11.2 and 12.1, the first or second digit in the version number
incremented with each release. In between Major releases were Patch Set releases that incremented
the fourth digit in the version number (11.2.0.1, 11.2.0.2, 11.2.0.3, 11.2.0.4). Patch Sets were
normally full installations and included new features and patches but never architectural changes.

5 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
 Major releases could have 4 or more Patch Set releases and only the last Patch Set in a release (a.k.a.
Terminal release) was eligible for Extended Support as most others had reached the end of their grace
periods. In a few rare exceptions two Patch Set releases from the Major release family were in
Extended Support at a given time but only until the grace period expired for the oldest version. See
1.3.1 Grace Period below.

1.3 Patching Eligibility

Database patches are normally created only during Premier Support or Extended Support. In some releases,
Oracle has offered a global exception known as Limited Error Correction service and/or Severity 1 Production
Support that cover only Severity 1 production bugs while the customer upgrades away from the Sustaining
release to the latest supported release.

1.3.1 Grace Period

Grace Period was first defined in the Major release model and represented the period-of-time
following a new release where Oracle created patches for both the new release and previous versions
that fell within a certain grace period window. This concept was necessary for the Major release
model because it helped establish an end date for previous Patch Set release error correction and it
gave customers two years to plan for and install the latest version while still receiving patches during
the upgrade process.

Table 1: Database Release Models

Database Releases Premier Support (PS) Extended Support (EXS)

Major (11.2, 12.1) Grace Period was used to Only Terminal Patch Set releases
determine ECP for Patch Sets receive Error Correction during EXS
during PS. (e.g.11.2.0.4, 12.1.0.2).

Annual (12.2.0.1, 18c) These Annual releases were No Extended Support.

given at least a two-year
error correction grace
period window starting with
the on-premises go-live of
the next release.

6 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
1.4 Patching Models

Oracle Database patch delivery depend on the release model. For Annual releases, Oracle offered
Proactive Maintenance patches with RUs and RURs as well as reactive maintenance with interim
patches (a.k.a. one-off patches/overlay patches). For Major Releases/Patch Set Releases, Proactive
quarterly patches were released along with reactive interim patches. Proactive maintenance is
accomplished by proactively applying a routine quarterly patch bundle that is available from the My
Oracle Support (MOS) Customer Portal for each Oracle Database software release. Oracle releases
quarterly proactive patches and Database bundles on the third Tuesday of: Jan, Apr, July, Oct.
Quarterly proactive patches are marked as Recommended Patches. These patches are thoroughly
tested and are cumulative from quarter to quarter. If you attempt to download a quarterly patch
older than one year from My Oracle Support, you will be required to provide a password.

1.4.1 Proactive Maintenance Annual Releases (12.2.0.1)

For the Annual releases, Oracle recommended proactive patches known as Release Updates
(RUs).

For 12.2 customers who have Severity 1 Production Support exception, the RU is a
cumulative, well-tested, proactive quarterly recommended patch that contains both Security
fixes and the most critical non-Security fixes for the release.

18c is not eligible for Severity 1 Production Support exception.

1.4.2 Proactive Maintenance Patch Set Releases (11.2.0.4/12.1.0.2)

For terminal Patch Set releases, Oracle’s recommended proactive patches are known as Patch
Set Updates (PSU) which are cumulative, well-tested, proactive quarterly recommended
patches that contains the most critical fixes. An alternative to the PSU is the Database Bundle
Patch (DB BP) that is also released for 11.2 and 12.1 PSUs are available for Oracle Database
customers who have purchased Upgrade Support. Contact Customer Success Services (previously
known as Advanced Customer Services (ACS) for details.

1.4.3 Reactive Maintenance with Interim Patches

As needed, Oracle can also produce non-proactive patches. These are defined below in Section 5 and
include such things as interim patches and diagnostic patches. These patches are characterized as:
7 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
 • Usually delivered as “Interim Patches”
• Historically known as “one-off” patches or “overlay” patches
• Are provided on demand for a given “defect, version, platform” combination

• Go through basic sanity tests

• Certain reactive fixes may be included in future Release Updates

8 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
2 ERROR CORRECTION END DATES

For Oracle Database, the Error Correction End Dates are listed in MOS Document 742060.1

2.1 Global Exceptions

Global exceptions and global waivers are documented in the Oracle Technology Support Policies guide.

2.2 Market Driven Support (MDS) / Upgrade Support

When an Oracle Database release moves into Sustaining Support, if needed Market Driven Support (MDS)
provides additional Support for completing upgrades to the latest Long Term release. In all cases, the MDS
services that were setup for 11.2 have expired. To replace MDS, a custom Upgrade Support service has been
established and is available through Customer Success Services. Both Oracle 11.2.0.4 and 12.1.0.2 have
limited availability under Upgrade Support service. Please contact Customer Success Services for program
eligibility and service details.

9 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
3 PROACTIVE PATCHING
,

Proactive Patching includes: RU, PSU, BP, SPU, CPU

3.1 Definitions

Oracle streamlines patching by providing customers with well-tested patches released on a fixed predictable
schedule. This allows you to plan for and install the fewest number of patches with the highest expectation
of success. Stating April 2022, these patches and bundles are released on the third Tuesday in the months
of: Jan, Apr, Jul, and Oct.

Beginning with Oracle Database 12.2.0.1, quarterly proactive patches are called Release Updates (RUs).

Patches are bundled together based on platform and release version. For example, PSUs are a single patch
for some platforms and as a bundle patch on other platforms.

3.2 Recommended Patches

Oracle may designate some patches as “Recommended” or “Critical”. Recommended patches address high
impact bugs that affect a given configuration and have a high likelihood of occurring.

3.3 Release Update (RU)

Starting with Oracle Database 12.2.0.1, a RU is a cumulative, thoroughly tested, proactive quarterly
recommended patch that contain the Security fixes and the most critical non-Security fixes for an
Annual/Innovation/Long Term release. RUs allow customers to apply one patch to avoid many problems.
Where implemented for a product, RU patches replaces proactive bundles, PSU and SPU patches. Oracle
recommends as a best practice, that customers install each RU on a test system which mirrors their production
system’s environment before installing in a production system.

10 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
 3.3.1 Testing
RUs are tested extensively including install and functional regression tests, and in some cases are
tested as part of an Oracle application stack. Regression, system and performance testing are done
to ensure customers have the most successful experience using them.

3.3.2 Scope

Fixes may include:

o Fixes for critical technical issues such as wrong results, corruptions, and hangs.

o Fixes encountered by many customers.

3.4 Release Update Revision (RUR) - Deprecated

For the Annual releases, RURs have been deprecated. They were quarterly, cumulative, proactive patches
that contained fixes for regressions introduced in the applicable RU, plus all new security updates for the
quarter. Oracle recommended as a best practice, that customers install each RUR on a test system which
mirrors their production system’s environment before installing in a production system.

3.4.1 Testing

RURs were tested extensively including install and functional regression tests, and in some cases are
tested as part of an Oracle application stack

3.4.2 Scope

Fixes include:
• Fixes for regressions introduced in the applicable RU
• Security updates for the given quarter

3.5 Patch Set Update (PSU)

Patch Set Updates are only available for products in Upgrade Support (11.2, 12.1) and are created quarterly
if Oracle determines a PSU has content. When available, they are proactive cumulative patches comprised of
critical bug fixes released quarterly. PSUs establish a new baseline version number. Where both are released
in a quarter, all the fixes in the Security Patch Update are included in the PSU.
11 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
 Every PSU is a version of the software, changing the 5th place of the version number to a string that represents
the “year month date” of the PSU release (for example, 230417 means the patch released on April 17, 2023).
The PSU also represents a new baseline of the code, so in order to be applied, an interim patch may need to
be built specifically for the PSU you have installed. For more information on PSUs see Patch Set Updates for
Oracle Products (Doc ID 854428.1) including information about patch conflicts and how to resolve them.

3.5.1 Testing

PSUs are subjected to extensive tests prior to release. Regression, system and performance testing
are done to ensure customers have the most successful experience using them.

3.5.2 Scope

PSUs contain a strictly limited number of fixes. Content is selected to provide maximum benefit to
you while ensuring the PSUs are safe to apply. Fixes include:

• Fixes for critical technical issues such as wrong results, corruptions, and
hangs.
• Fixes encountered by a large number of customers.
• Fixes already proven in the field.
• All fixes that are included in the SPU patch
• Excluded from any PSU are:
• Fixes which would require recertification or changes functional behavior.

• Fixes which would require any configuration changes.

• Fixes to the optimizer.

If a Critical Patch Update security fix breaks one of the above rules, we include it and document the
exception.

3.5.3 Patch Set Update (PSU) Patch Eligibility

Patch Set Updates are created for products and Patch Sets which in Oracle’s judgment are adopted
widely enough to benefit from this approach to delivering an integrated set of fixes, and only for
Patch Sets currently under error correction (a.k.a. Upgrade Support, Contact Customer Success
Services for details).

12 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
 3.5.4 For Which PSUs Can Interim Patches Be Created?
Interim patches can be created for any PSU while the patch set it is based upon is supported under
Error Correction.

3.5.5 Conflicts between PSUs and Previously Installed Interim Patches

For product and release issue fixes via interim patches, it is very important to check for conflicts as
part of the planning process when applying a PSU so you know what installed patches will conflict and
can ensure conflicts are resolved before you install the PSU. You must get a replacement fix which is
specific to the PSU you are planning on applying. If the patch you need to resolve the conflict does
not already exist on My Oracle Support, you must request it. Unlike a typical request for a new interim
patch, no special approval is required to get a replacement patch built.

Note: Even if you resolve a conflict with the current PSU, the new fix might still conflict with
later PSUs. We do proactively create overlay patches to resolve conflicts as part of the
quarterly program, so the fix you need may already exist.

3.8 Bundle Patches

A bundle patch is a cumulative collection of fixes to address bugs for a given feature, product or
configuration. Windows Database Bundle Patch, Database Patch for Exadata and Database Proactive Bundle
Patch are all examples of a bundle patch.

Bundle Patches are a superset of a PSU and may span multiple stack components. For example: “Database
Patch for Exadata” includes fixes for both the Database and Grid Infrastructure. Unlike the PSU that is only
delivered quarterly, the bundle patch may have a more frequent pre-defined delivery schedule.

Bundle Patches are always Rolling and Standby First installable.

3.7 Critical Patch Update Program

3.7.1 Versions covered under CPU patches

13 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
 Patches released as part of the CPU program include: RUs, MRPs, PSUs, SPUs, and BP. They are created
for releases that are still covered by Premier Support and for Terminal Patch Sets that are covered by
Upgrade Support.

• Only customers who have contracted for Upgrade Support are entitled to download and use
proactive patches created for a product covered by Upgrade Support. (i.e. DB 11.2.0.4, 12.1.0.2)

3.7.2 Patch Conflict Resolution for SPUs

It is possible that you may encounter a conflict between the new SPU and a patch you had installed
prior to the SPU. Conflict resolution process is different for different products – see Patch Conflict
Resolution (Doc ID 1299688.1) for more information.

3.8 Security Patch Updates

A Security Patch Update (SPU) is a collection of security fixes issued quarterly. SPUs are built for the 11.2.0.4
patch set are covered under Market Driven Support.

3.8.1 Testing
SPUs are tested extensively including install and functional regression tests, and in some cases are
tested as part of an Oracle application stack.

Oracle recommends as a best practice, that customers install each SPU on a test system which mirrors
their production system’s environment before installing in a production system.

3.8.2 Scope
SPUs contain new security fixes, plus all fixes from previous SPUs issued on any given patch set,
meaning each new SPU is cumulative. For example, the Oct quarterly SPU patch issued against DB
11.2.0.4.201020 will contain all the fixes from the July quarterly SPU for 11.2.0.4.200714 plus any
new fixes. Even though Oracle intends to include mainly security fixes in SPUs, we may decide to
include high-priority non- security fixes. Any high-priority non security fixes will always be identified
in the SPU documentation.

14 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
4 INTERIM PATCHES
An Interim Patch is a patch containing one or more fixes made available to customers who cannot wait until
the next proactive patch to get the fix or who are running on a Terminal Patch Set Release.

Interim patches will not be used to backport features to older releases or implement new features. Interim
patches are specific to a particular Database version or Patch Set. Interim patches that meet the inclusion
criteria are included in the next RU, or PSU.

4.1 Testing
Interim patches are tested for the specific environment in which the patch was initially created. Users
installing interim patches in other environments, such as where different combinations of patches are
installed, compound the risk to system stability with each additional interim patch installed

4.2 Supported Releases

New interim patches are only created for eligible releases covered under a Lifetime Support Policy phase or
an exception situation:

• Premier Support

• Extended Support

• Sustaining Support with restricted Upgrade Support through Customer Success Services
(a.k.a ACS)

• Sustaining Support with Severity 1 Production Support exception

NOTE: During Limited Error Correction Support, interim patches can be limited to only Severity 1 and Security
issues reported via Service Request.

See Lifetime Support Policy – Oracle Technology Products for the dates of Premier and Extended Support,
and Oracle Software Technical Support Policies for exceptions.

4.2.1 Criteria for Considering Interim Patch Requests

15 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
 Any request for a new interim patch should be accompanied by a case showing the customer business
and operational impact is severe enough to be considered. Also, Oracle must believe it is technically
feasible to create a patch that will not jeopardize the stability of the customer’s system.

Below are some of the criteria which should be discussed in the impact case which must accompany
a request:

• Customer business impact

• Inability to do normal business

• Significant risk to development or deployment schedule

• Patch required to replace a patch rolled back by an RU / PSU

• Operational/technical impact

• Permanent data corruption (physical or logical)

• System hangs or crashes repeatedly

• Failure of critical functionality

• Severe performance regression

• Bug fixes are not implemented in a later release, RU, RUR, or PSU and you are currently
upgrading or planning to upgrade to the latest Long Term Release.

• No workaround available or inability to use workaround because of a strong business / technical

reason

• Technical Feasibility: if a fix requires too many lines of code to be changed, Oracle may
determine the bug fix cannot be safely implemented as an interim patch

• If the impact case for the request is strong, Oracle Support will log a request for an interim
patch on your behalf, which will result in the patch being created and placed on My Oracle
Support for you to download.

If the impact of a bug is high but does not meet the above criteria, Oracle Support will log a request to
include the fix in the next release or RU.

4.2.2 Interim Patches

Oracle will create new interim patches against the Terminal Patch Set release while the Patch Set is
covered in the Error Correction window.

16 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
4.3 Regressions Due to Interim Patch

If an interim patch introduces a new bug when installed on a customer system, Oracle will work the problem
at the level of priority assigned to the original bug. If necessary, Oracle may create a new interim patch to
correct the problem.

4.4 Interim Fixes Included in Future RUs and Releases

Interim patches that meet the inclusion criteria for an RU are automatically included. In cases where the
interim patch is created too late in the development cycle of the current release, it will be rolled into a
subsequent RU or bundle patch.

Be sure to review the list of bug fixes included in a new release to make certain all the fixes from patches
you currently have installed are included.

If you find a patch you need is missing, contact Support prior to installing so a new patch can be created for
you on the release you are preparing to install.

4.5 Customer Considerations

• An interim patch is unit tested but not tested with other interim patches, nor is the product regression
tested as a whole with the interim patch included.

• You should install and perform basic testing on a test system before installing an interim patch in a
production system.

• Install the requested patch promptly. If you do not plan to install it promptly, ask for the fix to be
included in the next release or bundle instead of requesting a patch.

• Report back to Oracle Support on the success of the patch, so Support can update the bug.

• As a best practice, install a patch set with this fix as soon as it is available on your platform.

4.6 Interim Patches Available via Self-Service

Once an interim patch has been provided to you, at Oracle’s discretion it is made available to other
customers for download via My Oracle Support.

IF YOU PLAN TO INSTALL MORE THAN ONE INTERIM PATCH and/or QUARTERLY released patch into an Oracle
Home directory, it is very important to run the My Oracle Support Conflict Checker.

17 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
 The My Oracle Support Conflict Checker tool, available from both the Patch Search results page and Patch
Details page, enables you to upload an OPatch Inventory and check the patches that you want to apply to
your environment for conflicts.

If no conflicts are found, you can download the patches. If conflicts are found, the tool finds an existing
resolution to download. If no resolution is found, you can request a solution and monitor your request in
the Plans region.

For more information, see Knowledge Document 1091294.1, "How to use the My Oracle Support Conflict
Checker Tool".

Oracle Support will determine, based on the patches already installed, whether a Merged Patch must be
requested. Failure to do so may result in reoccurrence of problems fixed by an earlier-installed interim
patch.

If the database is in Extended Support and the resolution is provided by the Conflict Checker, you must have
Extended Support setup on your database CSI in order to download the patch.

18 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
5 DIAGNOSTIC PATCHES

Diagnostic patches are patches created for the purpose of attempting to diagnose a product or performance
fault.

5.1 Install Only on Problem System

Diagnostic patches should not be installed on any other customer system than the one they were specifically
produced for unless so directed by Oracle Support personnel.

5.2 Diagnostic Patch Version

Diagnostic Patches may (at Oracle’s discretion) be created for any supported version.

5.3 Deinstallation

Diagnostic patches should be removed from a production system once the situation it was produced for has
been resolved, unless otherwise directed by Oracle Support personnel.

19 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
6 TERMINOLOGY

6.1 Bundle Patch (BP)

A cumulative quarterly proactive patch for Databases. Bundle patches are also used to refer to the
quarterly patches for Databases running on Microsoft Windows platforms. Exadata 11.2.0.4 also has a
proactive patch called a “Bundle Patch”.

6.2 Conflicting Patch

Conflicting patches are two or more patches that have some files in common but contain independent
fixes. Oracle recommends using the My Oracle Support Conflict Checker before installing a patch. See Doc
ID.1091294.1 for more information.

6.3 Critical Patch Update (CPU) Program

Critical Patch Update is the program for documenting Security fixes. See the CPU program
documentation for specific patches.

6.4 Cumulative Patch

A patch in a series of patches which includes both new fixes plus all fixes from previous patches in the
series. Proactive patches like RU, MRP, PSU and Bundles are cumulative patches.

6.5 Diagnostic Patch

An interim patch created specifically to diagnose one specific problem for one specific customer.
Normally, the patch is uninstalled after the diagnostics have been collected.

6.6 Grace Period

The time period following a new release where Oracle created patches for both the new release and
previous versions that fell within a defined grace period window. This allowed customers time to plan for
and install the latest version and receive patches while the upgrade was in process.

6.7 Innovation Release

In between Oracle Database Long Term releases, Oracle delivers Oracle Database Innovation releases
that include many enhancements and new capabilities which will also be included in the next Long Term
20 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
 release. Innovation releases are designed to enable customers to continuously use leading-edge
technologies to rapidly develop or deploy new applications or augment existing applications. Support for
Innovation Releases includes at least 2 years of Premier Support, but there is no Extended Support.
Production workloads can be deployed on Innovation Releases if upgrading within 2 years to a newer
release is factored into the deployment plan.

6.8 Interim Patch

When a customer cannot wait for the next RU or PSU, Oracle will create an interim patch that contains
one or more fixes. These patches are not tested as thoroughly as new releases or proactive patches.

6.9 Long Term Release

Oracle Database Long Term Releases are ideal for use cases that benefit from less frequent upgrades to
newer releases. Long Term Releases offer the highest level of stability and the longest length of error
correction support. These releases have 5 years of Premier Support followed by at least 3 years of Extended
Support. When combined with Extended Support, customers typically have almost 4 years to upgrade from
one Long Term Release to the next Long Term Release.

6.10 Major Release

Major Release is the release model historically used for most Technology products. For Oracle Database,
the last Major release was Oracle Database 12.1. A major release contains new features, technical
upgrades, and architectural changes. Subsequent releases in the Major release family are known as Patch
Set releases.

6.11 Merge Patch

A combination of multiple conflicting bug fixes into a single interim patch.

6.12 Patch Conflict Resolution

If interim patches are used in conjunction with one of the proactive patching methods, then there may be
patch conflicts.

21 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
6.13 Patch Set Release

An integrated, cumulative, fully tested collection of fixes delivered as a full installation on top of a major
Database release. Patch Set numbers were denoted by the fourth digit in the version (e.g. 12.1.0.1 was the
initial 12.1 release and 12.1.0.2 was a Patch Set release) For 11.2, the Patch Set releases were: 11.2.0.2,
11.2.0.3 and 11.2.0.4. For 12.1, the only Patch Set was 12.1.0.2. Extended Support normally only applies
to the terminal or final Patch Set of a Major release.

6.14 Patch Set Update (PSU)

A cumulative, well-tested, proactive quarterly recommended patch that contains the most critical
fixes. PSUs allow customers to apply one patch to avoid many problems. PSU patches are created
during the Premier and Extended Support timeframes for any Patch Set that is covered under the
Error Correction grace period. For Oracle Database, only Upgrade Support releases 11.2.0.4 and
12.1.0.2 are delivering PSUs and only until December 31, 2023.

6.15 Regression
A new bug introduced or revealed as part of a new release or interim patch.

6.16 Release Update (RU)

Starting with Oracle Database 12.2.0.1, an RU is a cumulative, thoroughly tested, proactive quarterly
recommended patch that contain the Security fixes and the most critical non-Security fixes. RUs allow
customers to apply one patch to avoid many problems. RUs may also contain a small number of
enhancements or new features when needed. RUs are created during Premier Support for Innovation
Releases and during Premier and Extended Support for Long Term Releases. Where implemented for a
product, RU + MRP patches replaces proactive bundles, PSU and SPU patches.

6.17 Release Update Revision (RUR)

RURs have been deprecated. They were a quarterly, cumulative, proactive patch containing fixes for
regressions introduced in the applicable RU plus new security updates for the quarter. Where implemented
for a product, RUR patches replaced SPU patches.

22 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
6.18 Security Patch Update (SPU)

An iterative, cumulative patch consisting of security fixes. Previously known as Critical Patch Update.
Only Oracle Database 11.2.0.4 is currently releasing an SPU.

23 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
7 ADDITIONAL DATABASE RESOURCES

For more information about preparing a maintenance plan for your release, see the following
My Oracle Support notes:
• Primary Note for Database Proactive Patch Program (Doc ID 888.1)
• Release Schedule of Current Database Releases (Doc ID 742060.1)
• Oracle Doc: Oracle Database Patch Maintenance

24 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
APPENDIX A– OTHER TECHNOLOGY PRODUCTS

A.1. ENTERPRISE MANAGER: Base Platform and Plug-ins

Grace Period: up to 1 year
Enterprise Manager Base Platform (and corresponding EM Plug-ins that are supported with the base platform) utilizes
the Major Release model which includes Patch sets, quarterly PSU, SPU, and monthly Plugin and Agent Bundle
patches.
When newer plug-ins release for a given EM Base Platform (e.g. 13.5, 13.4, 13.3), the plug-in release is called the PG
Release. Oracle gives you one year to upgrade to the newer release by offering a one-year grace period that starts
with the release date of the new release. Oracle will continue to create quarterly and monthly patch bundles for EM
Base Platform or Plug-in releases that fall within the one-year grace period.

EM Base Platform (Cloud Control)

Example: EM Base Platform 13.2.0.0 released Oct 2016. EM base Platform 13.3.0.0 release July 2018. Oracle created
patches for EM 13.2 Agent and OMS until July 2019.

EM Plug-ins
Example: Oracle Fusion Middleware Plug-in 13.2.1.0 released Oct 2016 (with EM Base Platform13.2.0.0). Oracle
Fusion Middleware Plug-in 13.2.2.0 released March 2017 with the PG release. The 13.2.1 FMW Plug-in was covered
under error correction until March 2018 (one year after the release of 13.2.2 FMW Plugin).
Exceptions:
Critical Patch Update Program and EM Plug-ins:
Patches will be provided for EM Plug-ins under error correction guidelines with the following exception: If
there is a later release of an EM Plug-in which includes the security vulnerability fixes, then the
recommendation will be to upgrade to the new EM Plug-in release and patches will be available only "on-
request".

Criteria for Considering Enterprise Manager Interim Patch Requests includes but is not limited to:

• OMS or Agent hangs, unable to start, hangs or crashes repeatedly

• Failure of key functionality, (e.g. Blackout, Notifications, Jobs, SLA, etc.)

• Loss of functionality in the console user interface o Unable to run an automated mass-deployment
action (e.g. Deployment Procedure, Agent Patching)

• Severe performance problems: (e.g. Console, OMS, Agent)

• Permanent data corruption to the repository o Bug fix is not implemented in a later patch set for the
release you are running

• No workaround available/inability to use workaround because due to business/technical reason

• Technical Feasibility: if a fix requires too many lines of code to be changed, Oracle may determine
the bug fix cannot be safely implemented as an interim patch Error Correction Policy

25 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
A.2 TIMES TEN IN-MEMORY DATABASE
Time Ten In-Memory Database utilizes the Major Release model which includes Patch Sets.
Patch Set version numbers:
Starting with Times Ten 18.1, patch sets are distinguished by a change in the 3rd digit of the version number
(e.g. 18.1.1.1.0 and 18.1.2.1.0). Patch sets for earlier versions of Times Ten are distinguished by a change in
the 4th place of the version number.
Grace Period: 1 year for interim patches and SPUs from the release of each patch set or bundle on each
different platform. Interim patches for Times Ten In-Memory Database are always cumulative and will include
all fixes made available in previous interim patches for the applicable patch set release.

A.3 ESSBASE
This document describes how Oracle delivers error correction for Oracle Essbase in the form of Annual Releases,
Release Updates (RU) and Release Update Revisions (RUR) for releases under Premier and Extended Support (but not
Sustaining Support), and is intended to complement the Lifetime Support Policy. The Error Correction Policy defines
the policies and practices surrounding the patching methodology and the grace period for which prior Release
Updates (6 months) are eligible for correction.

Relationship to Lifetime Support Policy:

The Lifetime Support Policy describes, for all Oracle products, the duration of support for Annual releases
and the support services delivered in each phase of a product’s life. All versions of an Annual release,
including Release Updates, are subject to the timelines provided for the corresponding Annual release. This
Error Correction Policy document describes how we deliver error corrections. This includes policies on how
long we will create new fixes on previously released versions including Release Updates (RU).

Terminology:
Effective with the October 2020 release of Essbase 21C, Release Updates (RU) and Release Update Revisions
(RUR) replaced the Patch Set Update (PSU) and Patch Set Exception (PSE) strategy. The new naming/version
conventions for Oracle Essbase releases are as follows:

• A version number has five positions

• The first position denotes the Annual release number, YY.1.0.0.0. For example, 21.1.0.0.0 is an
Annual release

• The second position denotes the Release Update (RU). When the Release Update is 1 that indicates
the original Annual Release. Subsequent Release Updates will increment the second position. For
example, 21.2.0.0.0 is the first Release Update of 21.1.0.0.0

• The third Position denotes the Release Update Revision (RUR). For example, 21.2.3.0.0 is the third
Release Update Revision of the Release Update 21.2.0.0.0 Error Correction Policy Oracle Corporation
01-MAY-2021 Page

• The fourth and fifth digits are reserved for release identification and are not used for error correction
timeline.

Grace Period: up to 6 months.

26 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public
 You have up to 6 months from the release of a Release Update to plan for and install the new Release
Update. During this period, we will create new bug fixes for the previous Release Update. For example, 21.2
was released in December 2020 followed by 21.3 in July 2021. We will create new fixes for both 21.2 and
21.3 through January 2022. After January 2022, new fixes for 21.2 will cease on all platforms and we will
only create new fixes for 21.3.

Exceptions: none

Connect with us
Call +1.800.ORACLE1 or visit oracle.com. Outside North America, find your local office at: oracle.com/contact.

blogs.oracle.com facebook.com/oracle twitter.com/oracle

Copyright © 2023, Oracle and/or its affiliates. This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is
not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document.
This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission.

Oracle, Java, MySQL, and NetSuite are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

27 Oracle Database (11g, 12c, 18c) and Other Technology Products / Version 2.1
Copyright © 2023, Oracle and/or its affiliates / Public