In this article, you can learn about patch delivery methods for Oracle Database 19c and later versions.

Introduction to Oracle Database Patch Maintenance

Learn about the differences between reactive patch maintenance and proactive patch maintenance.

Reactive Patches react to specific maintenance issues. They are characterized as follows:

  • Usually delivered as “Interim Patches”
  • Historically known as “one-off” 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

Proactive Patches provide recommended updates for all Oracle Database customers. Proactive patches employ bundles of patches optimized to be delivered together. Starting with Oracle Database 23ai, these patch bundles will also be provided as gold images.

Proactive patches (patch bundles) are characterized as follows:

  • Address high impact bugs that affect a given configuration
  • Contain proven low risk fixes
  • Include cumulative of prior fixes
  • Go through extra levels of testing, determined by the features affected by the patch
  • Are available on "My Oracle Support" by clicking on the Patches & Updates tab
  • Are available as Release Updates (RU) and Monthly Recommended Patches (MRPs)

Starting with Oracle Database 23ai, for proactive patch bundles, Oracle recommends that you perform software maintenance using one of the following methods:

  • Database Configuration Assistant (DBCA): Use DBCA as the recommended software maintenance method for single-instance Oracle Databases.
  • Oracle Fleet Patching and Provisioning (FPP): Use FPP as the recommended software maintenance method for Oracle Real Application Clusters (Oracle RAC) databases, and for Oracle Databases deployed with Oracle Data Guard. In addition, Oracle recommends that you use FPP for larger database fleets, and with Exadata databases.

You can continue to use OPatch and OPatchAuto for in-place and out-of-place patching (installing the software update into a new Oracle home). Oracle recommends that all patch operations are performed as Out-of-Place patching.

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)
  • Oracle Database 19c and 23ai Important Recommended One-off Patches (Doc ID 555.1)
  • Release Schedule of Current Database Releases (Doc ID 742060.1)

In-Place and Out-of-Place Patch Maintenance

Oracle recommends you perform Out-of-Place patch maintenance. Learn about the differences between In-Place and Out-of-Place patching.

In-Place Patching means that you have one single Oracle home, and you apply the next Release Update (RU) or one-off patch as a patch to this Oracle home. Out-of-Place patching means that you move the database stack to run from a new Oracle home that is at the desired level of software version. Oracle releases the RU as software images that you can download to set up the new Oracle home. After the home is set up, the database stack can be moved to operate from this new Oracle home.

Understanding Out-of-Place Patching

Out-of-Place patching is performed by deploying gold images into a new Oracle home. This method has many benefits, including reducing downtime, reducing the risk of patch deployment issues, reducing the time required for switching services from the existing home to the updated home, and generally simplifying the process of deployment.

As a best practice, Oracle recommends that you use Out-of-Place patch maintenance. For simplicity and ease of deployment, Oracle also recommends that you use the specific Oracle patch maintenance utilities we recommend for your configuration type. The recommended utilites are Database Configuration Assistant (DBCA) for single-instance databases, and Oracle Fleet Patching and Provisioning for Oracle Real Application Clusters (Oracle RAC) and Oracle Database deployments using Oracle Data Guard.

Understanding In-Place Patching

In-Place patching is performed by applying patch binaries to an existing Oracle home.You can use In-Place Patching to deploy individual patches as well as RUs using either OPatch or OPatchAuto. In this case, you deploy the RU or patch to your existing Oracle home in the form of binary patches. However, In-Place patch maintenance requires more manual work, and can be more complex to perform successfully. For most customers, Oracle strongly recommends that you choose Out-of-Place patching.

Quarterly Release Updates (RUs) are created with the intention to merge the latest RU into the preceding RU, as cumuilative patch update bundles. Release Update Revisions (RURs) and one-off patches are also built to deploy in an Oracle home with a specific RU. As a result, before you can deploy the latest RU with cumulative updates, you need to remove patches deployed for the earlier different RU from the existing Oracle home before you can apply the latest RU to your existing Oracle home.

When you perform an in-place Oracle home patch update, you must stop all Oracle Database instances using that existing Oracle home, so you require a longer downtime maintenance window to perform manual patch management. Depending on the complexity of your patch environment in the existing Oracle home, the downtime required for this work can be significant. If an issue occurs, then you will have to create a new Oracle home as part of your recovery process. And even if you clone the Oracle home, you also clone the Oracle home history, which can create unexpected complications.

Proactive Maintenance with RUs and MRPs

Proactive maintenance is the process of proactively applying the routine quarterly Release Update, and optionally, applying Monthly Recommended Patches to update the Release Update patch.

Oracle delivers two types of proactive content: Release Updates, and Monthly Recommended Patches. These software updates are available from the My Oracle Support (MOS) Customer Portal for each Oracle Database software release.

About Release Updates and Monthly Recommended Patches

Release Updates (RUs) are released quarterly, typically on the third Tuesday of January, April, July and October. To help to ensure your software performance and security, the RUs are required updates for Oracle software. Oracle recommends that you update your software quarterly, when the RUs are released.

Monthly Recommended Patches (MRPs) are optional software updates that are applied to the RUs. They contain recommended updates and fixes of known issues, grouped together for ease of deployment. These software updates are released monthly for software deployed on Linux systems. Each RU will be given a maximum of six Monthly Recommended Patches. The MRP updates are additional, optional fixes applied on top of a specific RU.

For platforms other than Linux, in place of MRPs, you can continue to download recommended interim patches and known issues patches to the Oracle software home.

Software updates are announced in the following locations

  • Primary Note for Database Proactive Patch Program (Doc ID 888.1)
  • Monthly Recommended Patches (MRPs)
  • Critical Patch Updates, Security Alerts and Bulletins

Quarterly release updates are announced on the "Critical Patch Updates, Security Alerts and Bulletins" page each January, April, July, and October. Monthly Recommended Patches are released each month in between a quarterly RU, and are cumulative bundles of recommended patches. To receive email notifications when the quarterly RU software updates are available, subscribe to Oracle Security alerts.

Recommended Apply Frequency for Proactive Maintenance Patches

Apply frequency defines how often you apply an update to the database software. The Apply Frequency does not define selecting earlier Release Update or Monthly Recommended Patches.

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 23.6.0.24.10.

  • 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. For example, 23.6.0.0 designates the fifth quarterly RU for Oracle Database 23ai.
  • The third field is reserved for future use and is currently always set to 0.
  • The fourth field indicates the year the RU was released.
  • The fifth field represents the month the RU was released.

An RU is always Oracle RAC Rolling installable.

Monthly Recommended Patches (MRP)

Oracle provides MRPs for Linux x86-64 to provide simplified recommended and interim software updates between the quarterly Release Updates.

MRPs are a collection of recommended and interim software updates bundled together. Unlike an RU, an MRP does not affect the release revision number. The release number continues to be designated by the RU number. The MOS Conflict Checker will treat the MRP fixes as it does with other bundled software updates. Regular conflict resolution will take place. The patches in an MRP are tracked in the Oracle Inventory directory (oraInventory), which is updated to indicate which interim patches are installed from the MRP.

MRPs can be provided for each RU in the 6 months following each RU release. MRPs will include the fixes documented in "Oracle Database Important Recommended Patches" (My Oracle Support Doc ID 555.1), plus the prior MRPs for the RU. While RUs will continue to be available on all supported platforms, and recommended and interim patches are available separately for all platforms, MRPs will only be offered on Linux x86-64 platforms. Customers can continue to request one-off patches on all supported platforms. If a particular month does not have new recommended fixes for an RU, then no MRP will be released, and an annotation will be added in the relevant My Oracle Support notes to avoid confusion. Merge patches will be provided if there are conflicts between one-off patches and the latest MRP for an RU.

MRPs are provided as separate software updates to the RU for the database (RDBMS), Oracle Clusterware (OCW), Advanced Cluster File System (ACFS) and Rapid Home Provisioning (RHP). You apply an MRP by using the command opatch napply. You can apply or uninstall an MRP by using the opatchauto tool.

MRPs are characterized as follows:

  • MRPs are cumulative: each new MRP will contain the recommended and interim software update in any earlier MRPs released for a given RU, as well as the current set of interim software updates that Oracle recommends for the RU plus the current set of recommended updates for the RU documented in Oracle Database 19c and 23ai Important Recommended One-off Patches (Doc ID 555.1)
  • MRPs do not change the release number
  • MRPs are deployed using OpatchAuto or Opatch with the napply option.
  • MRPs are available only on the Linux x86-64 platform
  • All fixes in the MRP will always be Oracle RAC Rolling and Oracle Data Guard Rolling installable.

Additional Proactive Patches

In addition to RUs and MRPs, 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 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 software in addition to Oracle Database software, then you should use the parallel Oracle Grid Infrastructure RU. These Oracle Grid Infrastructure RUs include everything that the parallel database RU contains.

Proactive Apply Frequency Patching Strategy

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

Apply frequency defines how often you apply an update to the database software. It does not define selecting a Release Update that is not the latest RU. Oracle recommends that you always update to the latest available RU for your release.

Release Update Lag and Apply Frequency

Oracle recommends you install the latest Release Update (RU), whenever you perform an installation. 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 1-1 Apply the Most Recent RU each quarter

This is the default plan for single-instance databases. The simplest maintenance schedule plan is to apply the latest Release Update (RU_Latest) quarterly, and never apply MRPs.

Note:

If you choose this strategy, then Oracle recommends that your apply frequency is quarterly (every three months).

Table 1-1 Quarterly RU Software Maintenance Plan (RU_N)

Apply Frequency Release Updates (RU_N)

Monthly

Not applicable

Quarterly

Every 3 months - Apply RU_Latest (N)

Semiannually

Every 6 months - Apply RU_Latest (N)

Annually

Every 12 months - Apply RU_Latest (N)

Example 1-2 Apply the most recent quarterly RU and most recent MRP for that RU

In this maintenance schedule example, to obtain the most current security and performance fixes, you install the latest RU (RU_Latest), and install the most recent MRP (MRP_N, where N is the most recent available MRP available for the latest RU). The latest MRP contains all recommended and interim fix patches from the previous MRPs published for that RU.

Note:

If you choose this strategy, then Oracle recommends that your apply frequency is quarterly (every three months).

Table 1-2 RU (RU_N) and Monthly Recommended Patches Software Maintenance Plan (MRP_N)

Apply Frequency RU (RU_Latest) + MRP_N

Monthly

Every 1 month - Apply RU_Latest + MRP_N

Quarterly

Every 1 month - Apply RU_Latest + Recommended_Latest_N

Semiannually

Every 6 months - Apply RU_Latest + Recommended_Latest_N

Annually

Every 12 months - Apply RU_Latest + Recommended_Latest_N

Reactive Maintenance with Interim Patches

All patch methods allow interim (or "one-off") patches to be installed, but the version of an interim patch that is required can vary depending on the patching method.

Microsoft Windows platforms do not support normal interim (also known as “one-off") patches. See Oracle Database - Overview of Database Patch Delivery Methods for 12.2.0.1 and greater (Doc ID 2337415.1) for details of current and historic proactive patches.

Interim patches are delivered on request as standalone patches for a given “defect, version, platform” combination.

  • Interim patches are provided on top of any release or Release Updates (RUs) for supported software versions as long as it is technically feasible to do so.
  • Interim patches go through basic functional, stress and performance sanity tests.
  • Interim patches are considered for inclusion in Release Updates (RUs) based on their technical severity or number of affected features.

Generally, instead of requesting an interim patch, Oracle recommends that you apply the most recent Release Update that includes the fix. For an additional discussion of the pros and cons of asking for interim bug fixes in patches instead of following an RU maintenance schedule, see Should I ask for a one-off bug fix or wait for the next Release Update (Doc ID 2648544.1).

Patch Conflict Resolution

If you choose not to use Gold Image patch maintenance, then interim patches used in conjunction with other proactive maintenance methods, including custom Gold Images, may cause patch conflicts.

Note:

Oracle recommends that you use one of the Quarterly Gold Image deployment methods for database maintenance. With Gold Image deployment, patch conflict resolution and merges are included as part of the Gold Image creation. Custom gold images do not have this optimization.

For the quarterly proactive patches (Quarterly Exadata Patch, RU, and MRPs), 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 My Oracle Support notes for patch conflicts.

Patching Oracle Database and Oracle GoldenGate

When you use Oracle GoldenGate with Oracle Database, you must ensure that Oracle GoldenGate processes are shut down before patching the database.

When you patch Oracle Database, and you are using Oracle GoldenGate, you must disable Oracle GoldenGate processes before starting to patch the database. The reason for this is that patches and upgrades can modify the RDBMS internal tables and views, which cause stored procedures that call them to be invalidated. All dependent objects are invalidated as well.

Frequently Asked Questions

Find answers to common questions, and learn details about how you can address common issues.

Do proactive patches include optimizer fixes?

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 23ai (23.4.0.0), 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 .Should I ask for a one-off bug fix or wait for the next Release Update (Doc ID 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.

Documentation Accessibility

Access to Oracle Support