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)

Proactive Maintenance with RUs and MRPs

Proactive maintenance is accomplished by proactively applying a routine quarterly patch bundle (Release Update) that is available from the My Oracle Support (MOS) Customer Portal for each Oracle Database software release.

Release Updates (RUs) are release quarterly: Third Tuesday of January, April, July and October. Each RU will be given a maximum of six Monthly Recommended Patches (MRPs), released monthly.

Patch 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 patch updates are announced on the Critical Patch Updates, Security Alerts and Bulletins page each page each January, April, July, and October. Monthly Recommended Patches are released each month in between a quarterly Release Update, and are cumulative bundles of recommended patches. To receive email notifications when quarterly patch bundles are available, subscribe to Oracle Security alerts.

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 (Discontinued January 2023).
  • 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.

Monthly Recommended Patches (MRP)

Starting with update 19.17, Oracle is providing MRPs for Linux x86-64 to provide proactive patching between Release Updates.

In October 2022, starting with RU 19.17, Oracle is modifying its proactive patch program between Release Updates to use Monthly Recommended Patches. Release Update Revisions (RURs) are deprecated, and planned to be discontinued after January 2023. MRPs provide many of the same features of the RUR patches. However, they are offered only for Oracle Database 19c on Linux x86-64 platforms.

MRPs will be delivered for each RU in the 6 months following each RU's release, starting with Oracle Database 19c RU19.17 (mid-October, 2022). 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, 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 a collection of one-off patches 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 patches, and 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 one-off are installed from the MRP.

MRPs are provided as separate patches for the database (RDBMS), Oracle Clusterware (OCW), Advanced Cluster File System (ACFS) and Rapid Home Provisioning (RHP). Each MRP is packaged as a bundle of One-off patches that you can apply by using the command opatch napply. You can apply or rollback by using the opatchauto tool.

Each MRP includes the latest critical 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 succeeding MRP, then they will be fixed in later MRPs.

MRPs are characterized as follows:

  • MRPs are cumulative: each new MRP will contain the patches in any earlier MRPs released for a given release update, as well as the current set of one-off patches that Oracle recommends for the RU plus the current set of recommended one-off patches for the RU documented in Oracle Database 19c Important Recommended One-off Patches (Doc ID 555.1)
  • MRPs do not change the release number
  • MRPs are deployed using Opatchauto
  • MRPs are available only on the Linux x86-64 platform

RUs and MRPs Content Differences

There are content differences between release updates (RUs) and monthly recommended patches (MRPs).

The following table describes the differences:

Criteria Release Update (RU) MRPs
Cadence Quarterly Monthly for Release 19c on Linux x86-64
Zero downtime (ZDT) RAC Rolling RAC Rolling
Security fixes Included May include CPU Alerts and high CVSS fixes
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 Included
Supported operating systems All supported platforms Release 19c on Linux x86-64

Monthly Recommended Patches (MRPs) are offered for Oracle Database 19c on Linux x86-64. Both RUs and MRPs 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.

For Oracle Database on Linux x86-64 platforms, RUs and MRPs are designed to coexist and allow future RUs and MRPs to be installed.

Moving from one MRP to the next (for example 221115 to 221220) results in taking up all the functional fixes in the underlying RU (in this case 19.17), but with an additional month of more recent patch updates.

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 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 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 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 1-1 Apply the next RU each quarter

The following table shows an example of how you can apply a release update each quarter. Starting in October, you install RU 19.17.0. In January, you install RU 19.18.0. In April, you install RU 19.19.0. In July, you install RU 19.20.0. In October, you install RU 19.21.0.

Patch Type October January April July October
RU 19.17.0 19.18.0 19.19.0 19.20.0 19.21.0

Example 1-2 Apply the Monthly Recommended Patches (MRP) for an RU each month on Linux x86-64

Another proactive patching strategy for Linux-x86-64 platforms is to regularly apply the latest Monthly Recommended Patch (MRP) for a specific Release Update that is already installed. MRPs are created for six (6) months for each RU release, and made external on the third Tuesday of the month. MRPs are provided only for the 19c release from the 19.17 RU onward on Linux x86-64 platforms.

MRPs are installed using the Opatchauto utility. The MRP tracking patch Abstract or Subject indicates to which database RU the MRP applies, and the release date for the MRP in the form of RU-number.MRP-number, where RU-number is the numeric value of the RU, and MRP-number is the numeric value of the MRP. The MRP number designates the date on which the MRP is released.

For example:

Patch 34522319 - DATABASE MRP 19.17.0.0.221115

This MRP patch indicates that patch 34522319 is an Oracle Database MRP that can be applied on top of RU 19.17, and the MRP release date is 2022 (year) 11 (month), and 15 (day), corresponding to 15 November 2022.

The following tables show an example of how you can apply RU 19.17.0, released October 18, 2022, and then proceed to update that RU with MRPs for six months, starting in November 2022 and continuing until April 2023, when the last MRP for 19.17.0 is released. In May 2023, you then update to RU 19.18.0, released in January 2023, and update RU 19.18.0 with the April 2023 or May 2023 MRP for RU 19.18.0. In the tables, n/a designates a month where an MRP does not apply, because the RU that it updates is not released.

Table 1-1 Patch Schedule for RU 19.17.0

MRP October 2022 November 2022 December 2022 January 2022 February 2022 March 2022 April 2022
MRP for 19.17.0 RU n/a 221115 221220 230117 230221 230321 23418

Table 1-2 Patch Schedule for RU 19.18.0

MRP January 2023 February 2023 March 2023 April 2023 May 2023 June 2023 July 2023
MRP for 19.18.0 RU n/a 230221 230321 230418 230516 230620 230718

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.

Streamlining Your Update Experience with Oracle Update Advisor

Oracle Update Advisor is a software update recommendation framework that provides accurate, up-to-date information to keep software at recommended versions.

What is Oracle Update Advisor

Oracle Update Advisor analyzes your Oracle Database and Grid Infrastructure homes, identifies necessary updates, and delivers preconfigured deployment packages.

Maintaining software is not easy. To understand what you need to maintain your software enterprise security and functionality, administrators must review multiple product information sources, including My Oracle Support documents, and support recommendation technical briefs. You then must apply that information in accordance with your maintenance polices.

Streamlined Access to Updates

Oracle Update Advisor provides you with a powerful software update recommendation framework to streamline your maintenance. The advisor analyzes your Oracle Database and Oracle Grid Infrastructure homes, and identifies up-to-date guidance based on your defined maintenance policy, in a single, easy-to-understand report. Oracle Update Advisor also provides you with a preconfigured, fully functional gold image zip file that you can use to simplify the deployment of consistent operating system and Oracle software updates across your enterprise.

The Oracle Update Advisor commands are added to the Configuration Assistant (DBCA) and Oracle Fleet Patching and Provisioning (FPP). With the release of Database Configuration Assistant Utility (dbcactl) , a lightweight self extractable executable version of the Database Configuration Assistant, DBCA now also supports Oracle Database 19c. Oracle Update Advisor is not available with Oracle Database 21c. These commands enable you to provide to Oracle information that can help you to maintain the database and Grid Infrastructure software at recommended versions. Other Oracle tools are planned to interact with the Oracle Update Advisor in the future.

Accurate Software Health Status, Up-to-Date Version Guidance

Oracle Update Advisor provides two fundamental functions:

  • Software Status
  • Software Recommendations

Software Status indicates whether the currently installed software meets Oracle's current recommendations. When the installed software does not meet current recommendations, Oracle Update Advisor provides a list of Software Recommendations and also a software image of updates and maintenance fixes that you can use to bring your software up to the current recommendations for your software. That image is then used to create a new Oracle Home that meets the software recommendations.

How Do I Get Started with Oracle Update Advisor

To get started with Oracle Update Advisor, you just need your Oracle user information, secure HTTP, and a supported Oracle software maintenance tool.

What do you need?

Using Oracle Update Advisor is simple, as it enhances the use of features you already use. To enable Oracle Update Advisor functionality, you just need the following:

  • A valid Oracle Support contract, Customer Support Identifier (CSI) number, and a My Oracle Support user
  • Secure HTTP (HTTPS) network connectivity to Data Transport Services (DTS), https://transport.oracle.com to transport information for obtaining proactive advice on product use and configurations
  • Oracle Object Store service, which is required to download the Oracle Update Advisor image.

Note:

Oracle Update Advisor uses Data Transport Services (DTS) to handle customer registration for Oracle Update Advisor, to upload configuration data (such as RU and patch inventory), and to deliver patch update status and recommendations.

How does it work?

Using Oracle Update Advisor can be as simple as 1, 2, 3:

  1. Register a My Oracle Support user for the Oracle Update Advisor service.
  2. Use either Database Configuration Assistant with the Database Configuration Assistant Utility (dbcactl) command, which includes the Oracle Update Advisor options, or Fleet Patching and Provisioning (FPP) to run a check on the software status of an installed Oracle home. The dbcactl command syntax is identical with the dbca command syntax,
  3. Review the status report. If the status is not green, then download and install the recommended software image.

Note:

the Database Configuration Assistant Utility software package is only available on Linux.

Example of Using Oracle Update Advisor with DBCA

See how you can use Database Configuration Assistant (DBCA) with the Oracle Update Advisor features to simplify proactive checks during maintenance.

If your preferred patching tool is DBCA then you just need to add an Oracle Update Advisor command to your patching process.

For Database Configuration Assistant Utility (dbcactl), you must first download and install the utility from Oracle Support (Support for Oracle Cloud Infrastructure and Cloud applications). Refer to "Database Configuration Assistant Utility (dbcactl) - Standalone Software Package (Doc ID 3099785.1)".

To register the user for Oracle Update Advisor, use the following command syntax, where sso_username is the name of the Oracle user account, and csi_number is the Customer Support Identifier (CSI) number

dbcactl -managePatches -silent -registerUser -ssoUserName sso_username -csiNumber csi_number

To check software service, use the following command syntax:

dbcactl -managePatches -checkPatchStatus -silent

Example of Using Oracle Update Advisor with Oracle FPP

Oracle recommends that you use Oracle Fleet Patching and Provisioning (Oracle FPP) with the Oracle Update Advisor features to maintain Oracle Real Application Clusters (Oracle RAC) databases.

To manage the maintenance updates in your cluster, you use the Oracle Fleet Patching and Provisioning Control (RHPCTL) command-line utility with Oracle Update Advisor commands.

For maintenance with Oracle Update Advisor, you use Oracle Fleet Patching and Provisioning in Local Mode. This enables you to perform version updates on a local Oracle RAC Cluster without any configuration except for connectivity to the Oracle Update Advisor. See how in this example:

  1. Register with Oracle Update Advisor using the command rhpctl manage updateadvisor update. The syntax is as follows:

    $ rhpctl manage updateadvisor 
          {-registeruser -ssousername <sso_username>
                [-csinumber <csi_number]
                [-proxyserver <proxy_server> -proxyport <port_number>
                      [-proxyuser <proxy_user>] ]
                [-endpoint <endpoint_url>] |
           -unregisteruser}

    These options are as follows:

    • -registeruser: Register user to Oracle update advisor
    • -ssousername <sso_username>: SSO user name
    • csinumber <csi_number>: Customer Support Identifier (CSI)
    • -proxyserver <proxy_server>: Proxy server IP/name
    • -proxyport <proxy_port>: Proxy server port number
    • -proxyuser <proxy_user>: Proxy server user name
    • -endpoint <endpoint_url> Oracle Update Advisor end point URL
    • -unregisteruser Unregister the user from Oracle Update Advisor

    In this example, the My Oracle Support user is enterprise1, the CSI number is 123456789, the proxy server is 192.0.2.1, the proxy port is 20001, and the proxy user maint1:

    rhpctl manage updateadvisor -registeruser --ssousername enterprise1 -csinumber 123456789 -proxyserver -192.0.2.1 -proxyport 20001 -proxyuser maint1

  2. Use the command rhpctl evaluate patch to check the status of the database or Grid Infrastructure home that you are maintaining. In this example, we check the Oracle Grid Infrastructure image GI_1928:

    rhpctl evaluate patch  -image GI_1928 iso -path 
  3. After you validate the software installed on that test system, you can deploy the gold image software version on your production environment

This is a simple example. For examples using a centralized approach, you can refer to the Oracle Fleet Patching and Provisioning documentation. With Oracle Fleet Patching and Provisioning, you can centrally manage a complete Oracle Database landscape, including Oracle Exadata, Oracle Grid Infrastructure, Oracle Database, Oracle Restart, and Oracle Single instance deployments.

Monthly Recommended Patches (MRPs)

For Linux x86-64 platforms, MRPs provide a method to apply all Oracle recommended fixes easily for the current RU.

Monthly Recommended Patches (MRPs) are a collection of recommended interim ("one-off") fixes that are provided at monthly intervals using a single downloadable patch. Each MRP provides update content updated monthly after the RU associated with that monthly update is released, up to six months after the release date of the RU. 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 encountering known issues fixed in the most recent updates.

Additionally, you should install the following:

  • The OJVM patches where the JVM component is available in an Oracle Database.
  • 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.

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 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 with Oracle Fleet Patching and Provisioning (Oracle FPP)

Oracle recommends the Oracle FPP service as the maintenance method for Oracle Database deployed with Oracle RAC, Exadata, and Oracle Data Guard.

The Oracle Fleet Patching and Provisioning (FPP), which is a service in Oracle Grid Infrastructure, manages software homes on the cluster hosting the Oracle Fleet Patching and Provisioning Server itself. It enables mass deployment and maintenance of standard operating environments for databases, clusters, and user-defined software types. FPP also helps you to install clusters and provision, patch, scale, and upgrade Oracle Grid Infrastructure and Oracle Database 12c release 2 (12.2), and later releases, and Oracle Exadata stack with Release 19c (19.17 and later releases). FPP can also patch both single-instance Oracle Databases and Oracle Real Application Cluster configurations. You can also use FPP to provision applications and middleware.

You can use Oracle Fleet Patching and Provisioning in any of the following modes:

  • Using "Lite mode" (Oracle Fleet Patching and Provisioning Server in local mode also called FPP Lite Mode). This mode is the default configuration when you install Oracle Grid Infrastructure. FPP Lite Mode operation enables you to perform Oracle Grid Infrastructure and Oracle Database patching operations on the local cluster in a simplified environment without having to register or deploy gold images. Deploy either the Oracle Grid Infrastructure or the Oracle Database patched home and run the patch operation using either the rhpctl move gihome or rhpctl move database command, specifying the source and destination paths instead of working copy names.
  • Using a central server (Oracle Fleet Patching and Provisioning Server). The central server stores and manages standardized images, called gold images. You can deploy gold images to any number of nodes across a data center. You can use the deployed homes to create new clusters and databases, and patch, upgrade, and scale existing installations.

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

This section lists frequently asked questions.

Do proactive patches include optimizer fixes?

  • "Windows Database Bundle Patch" can include optimizer fixes.
  • Oracle Database RUs 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 19c (19.3.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 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.

Platform Environment DB Version Methods
Unix platforms Exadata 19.3.0.0 and later releases QFSDP for Exadata, OJVM Update, TZ
Linux Platforms Exadata 19.3.0.0 and later releases QFSDP for Exadata, OJVM Update, TZ, MRP
Unix platforms RAC 19.3.0.0 and later releases GI Update, OJVM Update, Combo, TZ
Linux platforms RAC 19.3.0.0 and later releases GI Update, OJVM Update, Combo, TZ, MRP
Unix platforms Non-RAC 19.3.0.0 and later releases DB Update, OJVM Update, Combo, TZ
Linux platforms Non-RAC 19.3.0.0 and later releases DB Update, OJVM Update, Combo, TZ, MRP
Windows platforms All 19.3.0.0 Windows Bundles, TZ