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.
OPatch — Commands by Component
Database tier — DB CPU patch
# 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
# 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
# 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
# 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
# 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 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
# 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
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:
Post a Comment