Introduction

This article covers patch delivery methods for Oracle Database 12c Release 2 (12.2.0.1) and later versions.

One of the duties of a DBA is to maintain the Oracle Database software. There are two maintenance strategies:

For more information, see My Oracle Support Note 2337415.1. If you are interested in methods for Oracle Database 12c Release 1 (12.1.0.2) and older versions, then see My Oracle Support Note 1962125.1. For information about database releases (such as Oracle Database 18c, and so on), read My Oracle Support Note 742060.1.

Proactive Maintenance with RUs and RURs

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.

These patch bundles are announced in My Oracle Support Note 756671.1 and on the Critical Patch Updates, Security Alerts and Bulletins page each January, April, July, and October. To receive email notifications when quarterly patch bundles are available, sign up here.

Since Oracle Database 12c Release 2 (12.2.0.1), the quarterly bundle patching model uses Release Updates (RUs) and Release Update Revisions (RURs).

  • Release Updates (RUs)
    RUs are highly tested bundles of critical fixes which enable you to avoid known issues. They usually contain the following type of fixes: security, regression (bug), optimizer, and functional (which may include feature extensions as well).
  • Release Update Revisions (RURs)
    RURs include all fixes from their corresponding RU but only add new security and regression fixes. However, no new optimizer or functional fixes are included.
  • RUs and RURs Content Differences
    There are content differences between release updates (RUs) and release update revisions (RURs).
  • Additional Proactive Patches
    In addition to RUs and RURs, there are quarterly full stack download patches and combo patches, as well as other proactive patches.
  • Proactive Patching Strategy
    Oracle recommends that you keep your database and Oracle Grid Infrastructure software current by applying Release Updates (RUs).

Release Updates (RUs)

RUs are highly tested bundles of critical fixes which enable you to avoid known issues. They usually contain the following type of fixes: security, regression (bug), optimizer, and functional (which may include feature extensions as well).

Oracle recommends that you stay current by using RUs. By doing this, you minimize the chance of encountering known bugs and security vulnerabilities.

The nomenclature for the RU patches is a five-field number, such as 19.7.0.0.0.

  • The first of the five fields indicates the year that this annual set of new features (also known as, this release) was first available.
  • The second field shows the RU level that has been applied against that annual new features release. 19.7.0.0 would designate the seventh quarterly RU for Oracle Database 19c. Please note that several of the initial RUs are internal to Oracle and the first publicly available RU is often the forth quarterly RU, as in 19.4.0.0. That first publicly available RU is provided the next quarter after the release is publicly available.
  • The third field refers to the RUR.
  • The fourth field is reserved for future use and is currently always set to 0.
  • Although only the first three fields are commonly used, the fifth field may show a numerical value that redundantly clarifies the release date of the RU, such as 19.7.0.0.200414.

Note:

The nomenclature for the Oracle Database 12c Release 2 (12.2.0.1) RU patches is text-based because the Oracle Database 12c Release 2 (12.2.0.1) RU patches slightly pre-date the beginning of the use of the five-field numbering system. For example, the seventh quarterly RU for Database 12c Release 2 (12.2.0.1) RU patches would be 12.2.0.1.181016 (Oct 2018) Database Release Update.

Parent topic: Proactive Maintenance with RUs and RURs

Release Update Revisions (RURs)

RURs include all fixes from their corresponding RU but only add new security and regression fixes. However, no new optimizer or functional fixes are included.

Installing RUR changes the third digit of the database release. For example, 19.7.1.0 would designate the first RUR of the seventh quarterly RU for Oracle Database 19c.

It’s important to mention that there is no third RUR planned. The model allows only two RURs for each RU. Afterward, you have the option to either get the most recent RU or the latest RUR based on a newer RU. This enables you to take a more conservative approach to database maintenance for three or six months where you estimate your system is stable enough and you only want new security and regression fixes. However, you will have a greater likelihood of encountering known issues that are already fixed in a more recent update. Oracle recommends that you install the RUR after your environment reaches a stable state.

Parent topic: Proactive Maintenance with RUs and RURs

RUs and RURs Content Differences

There are content differences between release updates (RUs) and release update revisions (RURs).

The following table describes the differences:

Criteria Release Update (RU) Release Update Revision (RUR)
Cadence Quarterly Minimum quarterly or as needed
Zero downtime (ZDT) Included Included
Switch between RU and RUR Included Included
Security fixes Included Included
Regression fixes Included Included
Proactive functional fixes Included Not included
Optimizer plan changes (off by default) Included Not included
Functional enhancements (minor) Included Not included
Emergency one-offs Included Not included

Both RUs and RURs are cumulative bundle patches. Each of them include all the fixes of the previous patches. You can install directly whatever bundle patch as long as its year digits are the same as the digits of your current installation and the bundle was released at the same time or after your current installed version.

RUs and RURs are designed to enable you to switch back and forth between using RUs and RURs as desired.

Moving from one RUR to the next (for example Oracle Database 18.4.2.0 to 18.5.2.0) results in taking up all the functional fixes in the underlying RU (in this case 18.5.0), just six months later.

Watch the Oracle Database Quarterly Patching Model Overview video to understand the RU and RUR patches.

Oracle Database Quarterly Patching Model Overview video

Parent topic: Proactive Maintenance with RUs and RURs

Additional Proactive Patches

In addition to RUs and RURs, there are quarterly full stack download patches and combo patches, as well as other proactive patches.

Quarterly Full Stack Download Patch and Combo Patch

Oracle delivers a number of different patches packaged together, for example:
  • Quarterly Full Stack Download Patch for Exadata, which includes the quarterly Grid Infrastructure RU along with the OJVM update and other Exadata system patches in a single download.
  • Combo Patch of OJVM RU and Database RU

Other Proactive Patches

Oracle produces some proactive patches for very specific purposes outside of the normal update and revision cycle. Such patches are usually delivered as "Interim Patches". For example, special time zone patches are released every six months for customers who require systems to use latest time zone data.

Note:

If you are using Oracle Grid Infrastructure (GI) software in addition to Oracle Database software, then you should use the parallel GI RU. These Oracle Grid Infrastructure RUs include everything that the parallel database RU contains.

Parent topic: Proactive Maintenance with RUs and RURs

Proactive Patching Strategy

Oracle recommends that you keep your database and Oracle Grid Infrastructure software current by applying Release Updates (RUs).

RUs include the most recent security, regression, and critical fixes. Applying RUs minimizes the chance of encountering known bugs and security vulnerabilities. Staying current with RUs reduces the likelihood of requiring separate interim one-off patches which lead to unique software baselines and a potential for ongoing costly patch maintenance.

Example - Apply the next RU each quarter

The following table shows an example of how you could apply a release update each quarter. Starting in January, you install RU 19.6.0.0. Then in April, you install RU 19.7.0.0, then RU 19.8.0.0 in July, then RU 19.9.0.0 in October, and then finally, install RU 19.10.0.0 in January.

Patch Type January April July October January
RU 19.6.0.0 19.7.0.0 19.8.0.0 19.9.0.0 19.10.0.0
RUR-1 19.5.1.0 19.6.1.0 19.7.1.0 19.8.1.0 19.9.1.0
RUR-2 19.4.2.0 19.5.2.0 19.6.2.0 19.7.2.0 19.8.2.0

Example - Apply the second RUR each quarter

Another proactive patching strategy is to prioritize security updates before functional fixes. In such cases, you can choose to apply RURs instead of RUs. The RUR includes the latest security and regression fixes, but also contains the critical content that was released six months prior. By choosing to wait on taking new RU content by six months, you can take a more conservative approach to Oracle Database software maintenance, but you still risk the chance of hitting known issues that are fixed in the most recent RU. The main benefit of this patching strategy is that, if there are any regressions reported on the base RU or the first RUR, then they will be fixed in this second RUR.

The following table shows an example of how you could apply the second (also known as "final") RUR each quarter. For example, starting in January you apply RUR-2 19.4.2.0. In April you apply 19.5.2.0. In July you apply 19.6.2.0. In October you apply 19.7.2.0. And then finally, in January you apply 19.8.2.0.

Patch Type January April July October January
RU 19.6.0.0 19.7.0.0 19.8.0.0 19.9.0.0 19.10.0.0
RUR-1 19.5.1.0 19.6.1.0 19.7.1.0 19.8.1.0 19.9.1.0
RUR-2 19.4.2.0 19.5.2.0 19.6.2.0 19.7.2.0 19.8.2.0

Parent topic: Proactive Maintenance with RUs and RURs

Reactive Maintenance with One-off Patches

All methods allow one-off patches to be installed, but the version of a one-off patch that is required may vary depending on the patching method.

Windows platforms do not support normal “one-off patches”. See My Oracle Support Note 2337415.1 for details of current and historic proactive patches.

The one-off patches are delivered as standalone on request for a given “defect, version, platform” combination (also known as “Interim Patches”).

  • One-off patches are provided on top of any release or updates for supported version as long as technically feasible.
  • One-off patches go through basic sanity tests.
  • One-off patches are considered for inclusion in an update based on technical severity or blast radius.

Oracle recommends you to apply the update including the fix. For an additional discussion of the pros and cons of asking for one-off bug fixes instead of waiting on RUs, see My Oracle Support Note 2648544.1.

Which Patching Method to Use?

You may have reached a stable state and want to prioritize security updates before functional fixes. In such cases, you can apply RURs.

When you apply RUR-1, you lag with the update content by three months. When you apply RUR-2, you lag with the update content by six months. By waiting to install a new update content by three or six months, you take a more conservative approach to Oracle Database software maintenance, but you still risk the chance of hitting known issues fixed in the most recent updates.

Additionally, you should install the following:

  • The OJVM patches where Oracle Database uses the JVM
  • Interim patches only for specific issues that you know apply to your environment
  • A minimum of interim patches

Installing the latest update is a good way to reduce the need for interim patches.

Switching Between RUs and RURs

Oracle supports switching between RUs and RURs.

Oracle recommends applying an RU or RUR that is a super set of the RU or RUR currently installed so that fixes are not lost. At a high-level, the process is as follows:

  • Make note of the interim patches that are installed in the Oracle home.
  • Check for conflicts among the installed interim patches and the target RU or RUR.
  • As needed, request new interim patches.
  • When the interim patches are available, install the target RU or RUR and any required interim patches.

Patch Conflict Resolution

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

For the quarterly proactive patches (Quarterly Exadata Patch, RU, and RUR), Oracle proactively produces new interim patches for existing patches that would conflict. The new interim patches are usually released at the same time as the proactive patches.

For information about resolving patch conflicts, see the following documents:

Frequently Asked Questions

This section lists frequently asked questions.

Do proactive patches include optimizer fixes?

  • "Database Patch for Exadata" can include optimizer fixes for issues that arise from inaccurate optimizer results, but only in a form that enables or disables them individually, as required.
  • "Windows Database Bundle Patch" can include optimizer fixes.
  • Oracle Database RURs can include optimizer fixes for issues that arise from inaccurate optimizer results, but only in a form that enables or disables them individually, as required. RUs include optimizer fixes in the "disabled by default" state. For more information, see My Oracle Support Note 2147007.1, "Automatic Fix Control Persistence (FCP) for Database Proactive Bundle Patch ".

How can I tell what patching method an installation uses?

Review the opatch lsinventory output to see what patches are applied. RUs and RURs include a description of the patch name and version in the output.

What is the difference between "Windows Database Bundle Patch" and "QFSDP for Exadata" and so on?

These bundles are targeted at different environments. The latest versions include the same update content, but all other content is specific to the target environment. There may be some other common content but there are differences in content.

Do proactive patches affect the database version as reported in trace files and database views like V$VERSION?

For Oracle Database 12c Release 2 (12.2.0.1), the patch level in the ORACLE_HOME is reflected in the opatch lsinventory data, and for some patch types, the patch level is reflected in DBA_REGISTRY or DBA_REGISTRY_HISTORY. The DBA_REGISTRY_SQLPATCH view tells you the SQL patches that are applied to the database.

Should I ask for a one-off bug fix or wait for the next RU?

For a discussion of the pros and cons of asking for one-off bug fixes instead of waiting on RUs, see My Oracle Support Note 2648544.1.

How to apply patches? Use either the opatch utility or the OPLAN utility?

Refer to the README to learn how to install patches.

OPatch - Where Can I Find the Latest Version of OPatch?

See My Oracle Support Note 6880880.1 or My Oracle Support Note 224346.1

Current Database Proactive Patches

The following table gives information on available proactive database related patches by platform, environment, and version.

The short names that are used in the Methods column in the table are expanded in My Oracle Support Note 2337415.1. You can find detailed information about proactive database patches by reading My Oracle Support Note 2337415.1

Platform Environment DB Version Methods
Unix platforms Exadata 12.2.0.1 QFSDP for Exadata, OJVM Update/Revision, TZ
Unix platforms RAC 12.2.0.1 GI Update/Revision, OJVM Update/Revision, Combo, TZ
Unix platforms Non-RAC 12.2.0.1 DB Update/Revision, OJVM Update/Revision, Combo, TZ
Windows platforms All 12.2.0.1 Windows Bundles, TZ

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.