Tuesday, May 19, 2026

OPatch vs ADOP — which patches use which tool in EBS R12.2

OPatch vs ADOP — Which Patches Use Which Tool in Oracle EBS R12.2 | punitoracledba

OPatch vs ADOP — Which Patches Use Which Tool in Oracle EBS R12.2

One of the most common questions from DBAs who are new to Oracle EBS R12.2 — and one that comes up regularly in interviews — is this: when do I use OPatch and when do I use ADOP?

The answer is straightforward once you understand that an EBS R12.2 environment is not a single layer. It has three distinct tiers — the database tier, the Fusion Middleware and WebLogic tier, and the EBS application tier — and each tier has its own patching tool. Using the wrong tool on the wrong tier does not just fail — it can leave your environment in an inconsistent state.

This post maps every patch type to the correct tool, explains why each tool is used where it is, provides the exact commands for each, and gives you a decision tree you can refer to during any patching session.

One rule to remember before reading further: adpatch is not used on R12.2. It was the patching tool for R12.1 and earlier. On R12.2, EBS application tier patches always use ADOP. This is non-negotiable — adpatch does not understand the dual-filesystem architecture of R12.2.

The Two Patching Tools — What They Are

OPatch

OPatch is Oracle's universal patching utility for Oracle software installations. It patches Oracle homes — the database home, the Oracle Fusion Middleware homes, and WebLogic homes. It works by modifying files inside a specific $ORACLE_HOME directory. OPatch knows nothing about EBS editions, dual filesystems, or ADOP sessions. It simply modifies the files in the Oracle home you point it to.

ADOP

ADOP — AD Online Patching — is the EBS-specific patching utility for the application tier. It understands the dual-filesystem architecture, the database edition model, and the five-phase patching cycle. It manages the entire online patching process from prepare through cleanup. ADOP is only used for EBS application tier patches — not for database or FMW patches.

Tool What It Patches Aware of EBS Editions Requires Services Down
OPatch Oracle homes — DB, FMW, WebLogic, OHS, Forms, Reports No Usually yes — DB must be shut down for DB patches
ADOP EBS application tier — PL/SQL, Forms, Reports, Java, seed data Yes — uses patch edition and dual filesystem No — except for brief cutover window

Which Patch Type Uses Which Tool

Patch Type Tool OS User Services During Apply
Oracle Database CPU (DB home) OPatch oracle DB must be shut down
Oracle JVM / OJVM patch (inside DB) OPatch + datapatch oracle DB shut down for OPatch, then DB up for datapatch
Oracle WebLogic Server (WLS) OPatch applmgr WebLogic Admin and Managed Servers must be down
Oracle Fusion Middleware (FMW) OPatch applmgr FMW services must be down
Oracle HTTP Server (OHS / Web Tier) OPatch applmgr OHS must be down
Oracle Forms and Reports home OPatch applmgr Forms and Reports services must be down
EBS Application Tier (CPU, one-off, RUP) ADOP applmgr Services stay up — brief cutover only
EBS NLS / Language patches ADOP applmgr Services stay up — brief cutover only
EBS AD and TXK codelevel patches ADOP applmgr Services stay up — brief cutover only
Java CPU patches (JDK in FMW homes) OPatch applmgr FMW services must be down for each Java home

Important for CPU patching: A full quarterly CPU cycle in EBS R12.2 uses both tools. OPatch is applied first to the DB home and all FMW homes. ADOP is applied after to the EBS application tier. Both are required — neither replaces the other.

Decision Tree — Which Tool to Use

Use this decision tree every time you have a patch to apply. Start at the top and follow the questions down.

Is this an EBS application tier patch? (one-off, CPU app tier, RUP, NLS, AD/TXK) | YES ────────────────────────> Use ADOP | adop phase=apply patches=<number> | NO | v Is this a Database home patch? (DB CPU, OJVM, PSU, one-off DB fix) | YES ────────────────────────> Use OPatch on $ORACLE_HOME (DB) | Shut down DB first | Run datapatch after for OJVM patches NO | v Is this a WebLogic Server patch? | YES ────────────────────────> Use OPatch on $WLS_ORACLE_HOME | Stop Admin and Managed Servers first | NO | v Is this an Oracle HTTP Server or Web Tier (OHS) patch? | YES ────────────────────────> Use OPatch on $OHS_ORACLE_HOME | Stop OHS first | NO | v Is this a Java / JDK CPU patch for an FMW Java home? | YES ────────────────────────> Use OPatch on each Java home | Run EJCPUC first to identify homes | NO | v Is this a Forms or Reports home patch? | YES ────────────────────────> Use OPatch on $FORMS_ORACLE_HOME Stop Forms and Reports services first

OPatch — Commands by Component

Database tier — DB CPU patch

Apply DB CPU using OPatch — run as oracle OS user
# Set DB Oracle home
export ORACLE_HOME=/u01/oracle/product/19.0.0/dbhome_1
export PATH=$ORACLE_HOME/OPatch:$PATH

# Check OPatch version — confirm it meets minimum requirement
opatch version

# Check for conflicts before applying
cd /stage/<db_patch_number>
opatch prereq CheckConflictAgainstOHWithDetail -ph ./

# Shut down the database and listener
sqlplus / as sysdba
SQL> shutdown immediate;
SQL> exit
lsnrctl stop

# Apply the DB CPU patch
opatch apply

# Start the database
sqlplus / as sysdba
SQL> startup;
SQL> exit
lsnrctl start

# Run datapatch to apply SQL changes (required for OJVM patches)
$ORACLE_HOME/OPatch/datapatch -verbose

# Verify patch applied
opatch lsinventory | grep <patch_number>

WebLogic Server — FMW patch

Apply FMW / WebLogic patch using OPatch — run as applmgr # Stop WebLogic Admin and Managed Servers source /u01/oracle/R122/EBSapps.env run $ADMIN_SCRIPTS_HOME/adstopWLS.sh # Set FMW Oracle home — check your environment for the correct path export ORACLE_HOME=/u01/oracle/R122/fs1/FMW_Home/Oracle_EBS-app1 export PATH=$ORACLE_HOME/OPatch:$PATH # Apply FMW patch cd /stage/<fmw_patch_number> opatch apply # Repeat for each FMW home that requires patching # Check MOS CPU note for list of homes to patch # Restart WebLogic $ADMIN_SCRIPTS_HOME/adstartWLS.sh # Verify opatch lsinventory | grep <patch_number>

Oracle HTTP Server — Web tier patch

Apply OHS patch using OPatch — run as applmgr # Stop Oracle HTTP Server $ADMIN_SCRIPTS_HOME/adopmnctl.sh stop # Set OHS Oracle home export ORACLE_HOME=/u01/oracle/R122/fs1/FMW_Home/webtier export PATH=$ORACLE_HOME/OPatch:$PATH # Apply OHS patch cd /stage/<ohs_patch_number> opatch apply # Restart OHS $ADMIN_SCRIPTS_HOME/adopmnctl.sh start # Verify opatch lsinventory | grep <patch_number>

Java CPU — per Java home

Apply Java CPU patch to each Java home using OPatch # Run EJCPUC first to identify which Java homes need patching cd /stage/ejcpuc ./ejcpuc.sh # For each Java home listed in the EJCPUC report: export JAVA_HOME=/u01/oracle/R122/fs1/FMW_Home/jdk export PATH=$JAVA_HOME/bin:$PATH # Stop services that use this Java home before patching # Then apply the Java CPU patch cd /stage/<java_cpu_patch> $JAVA_HOME/../OPatch/opatch apply # Verify $JAVA_HOME/../OPatch/opatch lsinventory | grep <patch_number> # Repeat for every Java home in the EJCPUC report

ADOP — Commands for EBS Application Tier Patches

Standard ADOP patching cycle — run as applmgr on primary node # Source run environment — always first source /u01/oracle/R122/EBSapps.env run # Dryrun before every real apply adop phase=apply patches=<patch_number> apply_mode=dryrun # Full online patching cycle adop phase=prepare adop phase=apply patches=<patch_number> workers=8 adop phase=finalize adop phase=cutover adop phase=cleanup # Check status at any point adop phase=status # Verify patch registered in AD tables sqlplus apps/<apps_password> <<EOF SELECT bug_number, last_update_date FROM ad_bugs WHERE bug_number = '<patch_number>'; EOF

ADOP commands are always run from the primary application tier node only. In a multi-node environment, ADOP automatically uses SSH to execute the required actions on all secondary nodes. You do not run ADOP on secondary nodes separately.

An Important Consideration — OPatch and the Dual Filesystem

When you apply an OPatch to an FMW home on the run filesystem, the patch filesystem is not updated automatically. This creates a discrepancy between the run and patch filesystems. If you then start an ADOP cycle, the prepare phase will detect the discrepancy and attempt to synchronise the patch filesystem.

The safest approach — and the one Oracle recommends — is to apply OPatch changes to FMW homes on both the run and patch filesystems, or to run adop phase=fs_clone after applying OPatch changes to the run filesystem. This ensures both filesystems are in sync before the next prepare phase.

Apply OPatch to both run and patch filesystem FMW homes # Apply to run filesystem FMW home first export ORACLE_HOME=/u01/oracle/R122/fs1/FMW_Home/Oracle_EBS-app1 opatch apply # Then apply to patch filesystem FMW home export ORACLE_HOME=/u01/oracle/R122/fs2/FMW_Home/Oracle_EBS-app1 opatch apply # Alternative — run fs_clone to sync patch FS from run FS # Use this only when documented by Oracle or when specifically needed adop phase=fs_clone

Verifying That Patches Are Applied

Verifying OPatch patches

Check OPatch inventory for a specific patch # List all applied patches in the Oracle home opatch lsinventory # Search for a specific patch number opatch lsinventory | grep <patch_number> # Detailed listing of a specific patch opatch lsinventory -detail | grep -A5 <patch_number>

Verifying ADOP patches

Check AD tables for EBS application tier patches sqlplus apps/<apps_password> <<EOF -- Check if patch is registered SELECT bug_number, last_update_date FROM ad_bugs WHERE bug_number = '<patch_number>'; -- More reliable check using AD_PATCH function SELECT ad_patch.is_patch_applied('R12', -1, <patch_number>) FROM dual; -- Returns: EXPLICIT = applied -- Returns: NOT APPLIED = not applied or aborted -- Check patch history for a session SELECT adop_session_id, bug_number, status, end_date FROM ad_adop_session_patches WHERE bug_number = '<patch_number>' ORDER BY end_date DESC; EOF

Use AD_PATCH.IS_PATCH_APPLIED over AD_BUGS for verification. The AD_BUGS table can contain entries for patches that were applied during a cycle that was subsequently aborted. The AD_PATCH.IS_PATCH_APPLIED function checks the actual successful application status and is therefore more reliable for confirming a patch is truly in place.

Complete CPU April 2026 Patching Sequence — Tool by Tool

This is the correct sequence for applying a full quarterly CPU in EBS R12.2. Each step uses the correct tool for that component. Do not reorder these steps.

Step Component Tool Services Required Down
1 Run ECPUC and EJCPUC — identify all required patches ECPUC / EJCPUC scripts None
2 Oracle Database home — DB CPU patch OPatch Database and listener
3 Run datapatch after DB OPatch (for OJVM patches) datapatch DB up, no user connections
4 WebLogic Server and FMW Oracle homes OPatch WebLogic Admin and Managed Servers
5 Oracle HTTP Server (OHS) home OPatch OHS / web tier services
6 Java CPU — all Java homes on app tier and DB tier OPatch (per Java home) Services using each Java home
7 EBS application tier — CPU patches from ECPUC list ADOP None — brief cutover only
8 Run ECPUC and EJCPUC again — confirm zero remaining patches ECPUC / EJCPUC scripts None

Common Mistakes — Tool Confusion in Practice

Mistake Consequence Correct Approach
Using adpatch instead of ADOP on R12.2 Patch applies to run filesystem only — does not use dual filesystem or editions — leaves system inconsistent Always use ADOP for EBS application tier patches on R12.2
Applying DB CPU with ADOP ADOP does not patch Oracle database homes — patch will not apply Use OPatch on $ORACLE_HOME (DB) with the DB shut down
Applying FMW patches with ADOP FMW homes are not part of the ADOP patching cycle — patch will not apply Use OPatch on each FMW Oracle home
Applying OPatch to run FS only and not syncing patch FS Next ADOP prepare will detect discrepancy and may fail or run fs_clone unexpectedly Apply OPatch to both filesystems or run fs_clone after
Using AD_BUGS alone to verify patch application AD_BUGS may show patches from aborted cycles as applied when they are not Use AD_PATCH.IS_PATCH_APPLIED for reliable verification
Forgetting datapatch after DB OPatch Database SQL changes from the patch are not applied — partial patch state Always run datapatch after applying DB and OJVM OPatches

Quick Reference — Tool and Command Summary

Component Tool Key Command
Oracle DB home OPatch opatch apply (DB shut down)
Oracle JVM / OJVM OPatch + datapatch opatch apply then datapatch -verbose
WebLogic / FMW homes OPatch opatch apply (WLS services down)
Oracle HTTP Server OPatch opatch apply (OHS down)
Java CPU (per home) OPatch opatch apply (services using that home down)
EBS application tier ADOP adop phase=apply patches=<number>
Verify OPatch patch OPatch opatch lsinventory | grep <patch>
Verify ADOP patch SQL AD_PATCH.IS_PATCH_APPLIED('R12',-1,<patch>)

No comments: