Oracle Applications DBA Patching (ADOP) is the standard patching framework for Oracle E-Business Suite (EBS) Release 12.2 and above. While ADOP was designed primarily around online patching — where patches are applied to a shadow file system without taking the application down — there are legitimate scenarios where downtime mode is the right choice.
Downtime mode simplifies the patching cycle dramatically. It eliminates the edition-based redefinition (EBR) complexity, removes the need for cutover/cleanup phases, and is mandatory for certain patch types. This guide walks you through every step, with real commands and DBA-grade precision.
Imp Note:
Downtime mode requires all users to be logged out of EBS. The application will be unavailable for the entire patching duration. Schedule a proper maintenance window and communicate it to stakeholders before proceeding.
When to Use Downtime Mode:
Not every patching scenario warrants downtime mode, but several situations make it the right — or only — choice:
1. NLS / Translation Patches:
--> Language patches that modify seed data in ways incompatible with EBR online patching.
2. Explicitly Required by Patch
--> Some Oracle-supplied patches explicitly require downtime mode in their readme documentation.
3. Simplified Maintenance Window
--> Smaller environments or DR refreshes where online patching complexity isn't justified.
4. Recovery from Failed Online Patch
--> When an online patching cycle has failed and the environment needs to be reset cleanly.
Section I:
Pre-Patching Checklist:
Before issuing a single ADOP command, verify all of the following. Skipping pre-checks is the primary cause of failed patching cycles.
- Confirmed maintenance window with all application owners and stakeholders
- Full RMAN backup of database completed and verified
- Full file system backup (run/patch) of EBS application tier
- All active users logged off; no pending concurrent requests in Running state
- All application services stopped cleanly via adstpall.sh
- Patch downloaded, unzipped, and MD5 checksum verified against My Oracle Support
- AD-TXK and Application DBA patches at recommended levels
- Sufficient disk space on both run and patch file systems (≥ 20GB headroom)
- Database listener and database itself are running
- Environment variables sourced correctly for apps user
Section II:
Step-by-Step: Applying the Patch:
Step 1 — Source the Environment
Always begin by sourcing the EBS environment file. This sets
all necessary Oracle and EBS variables for the session.
Shell — Source EBS Environment (Run FS)
# As the applmgr OS user on the application tier
su - applmgr
# Source the run file system environment
. /u01/oracle/EBSapps/appl/APPSSID_hostname.env
# Verify key variables are set
echo $APPL_TOP
echo $TWO_TASK
echo $APPS_BASE
Step 2 — Stop All Application Services
Downtime mode requires a completely idle application. Stop
all services using the standard script, then verify no processes remain.
Shell — Stop Application Tier Services
# Stop all EBS application services
$ADMIN_SCRIPTS_HOME/adstpall.sh apps/apps_password
# Confirm no Java, OC4J, or Forms processes are running
ps -ef | grep -i java | grep -v grep
ps -ef | grep -i forms | grep -v grep
ps -ef | grep -i oacore | grep -v grep
Step 3 — Navigate to Patch Directory
Shell — Change to Patch Location
# Change to the directory where the patch was unzipped
cd /u01/patches/PATCHNUMBER
# List to confirm patch contents
ls -la
# You should see: u.drv, README.txt, files/
Step 4 — Initiate ADOP in Downtime Mode
This is the core command. The downtime=yes flag
collapses the entire online patching cycle (prepare → apply → finalize →
cutover → cleanup) into a single, synchronous operation.
Shell — ADOP Downtime Mode Command
adop phase=apply \
patches=PATCHNUMBER
\
apply_mode=downtime
\
patching_mode=downtime
\
downtime=yes \
logfile=/u01/patches/logs/adop_PATCHNUMBER_$(date +%Y%m%d_%H%M).log
adop phase=apply apply_mode=downtime
[oracle@lufRAMfebsdl411 <PATCH> ]$ adop phase=apply apply_mode=downtime patches=38086076,37713099,38391147
Enter the APPS password:
Enter the EBS_SYSTEM password:
Enter the WLSADMIN password:
Validating credentials.
Initializing.
Run Edition context : /u01/install/APPS/fs1/inst/apps/GRAMFI_lufRAMfebsdl411/appl/admin/GRAMFI_lufRAMfebsdl411.xml
Patch edition context: /u01/install/APPS/fs2/inst/apps/GRAMFI_lufRAMfebsdl411/appl/admin/GRAMFI_lufRAMfebsdl411.xml
Patch file system free space: 49356.30 GB
Validating system setup.
Validating credentials.
Initializing.
Run Edition context : /u01/install/APPS/fs1/inst/apps/GRAMFI_lufRAMfebsdl411/appl/admin/GRAMFI_lufRAMfebsdl411.xml
Patch edition context: /u01/install/APPS/fs2/inst/apps/GRAMFI_lufRAMfebsdl411/appl/admin/GRAMFI_lufRAMfebsdl411.xml
Patch file system free space: 49356.30 GB
Validating system setup.
Node registry is valid.
[WARNING] ETCC: The following required database fixes have not been applied to node lufRAMfexanpq
38291812 - DATABASE RELEASE UPDATE 19.29.0.0.251021
Refer to My Oracle Support Knowledge Document 1594274.1 for instructions.
[WARNING] ETCC: The following required database fixes have not been applied to node lufRAMfexanpq
38291812 - DATABASE RELEASE UPDATE 19.29.0.0.251021
Refer to My Oracle Support Knowledge Document 1594274.1 for instructions.
Checking for existing adop sessions.
Application tier services are down.
No pending session exists.
Starting new adop session.
# Provide credentials when prompted:
# APPS
username/password
# SYSTEM
username/password
# WLSADMIN
username/password (if WebLogic admin)
###############################################################################
During execution, ADOP will run all patch drivers — copy, database,
and generate — sequentially. For larger patches, this can take
anywhere from 15 minutes to several hours depending on patch complexity and
system performance.
Step 5 — Monitor Patch Progress
In a separate terminal session (keep the ADOP session
running), monitor the log for errors or stalls.
Shell — Tail the ADOP Log
# Follow the log file in real-time
tail -f /u01/patches/logs/adop_PATCHNUMBER_TIMESTAMP.log
# Also watch the AD Worker logs
ls $APPL_TOP/admin/SID/log/adwork*.log
tail -f $APPL_TOP/admin/SID/log/adwork0N.log
Step 6 — Validate Patch Application
SQL — Verify Patch in AD_APPLIED_PATCHES
-- Connect to the database as APPS
sqlplus apps/apps_password
SELECT patch_name,
patch_type,
maint_pack_level,
creation_date
FROM
ad_applied_patches
WHERE patch_name = 'PATCHNUMBER'
ORDER BY
creation_date DESC;
-- Check for any failed workers
SELECT worker_id, status, start_date, end_date
FROM ad_workers
WHERE status != 'Completed';
Step 7 — Restart Application Services
Once ADOP completes successfully and validation passes,
restart all application services.
Shell — Start Application Services
# Start all EBS application tier services
$ADMIN_SCRIPTS_HOME/adstrtal.sh apps/apps_password
# Verify all services are up
$ADMIN_SCRIPTS_HOME/adstatus.sh
# Check WebLogic Admin Server
ps -ef | grep AdminServer | grep -v grep
Downtime vs. Online Mode: Key Differences
|
Aspect |
Downtime
Mode |
Online
Mode |
|
Availability |
Application
fully offline |
Application
remains live |
|
Patching
Phases |
Single
collapsed phase |
prepare
→ apply → finalize → cutover → cleanup |
|
EBR
Required |
No |
Yes
(Edition-Based Redefinition) |
|
Rollback
Ability |
Restore
from backup |
Abort /
cutover to old edition |
|
Complexity |
Low |
High |
|
Best
For |
NLS
patches, mandatory downtime patches, small environments |
Production
systems with high availability SLAs |
Troubleshooting Common Issues
ADOP Fails with "Workers Not Completed"
Check individual worker logs under $APPL_TOP/admin/<SID>/log/.
Failed workers often indicate an underlying SQL error, object compilation
failure, or disk space issue. Fix the root cause, then restart the failed
worker from AD Controller:
Shell — Restart Failed AD Workers
# Launch AD Controller
adctrl
# From the AD Controller menu:
# Option 2: Tell workers to quit
# Fix root cause in log
# Option 4: Tell manager that worker failed to respond
# Re-run adop with restart=yes
adop phase=apply \
patches=PATCHNUMBER
\
downtime=yes \
restart=yes
Patch Already Applied Error
If ADOP reports the patch is already applied but you believe
it needs to be re-applied (e.g., after a refresh), use the force=yes flag.
Exercise caution — this bypasses the duplicate check.
Shell — Force Re-apply
adop phase=apply \
patches=PATCHNUMBER
\
downtime=yes \
force=yes
Insufficient Disk Space
ADOP requires space on both run and patch file systems.
Check available space with df -h and ensure at least 15–20 GB
headroom before starting. Clean up old patch zips and log files from prior
cycles if necessary.
Post-Patching Best Practices
A successful ADOP run is necessary but not sufficient.
Complete these steps before declaring the patching window closed:
- Smoke
test critical EBS functions (login, key forms, concurrent manager)
- Run
Autoconfig (adautocfg.sh) on both DB and app tiers if patch modifies
config files
- Review
patch README for any post-patch manual steps
- Generate
invalid objects: @$ORACLE_HOME/rdbms/admin/utlrp.sql
- Bounce
Concurrent Managers and verify they start cleanly
- Document
the patch number, date, and DBA who applied it in your change log
- Take a
post-patch RMAN backup (mark it clearly as post-patch baseline)
Applying an ADOP patch in downtime mode is the most straightforward patching path in Oracle EBS R12.2. The key is meticulous preparation: backups, pre-checks, a clean shutdown, and proper log monitoring during the run. The commands themselves are few — the discipline surrounding them is everything.
Used appropriately, downtime mode is not a second-class citizen to online patching. It is a reliable, predictable, and fully supported method that eliminates entire categories of online patching risk. For the right scenario, it is the professional's choice.
No comments:
Post a Comment