19c Release Update (RU) Application Checklist for EBS DBAs

If you support Oracle E-Business Suite on Database 19c, Release Updates aren't optional — they're a recurring fact of life. Every quarter (or close to it), a new RU lands, and every time, the same question comes up: what do I actually need to check before, during, and after applying it?

This post lays out a practical checklist you can reuse every cycle, built around the mistakes that most commonly turn a routine RU into a weekend-long incident.

1. Why RUs Matter for EBS Specifically

Unlike a generic database, EBS layers a large amount of custom PL/SQL, interMedia/Text indexes, and AD/FND schema objects on top of the core database. An RU that applies cleanly on a vanilla database can still break EBS-specific objects if datapatch doesn't run cleanly, or if EBS-specific interoperability patches haven't been applied for that RU level.

Important

Always check My Oracle Support for the EBS interoperability note that corresponds to your specific RU before applying it. Applying an RU without checking EBS certification/interop patches is one of the most common causes of post-patch breakage.

2. Pre-Application Checklist

• Confirm the target RU is certified for your EBS release and Database edition (check My Oracle Support certification pages, not just the RU release notes)

• Identify and download the EBS-specific interoperability patch for that RU, if one exists — these are often released a few weeks after the base RU

• Review the RU's known issues and bug fixes list for anything relevant to EBS (AD/TXK, Fusion Middleware, or interMedia-related fixes are the ones to watch)

• Take a full RMAN backup (or validated snapshot) immediately before applying — don't rely on a backup from days earlier

• Confirm sufficient space in the Oracle Home, $ORACLE_BASE, and the OPatch inventory location — RU staging can consume significant space

• Run OPatch conflict checks (opatch prereq CheckConflictAgainstOHWithDetail) against the current Oracle Home before applying

• Verify you're on a supported OPatch version — RUs frequently require a minimum OPatch version, and applying with an outdated OPatch is a common failure point

• Schedule a maintenance window that accounts for datapatch runtime, not just the OPatch apply itself — datapatch on an EBS-sized schema can take considerably longer than on a vanilla database

Tip

Run the pre-checks in a non-production clone first, even if it's just a quick sanity check. An RU that applies cleanly on a smaller or differently-configured non-prod instance can still surface unexpected conflicts on production due to one-off patches already in place.

3. Applying the RU — Step by Step

Step 1: Stop all instances tied to the Oracle Home

Shut down the database and any listener processes cleanly before touching the Oracle Home.

Step 2: Apply the RU with OPatch

$ export ORACLE_HOME=<db_oracle_home>
$ cd <RU_patch_directory>
$ $ORACLE_HOME/OPatch/opatch apply

Step 3: Start the database in upgrade mode and run datapatch

$ sqlplus / as sysdba
SQL> startup
$ cd $ORACLE_HOME/OPatch
$ ./datapatch -verbose

Step 4: Review the datapatch log carefully

Don't just check the exit code — open the log and confirm every SQL patch shows a successful status. Partial datapatch failures don't always stop the process outright.

Note

If datapatch reports failed or errored patches, do not proceed to the EBS-specific steps until the underlying SQL error is understood. Re-running datapatch blindly can mask the real issue.

4. EBS-Specific Post-Steps

• Apply the EBS interoperability patch for the RU, if applicable, using adop in the normal patching cycle
• Run AutoConfig on both the run and patch file systems to pick up any configuration changes
• Re-run EDBPC (the EBS Database Parameter Checker) to confirm no recommended parameters were reset or need adjustment after the RU — RUs occasionally touch parameter defaults
• Validate invalid objects in the database and recompile as needed:

$ sqlplus apps/apps_password
SQL> @$AD_TOP/sql/adzdshow.sql

• Check the FND and AD schema for any objects left invalid after the patch, and utlrp.sql if needed
• Confirm concurrent managers start cleanly and process a test request
• Spot-check a few core responsibilities (login, forms, OA Framework pages) before declaring the window closed

5. Common Failure Points to Watch For

6. Build a Reusable Runbook

Since RUs come every quarter, don't start from scratch each time. Keep a running document (or better, a checklist template) that captures:

• The certification note number for your current EBS/DB combination
• Space and OPatch version requirements confirmed for the last few RUs
• Any environment-specific one-off patches you always need to re-verify for conflicts
• Your actual maintenance window timing from the last few cycles, so estimates stay realistic

Summary

Applying a 19c RU to an EBS environment is more than an OPatch command — it's a sequence of certification checks, datapatch validation, and EBS-specific post-steps (interoperability patch, AutoConfig, invalid object checks). Most RU incidents trace back to skipping the EBS interoperability patch, an outdated OPatch version, or not reviewing the datapatch log closely enough. Build a runbook once, and every quarterly cycle gets faster and safer. Caution: Your use of any information or materials on this Blog is entirely at your own risk. It is provided for educational purposes only.

Reference: Check My Oracle Support for the RU-specific EBS interoperability note and the current EDBPC patch number (MOS KA1180) before every cycle.