OracleFree calculatorPDF, Excel, Word exportOracle Database

Oracle Database 19c Release Update Gap and Patch Window Calculator

This calculator shows how far your Oracle Database 19c home is behind a target Release Update, when each RU was released on the quarterly cadence, and how long the patch window will be for in-place or out-of-place patching with datapatch across your PDBs.

Your numbers

Current RU (number after 19.)

From opatch lspatches or DBA_REGISTRY_SQLPATCH. 19.15 = 15.

Target RU (number after 19.)

Oracle homes to patch

Database home plus Grid Infrastructure home, per node.

Minutes per home for OPatch apply

min

PDBs (or 1 for a non-CDB)

Datapatch minutes per PDB

min

Patching method

Home switch minutes (out of place)

min

Stop, repoint oratab and the listener, start in the new home.

Your results

Release Updates behind

Estimated patch window

90 min

In place: homes x OPatch minutes + datapatch per PDB. Out of place: home switch + datapatch per PDB; the new home is built before the window.

Months behind

36 months

Current RU release year

2,022

Current RU release quarter (1-4)

Target RU release year

2,025

Target RU release quarter (1-4)

Release quarters assume the quarterly cadence starting with 19.3 in April 2019 (19.4 July 2019, 19.5 October 2019, 19.6 January 2020 and so on). Confirm the patch number and date for your platform in the My Oracle Support note on Database 19 Release Updates and Revisions. Timings are estimates; measure them on a clone.

Save results:

Estimated patch window (minutes) vs PDB count

Sweeps PDBs (or 1 for a non-CDB) from 1 to 50, holding your other inputs fixed.

Get a reviewed patch plan

Send us your opatch lspatches output and PDB list and we will check one-off patch conflicts and draft the RU patch runbook for your ERP database.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to use it

Read the current RU from opatch lspatches or from SELECT patch_id, action, status, description, action_time FROM dba_registry_sqlpatch ORDER BY action_time. Enter the number after 19., for example 15 for 19.15. Enter the target, the number of Oracle homes to patch (database home and Grid Infrastructure home), your measured OPatch minutes per home, the PDB count and datapatch minutes per PDB. Choose in place or out of place. Out of place means you install and patch a new home ahead of time, so the outage is only the switch plus datapatch. The chart shows how the window grows with PDB count.

RU gap = target - current; months behind = 3 x gap.
Quarter index = RU - 3; year = 2019 + floor((index + 1) / 4).
19.3 = April 2019, 19.15 = April 2022, 19.19 = April 2023, 19.27 = April 2025, 19.29 = October 2025.

RUs are cumulative: jump straight to the target

Each 19c Release Update contains all fixes from earlier RUs, so moving from 19.15 to 19.27 is one patch, not twelve. Before applying, check that OPatch in the home meets the minimum version listed in the RU readme (download the latest OPatch, patch 6880880, and unzip it into the home). Run the conflict check against your one-off patches: $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./<patch_dir>. One-off patches not included in the target RU must be re-requested for that RU. For Grid Infrastructure use opatchauto as root, which patches the GI and database homes on a node together.

Datapatch and how to check the result

After the binaries are patched and the database is open, run $ORACLE_HOME/OPatch/datapatch -verbose. It applies the SQL portion to the CDB root, PDB$SEED and every open PDB, so open all PDBs first. Then check DBA_REGISTRY_SQLPATCH for a SUCCESS row for the new RU in each container, run utlrp.sql if invalid objects appear, and compare with opatch lspatches. A home at 19.27 with a registry still showing 19.15 means datapatch did not run or failed; its logs are under $ORACLE_BASE/cfgtoollogs/sqlpatch.

Gotchas for ERP databases

ERP vendors certify database patch levels separately: E-Business Suite has its own list of required database patches on top of each RU, and JD Edwards and PeopleSoft list supported database releases in the My Oracle Support Certifications tab. Out of place patching needs the listener, oratab, backup scripts and any hard coded ORACLE_HOME paths in ERP scripts updated. Datapatch time grows with the number of PDBs and the size of the RU's SQL changes, so measure it on a clone of production, not on an empty test database.

Frequently Asked Questions

Can I upgrade directly from Oracle 19.15 to 19.27?

Yes. Release Updates are cumulative, so apply the 19.27 RU directly to a 19.15 home after updating OPatch and checking conflicts with your one-off patches. Then run datapatch so the SQL changes reach every container. You do not apply the intermediate RUs.

When was each Oracle 19c Release Update released?

RUs follow a quarterly cadence in January, April, July and October. The on-premises base 19.3 shipped in April 2019, 19.4 in July 2019, and so on, which puts 19.27 in April 2025 and 19.29 in October 2025. Confirm patch numbers and any platform delays in the My Oracle Support note listing Database 19 Release Updates.

How do I find which 19c RU is installed?

Run $ORACLE_HOME/OPatch/opatch lspatches for the binaries, and query DBA_REGISTRY_SQLPATCH for the SQL level in each container. Both should show the same RU. SELECT banner_full FROM v$version also shows the full version, for example 19.27.0.0.0.

Does datapatch need downtime?

Datapatch runs with the database open, and Oracle supports running it with users connected for many RUs, but changes to busy packages can cause waits or invalidations. For ERP databases most teams run it inside the maintenance window with batch stopped. Check the RU readme for any patch that requires a quiet system.

If you want your team to ask patch inventories and the SQL patch registry questions in plain English across every database on your own servers, we can set that up.

Talk to an Expert Explore More Free Tools