Pre-Patch Checklist Every EBS R12.2 DBA Must Run Before Any CPU | punitoracledba

Oracle EBS DBA Series · May 2026 · punitoracledba.blogspot.com

Pre-Patch Checklist Every EBS R12.2 DBA Must Run Before Any CPU

Oracle EBS R12.2 | ADOP | Pre-Patch Checks | CPU April 2026 | 9 min read

Most patching failures are not caused by the patch itself. They are caused by starting a patching cycle on a system that was not ready. A stale ADOP session from last month, a disk nearly full, invalid objects that were never resolved, a concurrent manager that silently stopped — any one of these can derail an entire CPU cycle midway through.

The pre-patch checklist exists for one reason: to find these problems before you run adop phase=prepare, not after. Five minutes of checking saves hours of recovery.

This post covers every check you should run before any quarterly CPU patching session on Oracle EBS R12.2. All checks include the exact SQL or shell command to run. Print this page, hand it to your junior DBA, and patch with confidence.

These checks apply before every CPU patching cycle — not just April 2026. Build this into your standard patching runbook and run it every quarter without exception.

Check 1 — Read the MOS Patch Documentation First

Before running any system check, read the MOS documentation for the CPU you are about to apply. This tells you what to expect, what prerequisites are needed, and whether any special steps apply to your environment.

Open MOSFS KA923 — always points to the latest CPU availability document
Navigate to MOSFS KA1539 — April 2026 specific patch list and prerequisites
Download and read the README.txt inside each patch zip before staging
Note any patches listed as prerequisites — these must be applied before the CPU

A prerequisite patch missing mid-apply is one of the most common causes of a failed ADOP session. Verify all prerequisites are in place before you start — not after the first worker fails.

Check 2 — Run ECPUC and EJCPUC

Before downloading any patches manually, run Oracle's checker tools. They tell you exactly what your environment needs — no guesswork.

Run ECPUC — identifies missing EBS application patches

# Source run environment first
source /u01/oracle/R122/EBSapps.env run

# Run ECPUC SQL checker as APPS user
sqlplus apps/<apps_password>
SQL> @/stage/ecpuc/ECPUC.sql

# Review Section 3 of ECPUC.lst — your patch download list
cat ECPUC.lst

Run EJCPUC — identifies missing Java patches on both tiers # Run on application tier node cd /stage/ejcpuc ./ejcpuc.sh # Run separately on database tier node ssh oracle@dbserver cd /stage/ejcpuc ./ejcpuc.sh

Use the output from both tools as your definitive patch download list. Do not proceed until you have downloaded every patch they recommend.

Check 3 — No Active or Incomplete ADOP Session

If a previous patching cycle was not completed or cleaned up properly, a new prepare phase will fail immediately. This check must pass cleanly before anything else proceeds.

Check for stale ADOP sessions adop phase=status -- Also query the database directly sqlplus apps/<apps_password> <<EOF SELECT adop_session_id, status, abandon_flag, start_date, end_date FROM ad_adop_sessions WHERE status NOT IN ('completed', 'abandoned') ORDER BY adop_session_id DESC; EOF

Expected result: No rows returned. If rows are returned, you have an incomplete cycle. Resolve it before proceeding.

If a stale session exists — abort and cleanup # Abort the incomplete session adop phase=abort # Run full cleanup adop phase=cleanup cleanup_mode=full # Confirm status is clean adop phase=status

Check 4 — No Failed Workers from Previous Session

Failed workers from a previous session that was not properly cleaned up can interfere with a new patching cycle. This check complements Check 3.

Check for failed workers sqlplus apps/<apps_password> <<EOF SELECT worker_id, status, start_date, end_date FROM ad_workers WHERE status = 'Failed' ORDER BY worker_id; EOF

Expected result: No rows returned. If failed workers exist from a previous session, confirm that session has been fully cleaned up before starting a new cycle.

Check 5 — Database Editions Are Clean

In R12.2, the database uses Edition-Based Redefinition. During normal operation only one edition — the run edition — should exist. If a patch edition still exists from a previous incomplete cycle, the prepare phase will encounter problems.

Check DB editions sqlplus / as sysdba <<EOF SELECT edition_name, status, created FROM dba_editions ORDER BY created; EOF

Expected result: Only one edition listed with status CURRENT. If two editions exist, the previous patching cycle was not fully completed. Run cleanup before proceeding.

Check 6 — Invalid Object Count

A high number of invalid objects before patching is a warning sign. The patch apply and finalize phases will attempt to compile invalid objects — but if the invalids are caused by a pre-existing issue, they may cause the finalize phase to fail or take much longer than expected.

Check invalid objects sqlplus apps/<apps_password> <<EOF -- Total count of invalids SELECT COUNT(*) FROM dba_objects WHERE status = 'INVALID'; -- Breakdown by owner and type SELECT owner, object_type, COUNT(*) AS cnt FROM dba_objects WHERE status = 'INVALID' GROUP BY owner, object_type ORDER BY owner, object_type; EOF

Expected result: Zero or a very small number of invalids. If you see a high count — especially in the APPS schema — resolve them before patching by running a recompile.

Recompile invalid objects if needed sqlplus apps/<apps_password> <<EOF EXEC UTL_RECOMP.RECOMP_PARALLEL(4); EOF -- Or use adadmin to compile invalid objects adadmin

Check 7 — Disk Space on All Critical Mount Points

Disk space exhaustion mid-patch is one of the most disruptive failures you can encounter. Check all critical mount points before starting. Oracle requires a minimum of 10 GB free for the prepare and apply phases — but 20 GB or more is the safe working minimum in practice.

Check disk space on all critical locations # Check all EBS-related mount points df -h $APPL_TOP $COMMON_TOP $NE_BASE $PATCH_TOP /tmp # Find large files consuming space in patch top du -sh $PATCH_TOP/* # Check database data files location if on same server df -h $ORACLE_BASE

Location	Minimum Free Space	Why It Matters
`$APPL_TOP`	20 GB	Patch filesystem clone written here during prepare
`$PATCH_TOP`	10 GB	Patch zip files and extracted content staged here
`$NE_BASE`	10 GB	ADOP log files and shared non-editioned content
`/tmp`	5 GB	Temporary files during apply and finalize phases
`/usr/tmp`	15 GB	FMW archive creation during prepare fs_clone

Check 8 — Concurrent Managers Are Running

The ADOP cutover phase waits for all running concurrent requests to complete before proceeding. If the concurrent managers are down or have stuck requests, cutover can hang or take far longer than expected. Verify their status before starting.

Check concurrent manager status sqlplus apps/<apps_password> <<EOF -- Check which managers are enabled and running SELECT concurrent_queue_name, running_processes, max_processes, enabled_flag FROM fnd_concurrent_queues_vl WHERE enabled_flag = 'Y' ORDER BY concurrent_queue_name; -- Check for long-running requests that may delay cutover SELECT request_id, requested_by, phase_code, status_code, actual_start_date FROM fnd_concurrent_requests WHERE phase_code = 'R' ORDER BY actual_start_date; EOF

Long-running concurrent requests will delay the cutover phase because ADOP waits for them to complete before shutting down the concurrent manager. If any requests have been running for hours and appear stuck, investigate before starting the patch cycle.

Check 9 — Database Processes Parameter

ADOP uses multiple parallel worker processes. If the database processes parameter is too low, workers will fail to connect and the apply phase will error. Check and increase if needed before starting.

Check DB processes parameter and current usage sqlplus / as sysdba <<EOF -- Current processes parameter setting SHOW PARAMETER processes; -- Current active sessions vs limit SELECT COUNT(*) AS active_sessions FROM v$session WHERE status = 'ACTIVE'; -- Recommended: processes should be at least 500 for ADOP -- If too low, increase and restart the database: -- ALTER SYSTEM SET processes=500 SCOPE=SPFILE; -- SHUTDOWN IMMEDIATE; -- STARTUP; EOF

Check 10 — Prerequisite Patches Are Applied

Every CPU patch README lists patches that must be applied before the CPU can be installed. These are non-negotiable. Verify each one is registered in the AD tables before starting the cycle.

Verify prerequisite patches are registered sqlplus apps/<apps_password> <<EOF -- Replace the numbers with your actual prerequisite patch numbers -- from the CPU README. Every patch listed must return a row. SELECT bug_number, last_update_date FROM ad_bugs WHERE bug_number IN ( '<prereq_patch_1>', '<prereq_patch_2>', '<prereq_patch_3>' ) ORDER BY bug_number; EOF

Expected result: One row for every prerequisite patch number. If any are missing, apply those patches first in a separate ADOP cycle before applying the CPU.

Check 11 — RMAN Backup Is Current

This is not optional. A full RMAN backup must be taken and verified before every CPU patching session. If the patch cycle causes an unrecoverable issue, your only safe path back is a restore from backup.

Verify last RMAN backup and take a fresh one rman target / RMAN> LIST BACKUP SUMMARY; -- Confirm a recent full backup exists -- If no recent backup, take one before patching: RMAN> RUN { BACKUP DATABASE PLUS ARCHIVELOG; DELETE NOPROMPT OBSOLETE; } # Also backup APPL_TOP and NE_BASE to a safe location tar -czf /backup/appl_top_$(date +%Y%m%d).tar.gz $APPL_TOP tar -czf /backup/ne_base_$(date +%Y%m%d).tar.gz $NE_BASE

Save the backup location and timestamp in your change management ticket before starting. If something goes wrong at 2am, you need to know exactly where the backup is — not spend 20 minutes searching for it.

Check 12 — Patch Files Are Staged Correctly

Patches must be unzipped to the $PATCH_TOP directory before the apply phase. Each patch directory must be present on all application tier nodes and accessible by the applmgr user with the same path.

Verify patches are staged and readable # Confirm PATCH_TOP is set echo $PATCH_TOP # List staged patches ls -la $PATCH_TOP/ # Verify patch directory structure for each patch ls -la $PATCH_TOP/<patch_number>/ # Confirm applmgr owns the files stat $PATCH_TOP/<patch_number> # On multi-node: verify same path is accessible on secondary nodes ssh applmgr@secondary_node "ls -la $PATCH_TOP/<patch_number>/"

Master Pre-Patch Checklist — Print and Use

Use this table as your sign-off sheet before every CPU patching session. Every item must be confirmed before running adop phase=prepare.

#	Check	How to Verify	Done
1	Read MOS notes KA923 and KA1539 — patch list and prerequisites confirmed	Manual — MOS browser	[ ]
2	ECPUC run — all required patches identified and downloaded	`ECPUC.sql` — review ECPUC.lst Section 3	[ ]
3	EJCPUC run on app tier and DB tier — Java patches identified	`./ejcpuc.sh` on both nodes	[ ]
4	No active or incomplete ADOP session	`adop phase=status` and `AD_ADOP_SESSIONS`	[ ]
5	No failed workers from previous session	Query `AD_WORKERS WHERE STATUS = 'Failed'`	[ ]
6	Only one DB edition exists — run edition only	Query `DBA_EDITIONS`	[ ]
7	Invalid object count is low — recompile if high	Query `DBA_OBJECTS WHERE STATUS = 'INVALID'`	[ ]
8	Disk space confirmed — 20 GB+ free on APPL_TOP, PATCH_TOP, NE_BASE, /tmp	`df -h` on all mount points	[ ]
9	Concurrent managers are running — no stuck requests	Query `FND_CONCURRENT_QUEUES_VL` and `FND_CONCURRENT_REQUESTS`	[ ]
10	DB processes parameter is sufficient — minimum 500 recommended	`SHOW PARAMETER processes`	[ ]
11	All prerequisite patches are registered in AD_BUGS	Query `AD_BUGS` for each prereq patch number	[ ]
12	RMAN full backup taken and verified today	`LIST BACKUP SUMMARY` in RMAN	[ ]
13	All patches staged in $PATCH_TOP — readable by applmgr on all nodes	`ls -la $PATCH_TOP/<patch_number>`	[ ]
14	Maintenance window communicated to users and managers	Email / change ticket confirmed	[ ]
15	Dryrun completed without errors	`adop phase=apply patches=... apply_mode=dryrun`	[ ]

What Happens If You Skip These Checks

Skipped Check	Likely Consequence
Stale ADOP session not cleared	Prepare phase fails immediately with session conflict error
Disk space not verified	Apply or finalize aborts midway — partial patch leaves system inconsistent
Prerequisite patch missing	Worker fails mid-apply on a missing object or file — restart required
RMAN backup not taken	If patch causes unrecoverable issue — no safe rollback path exists
DB processes too low	Workers fail to connect — apply session fails with connection errors
Dryrun not run	Mode or compatibility issues surface mid-apply — no early warning given

Database Consultant (Passionate about Database & Cloud Technologies)

Tuesday, May 19, 2026