Database Consultant (Passionate about Database & Cloud Technologies)

Database Architect,Core DBA ,APPSDBA,Mysql DBA,MongoDB,PostgreSQL,MariaDB,Installations,Upgrades on all Flavors of UNIX (LINUX,SOLARIS,HP(AIX)). Oracle E-Business Suite R12 (Upgrades,Patching,Cloning) AWS upgrades and implementation expert. OCI (Oracle Cloud Infrastructure) Architect, Exadata (Oracle Database Exadata Cloud at Customer(Exacc)),Superclusters ,Autonomous Databases, AWS RDS Customs , Sql Tuning Expert. ***Never Stop sharing,Learning and Growing***

Tuesday, May 19, 2026

How to build a quarterly Oracle EBS CPU patching calendar for your DBA team

How to Build a Quarterly Oracle EBS CPU Patching Calendar for Your DBA Team | punitoracledba

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

How to Build a Quarterly Oracle EBS CPU Patching Calendar for Your DBA Team

Oracle EBS R12.2 | Team Management | Patching Calendar | Documentation Templates | 10 min read

Reactive patching is the most expensive kind. When a CPU drops and your team scrambles to read the advisory, identify patches, raise change tickets, book a maintenance window, and coordinate with the business — all in the same week — something gets missed. That missed item is usually what causes the problem three months later.

A quarterly patching calendar eliminates that scramble. It converts CPU patching from an event that surprises your team every three months into a predictable, well-rehearsed process that runs the same way every quarter. The DBA lead knows what to do on day one. The junior DBA knows their tasks. Management knows the maintenance window dates before the CPU drops. Change management is already in motion.

This post gives you a complete framework to build that calendar — the four CPU dates for the year ahead, a week-by-week activity plan, task assignment templates, change ticket templates, and a post-patch report template ready to use with your team today.

Who this post is for: Oracle EBS DBA leads and senior DBAs managing a team of one or more people who are responsible for quarterly CPU patching across DEV, UAT, and PROD environments.

The Four CPU Release Dates — Calendar These Now

Oracle releases Critical Patch Updates on the third Tuesday of January, April, July, and October every year. A pre-release announcement is published on the Thursday preceding each release. This is predictable — you can calendar every date a year in advance.

Quarter	Release Date	Pre-Release Announcement	Your Target Apply Date (PROD)
Q1 — January 2026	20 January 2026	15 January 2026	By 20 February 2026
Q2 — April 2026	21 April 2026	16 April 2026	By 21 May 2026
Q3 — July 2026	21 July 2026	16 July 2026	By 21 August 2026
Q4 — October 2026	20 October 2026	15 October 2026	By 20 November 2026
Q1 — January 2027	19 January 2027	14 January 2027	By 19 February 2027

The 30-day target apply date for PROD is the recommended maximum after CVE-2025-61882. For internet-facing EBS environments, treat this as a hard deadline — not a guideline. For internal-only environments, 45 days is acceptable with documented justification.

The Four-Week Patching Plan — Week by Week

The same four-week plan runs every quarter. The dates shift with each CPU release, but the activities are identical. Once your team has run this plan twice it becomes automatic.

Week 1 — CPU Release Week (Days 1 to 7)

The CPU drops. This week is about reading, not patching.

Day	Activity	Owner
Day 1 (Release day)	Read MOS note KA923 — confirm the EBS availability document link. Open and read the CPU advisory on oracle.com/security-alerts.	DBA Lead
Day 1–2	Download the latest ECPUC (Patch 35583866) and EJCPUC (Patch 37171025) from MOS. Run both against DEV to identify required patches.	Senior DBA
Day 2–3	Download all patches identified by ECPUC. Read the README for each patch — note any prerequisite patches or downtime mode requirements.	Senior DBA
Day 3–4	Raise the change request for DEV patching. Book the DEV maintenance window (internal — no user communication required for DEV).	DBA Lead
Day 5–7	Send the patching schedule communication to UAT and PROD business owners — maintenance window dates and expected brief outage at cutover.	DBA Lead

Week 2 — DEV Patching (Days 8 to 14)

Apply the full CPU cycle to the DEV environment. This is your test run and your learning opportunity.

Day	Activity	Owner
Day 8	Run pre-patch checklist on DEV. Confirm no stale ADOP session, disk space, invalid objects, DB editions clean, RMAN backup taken.	Junior DBA
Day 8	Apply DB CPU and FMW/WebLogic patches using OPatch on DEV. Run datapatch. Apply Java CPU patches using EJCPUC output.	Senior DBA
Day 9	Run ADOP dryrun on DEV with all application tier patches.	Senior DBA
Day 9–10	Run full ADOP cycle on DEV — prepare, apply, finalize, cutover, cleanup. Document any issues encountered and how they were resolved.	Senior DBA
Day 11–12	Run ECPUC and EJCPUC on DEV post-patch — confirm zero remaining patches. Run functional smoke tests on DEV.	Junior DBA
Day 13–14	Document DEV patching outcome. Note any issues, deviations, or patches that required special handling. Update UAT runbook with lessons from DEV.	DBA Lead

Week 3 — UAT Patching (Days 15 to 21)

Apply the CPU to UAT. The runbook is now refined from DEV. This should be a smoother run than DEV with no surprises.

Day	Activity	Owner
Day 15	Run pre-patch checklist on UAT. Take RMAN backup. Raise change ticket for UAT window.	Junior DBA
Day 15–16	Apply DB CPU, FMW OPatch, and Java CPU patches to UAT using OPatch.	Senior DBA
Day 16–17	Run full ADOP cycle on UAT. Brief user outage at cutover — notify UAT team in advance.	Senior DBA
Day 18	Run ECPUC and EJCPUC post-patch on UAT. Confirm zero remaining patches.	Junior DBA
Day 18–20	UAT functional testing by the business team. DBA team available for support. Confirm sign-off before PROD change ticket is approved.	Business Team + DBA Lead
Day 21	Obtain formal UAT sign-off. Raise PROD change request. Confirm PROD maintenance window with business stakeholders.	DBA Lead

Week 4 — PROD Patching (Days 22 to 30)

Apply the CPU to PROD. The runbook has been tested twice. There should be no surprises.

Day	Activity	Owner
Day 22	PROD change request approved. Communicate final maintenance window time to all users and management.	DBA Lead
Day 24–25	Run PROD pre-patch checklist. Take RMAN full backup. Confirm all patches staged. Confirm change ticket is approved.	Junior DBA + Senior DBA
Day 26	Apply DB CPU and FMW OPatch to PROD. Apply Java CPU patches. Services outage during this phase.	Senior DBA
Day 27	Run full ADOP cycle on PROD. Brief user outage at cutover only.	Senior DBA
Day 28	Run ECPUC and EJCPUC post-patch on PROD. Confirm zero remaining patches. Save both reports.	Junior DBA
Day 28–29	Run PROD smoke tests. Confirm all services healthy. Close change ticket.	Senior DBA + DBA Lead
Day 30	Publish post-patch report to management. File ECPUC reports. Update patch register. Close the quarter.	DBA Lead

Task Assignment by Role

For a typical EBS DBA team of three — a lead, a senior DBA, and a junior DBA — this is the standard task split every quarter. Adjust based on your team size.

Role	Responsibilities Each Quarter
DBA Lead	Reads the CPU advisory on release day Assesses risk and CVSS severity Raises all change requests Communicates maintenance windows to business Obtains UAT sign-off Publishes post-patch report to management Maintains the patch register Escalates to Oracle Support if issues arise
Senior DBA	Downloads and reviews all patches and READMEs Runs ECPUC and EJCPUC on all environments Applies DB CPU and FMW OPatch patches Runs the full ADOP cycle on all environments Troubleshoots any apply failures Writes and maintains the patching runbook Mentors the junior DBA during execution
Junior DBA	Runs pre-patch checklists on all environments Monitors ADOP apply progress and worker logs Runs post-patch ECPUC and EJCPUC checks Runs functional smoke tests Saves and files ECPUC reports Updates runbook with actual timings from each environment

If you are a one-person DBA team, all of these tasks fall to you. In that case the four-week plan becomes even more important — it prevents everything from stacking in the same week and gives you breathing room between environments.

Change Ticket Template

Use this template for every CPU change request. Fill in the bracketed fields for each environment and quarter. Standardising the format means your change advisory board knows exactly what to expect every quarter — which speeds up approvals.

Change Request Template — Oracle EBS CPU Patching

Change Title: Oracle EBS R12.2 CPU [Quarter Year] — Application of Critical Patch Update — [Environment: DEV / UAT / PROD]

Change Type: Standard — Scheduled Security Maintenance

Priority: High — Security patch with CVSS [highest score from advisory]

Environment: [Environment name and server details]

Maintenance Window Start: [Date and time]

Maintenance Window End: [Date and time — allow 12 hours for PROD]

User-Facing Downtime: Brief outage of 10 to 30 minutes at ADOP cutover phase. DB and FMW OPatch phases require services down for approximately 60 to 90 minutes beforehand.

Description of Change:
Application of Oracle Critical Patch Update [Quarter Year] to Oracle E-Business Suite R12.2 and its technology stack components. This includes:
1. Oracle Database home CPU patch — applied via OPatch
2. Oracle WebLogic / FMW home patches — applied via OPatch
3. Java CPU patches across all Java homes — applied via OPatch
4. EBS application tier CPU patches — applied via ADOP online patching cycle

Patches Being Applied:
DB CPU: [Patch number]
FMW CPU: [Patch number]
EBS App Tier: [Patch numbers from ECPUC]
Java CPU: [Patch numbers from EJCPUC]

Risk Assessment: Low — patches applied to DEV and UAT without issues. RMAN backup taken prior to patching. Rollback procedure documented.

Rollback Plan: Restore from RMAN backup taken before patching. ADOP abort and cleanup available if failure occurs before cutover. Estimated rollback time: [X hours].

Testing Completed:
DEV: Applied on [date] — no issues
UAT: Applied on [date] — UAT sign-off received [date]

Post-Change Verification:
ECPUC re-run — zero remaining patches confirmed
EJCPUC re-run — zero remaining Java patches confirmed
Functional smoke tests completed
All services healthy

Patching Runbook Template

The runbook captures the exact commands and environment-specific details for each CPU cycle. Fill in the environment details once — the commands stay the same every quarter, only the patch numbers change.

EBS CPU Patching Runbook — [Quarter Year] — [Environment]

Environment Details
EBS Release: [e.g. R12.2.13]
DB Version: [e.g. 19.18.0.0]
App Tier Primary Node: [hostname]
DB Tier Node: [hostname]
ORACLE_HOME (DB): [full path]
EBS Base: [full path]
PATCH_TOP: [full path]

Patches to Apply This Quarter
DB CPU Patch: [patch number]
FMW Patch: [patch number]
Java CPU Patch: [patch number — per Java home]
EBS App Tier Patches: [from ECPUC.lst Section 3]
Prerequisite Patches: [from README]

Pre-Patch Sign-off
[ ] Pre-patch checklist completed
[ ] RMAN backup taken and verified
[ ] ECPUC run — required patches identified
[ ] EJCPUC run — Java patches identified
[ ] All patches staged in PATCH_TOP
[ ] Change ticket approved
[ ] Maintenance window communicated

Step 1 — DB CPU (OPatch)
Start time: ____ End time: ____ Status: ____
Patch applied: [patch number]
Datapatch run: Yes / No
Issues: [none / describe]

Step 2 — FMW / WebLogic OPatch
Start time: ____ End time: ____ Status: ____
Homes patched: [list each home patched]
Issues: [none / describe]

Step 3 — Java CPU (OPatch per home)
Start time: ____ End time: ____ Status: ____
Java homes patched: [list each home]
Issues: [none / describe]

Step 4 — ADOP Cycle
Prepare start: ____ End: ____
Apply start: ____ End: ____ Workers used: ____
Finalize start: ____ End: ____
Cutover start: ____ End: ____ (user outage window)
Cleanup start: ____ End: ____
Worker failures: [none / describe and resolution]

Post-Patch Verification
ECPUC re-run: [date] — Zero remaining patches: Yes / No
EJCPUC re-run: [date] — Zero remaining patches: Yes / No
Smoke tests: [pass / fail — describe any failures]
Services healthy: Yes / No
Total downtime (user-facing): ____ minutes

Post-Patch Management Report Template

Send this report to your manager and security team within 48 hours of completing PROD patching. Keep it short — one page. Managers need to know it is done, what was applied, and whether there were any issues. They do not need the ADOP command history.

Oracle EBS CPU Patching — Quarterly Status Report

Report Date: [date]
CPU Quarter: [e.g. April 2026]
Prepared by: [DBA Lead name]

Summary
The Oracle E-Business Suite Critical Patch Update for [Quarter Year] has been successfully applied to all environments. All environments are now at the current CPU patch level.

Patch Scope
Highest CVSS score addressed: [e.g. 9.8]
New EBS security patches applied: [e.g. 18]
Remotely exploitable vulnerabilities addressed: [e.g. 8]

Environment Status

Environment	Patch Applied On	Downtime (mins)	Status
DEV	[date]	[X]	Complete
UAT	[date]	[X]	Complete
PROD	[date]	[X]	Complete

Verification
ECPUC report run post-patch: Zero remaining recommended patches confirmed on all environments.
EJCPUC report run post-patch: Zero remaining Java patches confirmed on all environments.
Reports filed: [storage location]

Issues Encountered
[None — or describe any issues and their resolution]

Next CPU Date
[Next quarter release date] — planning to start on release day.

Patch Register — Track Your Patch Level Over Time

Maintain a simple patch register that records the CPU level of every environment after each quarter. This is your single source of truth for audit purposes, management reporting, and compliance reviews.

CPU Quarter	Release Date	DEV Applied	UAT Applied	PROD Applied	ECPUC Clean
January 2026	20 Jan 2026	DD-Mon-YYYY	DD-Mon-YYYY	DD-Mon-YYYY	Yes / No
April 2026	21 Apr 2026	DD-Mon-YYYY	DD-Mon-YYYY	DD-Mon-YYYY	Yes / No
July 2026	21 Jul 2026	DD-Mon-YYYY	DD-Mon-YYYY	DD-Mon-YYYY	Yes / No
October 2026	20 Oct 2026	DD-Mon-YYYY	DD-Mon-YYYY	DD-Mon-YYYY	Yes / No

Store ECPUC.lst and EJCPUC report files for every environment every quarter. Name them consistently: ECPUC_PROD_APR2026.lst and EJCPUC_PROD_APR2026.txt. These are your audit evidence. If you are ever asked by auditors or management to prove your patch level at a point in time, these files are your answer.

Handling Out-of-Band Emergency Patches

The quarterly calendar handles regular CPU cycles. Emergency patches — like the October 2025 CVE-2025-61882 patch — do not wait for the quarterly cycle. You need a separate process for these.

Patch Severity	Target Apply Time (PROD)	Process
CVSS 9.0 or above — internet-facing EBS	Within 7 days of release	Emergency change request. Skip DEV dryrun if needed. Apply directly to PROD with RMAN backup and rollback plan ready.
CVSS 9.0 or above — internal EBS only	Within 14 days of release	Expedited change request. Apply to DEV first, then PROD within the 14-day window.
CVSS 7.0 to 8.9	Within 30 days of release	Standard change request. Apply to DEV and UAT first. PROD within 30 days.
CVSS below 7.0	Next quarterly cycle	Add to the next CPU cycle patch list. Do not delay the quarterly cycle for it.

Common Mistakes in Quarterly Patching Management

Mistake	Consequence	Prevention
Starting to read the CPU advisory on the day of patching	Prerequisites missed, wrong patches downloaded, maintenance window insufficient	Read the advisory on release day — always Week 1, Day 1
Skipping DEV and patching UAT first	Issues discovered during UAT with no fallback — forces abort under pressure	Always DEV first — that is the point of DEV
Not obtaining UAT sign-off before PROD change ticket	PROD issues blamed on patching — no evidence that functional testing was done	UAT sign-off is a gate — PROD change ticket cannot be raised without it
Filing no post-patch report	No audit trail — next year's audit asks for proof of patch dates and you have none	File the management report and ECPUC/EJCPUC reports every quarter without exception
Treating the out-of-band emergency patch as optional	Critical vulnerability open for months — CVE-2025-61882 showed the consequence	Emergency patches above CVSS 9.0 bypass the quarterly calendar — apply within 7 to 14 days
Not calendaring the next CPU date immediately after closing the current one	Next quarter arrives without preparation — reactive patching begins again	On the day you file the post-patch report, add the next CPU date to the team calendar

Summary — Starting Your Calendar This Week

You do not need to build the perfect calendar before starting. Build a simple version now and refine it after your first quarter.

Add all four 2026 CPU release dates and your 30-day PROD targets to your team calendar today
Copy the change ticket template and runbook template into your team's documentation system
Assign the three roles — Lead, Senior DBA, Junior DBA — for the next CPU cycle
Set a recurring reminder one week before each CPU release date to start Week 1 activities
After your first quarter, review the actual timings vs the plan and adjust the runbook
After two quarters, the process runs itself

The goal is not a perfect process. The goal is a repeatable one. A simple plan that runs every quarter is worth more than a complex one that only runs when someone remembers to start it.

CVE-2025-61882 — what the EBS zero-day exploit means for your patching strategy

CVE-2025-61882 — What the Oracle EBS Zero-Day Means for Your Patching Strategy | punitoracledba

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

CVE-2025-61882 — What the Oracle EBS Zero-Day Means for Your Patching Strategy

Every EBS DBA knows that CPU patching is important. Most treat it as routine maintenance — something to schedule, plan, execute, and document. CVE-2025-61882 changed that conversation permanently.

In August 2025, the Cl0p ransomware group began silently exploiting a zero-day vulnerability in Oracle E-Business Suite. For weeks, they moved through unpatched EBS environments, exfiltrating payroll files, vendor contracts, and financial transaction data — without triggering a single alert. By the time Oracle published an emergency patch on October 4, 2025, many organizations had already lost significant data and received extortion demands.

This post covers what CVE-2025-61882 was, how the attack worked, what the April 2026 CPU addresses in its aftermath, and — most importantly — what it means for how you manage EBS patching going forward.

What Is CVE-2025-61882

CVE-2025-61882 is a critical unauthenticated remote code execution (RCE) vulnerability in Oracle E-Business Suite. It carries a CVSS base score of 9.8 out of 10 — the highest severity rating in practice.

Detail	Value
CVE ID	CVE-2025-61882
CVSS Base Score	9.8 Critical
Attack Vector	Network — remotely exploitable via HTTP
Authentication Required	None — pre-authentication, no credentials needed
Component Affected	Oracle Concurrent Processing — BI Publisher Integration, UiServlet
Versions Affected	Oracle EBS 12.2.3 through 12.2.14
Impact	Full remote code execution — complete system compromise
Patch Released	October 4, 2025 — out-of-band emergency patch
Added to CISA KEV	October 6, 2025 — confirmed ransomware use

The vulnerability is not a single flaw. According to WatchTowr, the exploit chain involves five separate bugs to achieve pre-authentication remote code execution, including some that were patched by Oracle in its July 2025 Critical Patch Update. This means organizations that were behind on their quarterly CPU patching were exposed to components of this exploit chain months before the zero-day was even disclosed.

How the Attack Worked — The Five-Stage Exploit Chain

CVE-2025-61882 is a chained exploit — five separate vulnerabilities combined in sequence to achieve full remote code execution. Understanding the chain helps you understand why patching every quarterly CPU matters, not just the most recent one.

Stage 1 — Server-Side Request Forgery via UiServlet

The attack begins by exploiting a Server-Side Request Forgery (SSRF) vulnerability in the UiServlet component. By sending a specially crafted XML document through the getUiType parameter, an attacker can coerce the backend server into making arbitrary HTTP requests. No authentication is required for this initial step.

Stage 2 — Internal service access via port 7201

The exploit specifically targets an internal HTTP service running on port 7201, which is the core Oracle EBS application server. This technique allows reaching internal services that would otherwise be protected from direct internet access, significantly expanding the attack surface.

Stage 3 — Authentication bypass via path traversal

With access to the internal service, the attacker bypasses authentication filters using a classic path traversal technique with the /help/ prefix. The /help/ endpoint is publicly accessible and does not require authentication. By combining it with path traversal sequences, the filter logic fails to enforce authentication requirements.

Stage 4 — Malicious template upload via BI Publisher

To achieve code execution, the adversary targeted Oracle's XML Publisher Template Manager by issuing GET and POST requests to /OA_HTML/RF.jsp and /OA_HTML/OA.jsp to upload and execute a malicious XSLT template.

Stage 5 — Remote code execution and persistence

Web shells are invoked via filter chains in EBS endpoints, allowing attackers to execute commands in memory without leaving obvious traces on disk. Outbound HTTPS and TCP connections from Oracle Java processes to attacker-controlled infrastructure were used to fetch loaders and backdoors.

The sophistication of this chain is significant. It requires deep knowledge of EBS internals — the servlet architecture, BI Publisher integration, and internal port layout. This was not opportunistic scanning by script kiddies. It was targeted research by a well-resourced threat actor over months before exploitation began.

Timeline of the CVE-2025-61882 Campaign

July 10, 2025 Suspicious activity targeting EBS customer environments begins — approximately three months before the vulnerability is publicly disclosed. Cl0p was already inside environments at this stage.

August 9, 2025 The first confirmed exploitation occurs on August 9, 2025. Cl0p begins actively exploiting the zero-day in the wild. Throughout August, they quietly gain access to vulnerable EBS servers and harvest sensitive data without detection.

Late September 2025 After weeks of data theft, affected organizations begin receiving Cl0p extortion emails. The emails are sent to company executives, claiming the actor had breached their Oracle EBS application and exfiltrated documents — providing legitimate file listings from victim environments as proof.

October 2, 2025 Google Threat Intelligence Group and Mandiant publish their analysis of the campaign. CrowdStrike publishes independently. The scale of the exploitation becomes publicly known. Pressure mounts on Oracle to respond.

October 4, 2025 Oracle releases an emergency out-of-band patch for CVE-2025-61882 — outside the usual quarterly CPU schedule. The advisory confirms CVSS 9.8, pre-auth RCE, and includes Indicators of Compromise from observed exploitation.

October 6, 2025 CVE-2025-61882 is added to the US Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities list, confirming its use in a ransomware campaign.

October 7–9, 2025 Exploit code for CVE-2025-61882 surfaces on public forums via a Telegram channel. Security researchers confirm the PoC can reliably compromise unpatched systems, turning the zero-day into a one-day exploit accessible to any threat actor — not just Cl0p.

April 21, 2026 Oracle releases the April 2026 CPU — the first regular quarterly CPU after the CVE-2025-61882 incident. It includes 18 new security patches for EBS with a highest CVSS score of 9.8. Security researchers note elevated attacker interest in EBS remains.

What Data Was Taken and Who Was at Risk

The fallout from the campaign was extensive. Cl0p gained access to sensitive ERP data such as payroll files, vendor contracts, and financial transactions. Oracle EBS is the financial and operational backbone of many large organizations. When it is compromised, the attacker has access to everything that runs through it.

Any organization that had Oracle E-Business Suite exposed to the internet was at risk. Given that mass exploitation attempts had been ongoing for more than a month before public disclosure, organizations faced a real possibility that the vulnerability had already been exploited before they were aware of it.

The affected versions were Oracle EBS 12.2.3 through 12.2.14 — which covers virtually every organization running EBS R12.2.

If your EBS is internet-facing and was not fully patched through the July 2025 CPU before October 2025, you were exposed for the duration of the campaign. If you have not already done so, conduct a threat hunting exercise using the IOCs published by Oracle and Mandiant to determine if your environment was accessed.

What the April 2026 CPU Addresses in This Context

The April 2026 CPU is the first regular quarterly CPU released after CVE-2025-61882. It is not a direct fix for that specific vulnerability — that was the October 2025 emergency patch. However, the April 2026 CPU matters significantly in the post-CVE-2025-61882 landscape for several reasons.

18 new security patches for EBS

The April 2026 CPU includes 18 new security patches for Oracle EBS, with 8 remotely exploitable and the highest CVSS score at 9.8. Given that the CVE-2025-61882 exploit chain incorporated vulnerabilities from previous CPUs that organizations had not applied, every patch in the April 2026 CPU must be treated as a potential component of a future exploit chain — not as an optional update.

Attacker interest in EBS remains elevated

GTIG assesses that Cl0p-affiliated actors almost certainly perceive mass exploitation campaigns as successful, given that they have employed this approach since at least late 2020 and will continue to dedicate resources to acquiring zero-day exploits for similar applications for at least the near term. EBS is now a confirmed high-value target. That does not go away after one patch.

Proof-of-concept code is publicly available

The CVE-2025-61882 proof-of-concept exploit code is publicly available on underground forums. Any organization still running an unpatched EBS instance — whether the October 2025 emergency patch was missed, or earlier CPUs were skipped — is now trivially exploitable. The April 2026 CPU must be applied on top of a fully patched baseline, not a partially patched one.

Indicators of Compromise — What to Look For

If you have not yet checked your environment for signs of compromise from the CVE-2025-61882 campaign, do so before applying the April 2026 CPU. Patching over an already-compromised environment does not remove a backdoor that is already installed.

Suspicious HTTP endpoints to monitor in logs

Suspicious URL patterns — search access logs for these

# Search your EBS web tier and OHS access logs for these patterns
# Any hits on these endpoints warrant immediate investigation

grep -i "UiServlet" /u01/oracle/R122/fs1/FMW_Home/webtier/instances/*/diagnostics/logs/OHS/*/access_log*
grep -i "SyncServlet" /u01/oracle/R122/fs1/FMW_Home/webtier/instances/*/diagnostics/logs/OHS/*/access_log*
grep -i "help/\.\." /u01/oracle/R122/fs1/FMW_Home/webtier/instances/*/diagnostics/logs/OHS/*/access_log*
grep -i "ieshostedsurvey" /u01/oracle/R122/fs1/FMW_Home/webtier/instances/*/diagnostics/logs/OHS/*/access_log*
grep -i "RF\.jsp" /u01/oracle/R122/fs1/FMW_Home/webtier/instances/*/diagnostics/logs/OHS/*/access_log*

Suspicious database activity

Check for unusual BI Publisher templates — run as APPS sqlplus apps/<apps_password> <<EOF -- Check for unusual or recently added XDO templates -- External URLs or unknown XSLT payloads are suspicious SELECT template_code, template_name, default_output_type, last_update_date, last_updated_by FROM xdo_templates_vl WHERE last_update_date > TO_DATE('2025-07-01','YYYY-MM-DD') ORDER BY last_update_date DESC; -- Check for unexpected administrative accounts created recently SELECT user_name, start_date, end_date, last_logon_date, created_by FROM fnd_user WHERE start_date > TO_DATE('2025-07-01','YYYY-MM-DD') ORDER BY start_date DESC; EOF

Other indicators to check

Unexpected Java files on the application server — particularly files with names like Log4jConfigQpgsubFilter.java or other unusual Java class files
Outbound HTTPS or TCP connections from Oracle Java processes to unknown external IP addresses — check firewall logs for the period July to October 2025
Unusual activity in /OA_HTML/ directories — unexpected JSP or class files added outside of patch cycles
Extortion emails received by your executives referencing EBS data — if received, treat the environment as compromised and engage incident response immediately

What CVE-2025-61882 Means for Your Patching Strategy

The CVE-2025-61882 incident forced a reckoning that many EBS teams needed. The comfortable assumption that EBS patching can be deferred, deprioritised, or spread across many months is no longer defensible. Here is what this incident means for how you manage patching going forward.

1. Missing one CPU creates compounding risk

The CVE-2025-61882 exploit chain incorporated vulnerabilities that were already patched in the July 2025 CPU. Organizations that had applied the July 2025 CPU reduced their exposure to components of the exploit chain. Organizations that had not applied it were fully exposed. Each missed CPU is not just one missed quarter — it is a cumulative increase in attack surface that compounds with each passing month.

2. Internet-facing EBS requires an accelerated patching SLA

If your EBS environment is accessible from the internet — whether directly or via a DMZ — the standard quarterly patching timeline is no longer adequate on its own. You need a defined SLA for how quickly you apply security patches after release. For internet-facing EBS, the target should be within 30 days of the CPU release. For critical out-of-band patches like the October 2025 emergency fix, the target should be days, not weeks.

3. Out-of-band patches cannot wait for the next quarterly window

Oracle released the emergency patch on October 4 for CVE-2025-61882. GTIG and Mandiant recommend applying Oracle EBS patches released on October 4, 2025 immediately as the highest priority action. Many organizations that held the emergency patch for their next scheduled maintenance window allowed weeks of additional exposure. Out-of-band patches with CVSS scores above 9.0 must bypass the normal change calendar.

4. Your July 2025 CPU status was your first line of defence

This is the most critical lesson. The exploit chain used bugs that Oracle had already patched in July 2025. Organizations fully patched through July 2025 had significantly reduced exposure compared to those running older patch levels. Being current on quarterly CPUs is not just compliance — it is your primary defence against the next zero-day exploit chain.

5. Threat hunting after a public campaign is not optional

The timeline shows that Cl0p was inside EBS environments for six to eight weeks before public disclosure. If your environment was internet-facing and unpatched, and you have not yet conducted a threat hunting exercise, do it now. Applying the April 2026 CPU does not remove a backdoor already installed. Patching and incident response are separate activities.

Hardening Recommendations Beyond Patching

The April 2026 CPU and the October 2025 emergency patch address the known vulnerabilities. These additional measures reduce the attack surface for vulnerabilities that have not yet been disclosed.

Recommendation	Why It Matters
Restrict internet exposure of EBS	Place EBS behind a WAF, reverse proxy, or VPN. CVE-2025-61882 required network access via HTTP — limiting who can reach EBS at all reduces the attack surface for all future vulnerabilities
Enforce MFA on all EBS login paths	In cases where an organization reacts, Cl0p sometimes falls back to secondary access paths — using local EBS login endpoints that bypass SSO and do not enforce MFA, creating a survival route. Close these paths
Monitor access logs for suspicious URL patterns	The IOCs published by Oracle and Mandiant include specific URL patterns. Set up alerting on these. Early detection limits the dwell time attackers have before discovery
Restrict outbound connections from EBS servers	The CVE-2025-61882 exploit required outbound connections from EBS Java processes to attacker servers. Egress filtering from application servers limits the ability to establish command-and-control channels
Apply AD_PATCH.IS_PATCH_APPLIED checks after every CPU	Confirm that every patch listed in ECPUC is genuinely applied — not just attempted. Verify using the function rather than AD_BUGS alone
Keep OPatch and Java homes current	The exploit chain used Java-level vulnerabilities. EJCPUC identifies missing Java CPU patches. Keep every Java home current every quarter

The New Standard for EBS Patching After CVE-2025-61882

Before October 2025 it was possible to treat EBS CPU patching as a routine operational task with flexible timelines. That position is no longer defensible to management, auditors, or — if a breach occurs — legal teams. The standard that the CVE-2025-61882 incident has established is this:

Quarterly CPUs — applied within 30 to 60 days of release for all environments, within 30 days for internet-facing environments
Out-of-band emergency patches with CVSS 9.0 or above — applied within 7 days for internet-facing environments, within 14 days for internal-only environments
ECPUC and EJCPUC — run before and after every CPU cycle to confirm zero remaining recommended patches
Threat hunting — conducted within 30 days of any public EBS security campaign using published IOCs
Patch status reporting — current CPU level documented and reported to management quarterly

If your organization is struggling to justify the resources for quarterly EBS patching, the CVE-2025-61882 campaign provides the argument. The cost of applying the July 2025 CPU on schedule was a maintenance window. The cost of not applying it was potentially six to eight weeks of undetected attacker access to payroll files, vendor contracts, and financial data.

Summary

CVE-2025-61882 is a CVSS 9.8 pre-authentication RCE vulnerability in Oracle EBS Concurrent Processing — exploited by Cl0p as a zero-day from August 2025, patched by Oracle on October 4, 2025
The exploit chain chains five vulnerabilities — including some already patched in the July 2025 CPU — meaning organizations current on quarterly CPUs had reduced exposure
Cl0p operated silently inside EBS environments for six to eight weeks before public disclosure, exfiltrating ERP data including payroll and financial records
The April 2026 CPU includes 18 new EBS security patches — each one a potential component of a future exploit chain if left unpatched
Internet-facing EBS environments require an accelerated patching SLA — emergency patches with CVSS 9.0 or above cannot wait for the next quarterly window
Patching does not replace threat hunting — if your environment was exposed during the campaign period, investigate using published IOCs before assuming you are clean
The hardening measures — WAF, MFA enforcement, egress filtering, log monitoring — reduce attack surface for vulnerabilities not yet disclosed

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

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

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

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>)`

What is Edition-Based Redefinition and why EBS R12.2 online patching works

What Is Edition-Based Redefinition and Why EBS R12.2 Online Patching Works | punitoracledba

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

What Is Edition-Based Redefinition and Why EBS R12.2 Online Patching Works

Oracle EBS R12.2 | EBR | Online Patching | Database Architecture | 10 min read

Every EBS R12.2 DBA uses ADOP. Very few can explain why it works. When someone asks you in an interview or a team meeting — how does EBS R12.2 allow patching while users are online? — the answer is Edition-Based Redefinition, also known as EBR.

EBR is the Oracle database feature introduced in Oracle Database 11gR2 that makes the entire online patching model possible. Without EBR, R12.2 online patching does not exist. Understanding it makes you a better EBS DBA — you will troubleshoot patching issues faster, understand error messages more clearly, and explain the architecture to your team with confidence.

This post explains EBR in plain language — no marketing language, no jargon without explanation. By the end you will understand what an edition is, what the three edition types in EBS mean, what editioned and non-editioned objects are, and exactly how all of this maps to the ADOP phases you run every quarter.

The Problem EBR Solves

Before R12.2, patching Oracle EBS required a complete application shutdown. The reason was simple: when you apply a patch, you are changing database objects — packages, procedures, views, triggers. If users are connected and actively calling those objects while you are redefining them, the results are unpredictable. Applications crash, data gets corrupted, sessions error out.

The traditional solution was to bring the system down, apply the patch, bring it back up. For large environments this meant 4 to 12 hours of downtime every quarter. Multiply that by four CPU cycles per year and you have a significant availability problem.

Oracle's answer was Edition-Based Redefinition — a way to have two versions of the same database objects exist simultaneously in the same database, visible to different sessions, without conflict.

EBR was introduced in Oracle Database 11g Release 2 (11.2.0.1) in 2009. Oracle EBS R12.2 was the first major Oracle application to adopt EBR as its core patching mechanism when it was released in 2013.

What Is a Database Edition?

The simplest way to think of an edition is as a private namespace for database code objects. An edition is a named container that holds a version of your PL/SQL packages, procedures, functions, views, and synonyms. Different sessions can connect to different editions and each session sees only the objects belonging to its edition.

Think of it like two parallel rooms in the same building. Room A has the current version of your code — users are working in there right now. Room B is a private copy of Room A where you are free to make changes. Users in Room A cannot see what you are doing in Room B and are completely unaffected by it. When you finish your changes, you open the door, users move to Room B, and Room A becomes available for the next round of changes.

That is exactly what EBR does — except the rooms are database editions and the move from one room to the other is the ADOP cutover phase.

Check editions in your EBS database

sqlplus / as sysdba <<EOF
-- List all editions in the database
SELECT edition_name,
       status,
       created
FROM   dba_editions
ORDER  BY created;

-- Check which edition the current session is using
SELECT sys_context('USERENV','SESSION_EDITION_NAME') AS current_edition
FROM   dual;
EOF

The Three Edition Types in EBS R12.2

EBS R12.2 uses three specific edition types throughout the ADOP patching cycle. Understanding what each one is and when it exists removes all confusion about what ADOP is actually doing at each phase.

Edition Type	Who Connects to It	When It Exists
Run Edition	All online users — the default edition for all application sessions	Always — it never goes away. This is what users see at all times.
Patch Edition	ADOP patching tools only — users never connect to it	Only during an active patching cycle — from prepare to cutover or abort
Old Edition	Nobody — no connections allowed	After cutover, the previous run edition becomes the old edition. Removed during cleanup.

The patch edition is always a child of the run edition. It inherits all the objects from the run edition when it is created. Objects that are not changed by the patch remain inherited from the parent — they are not duplicated. Only objects that the patch actually modifies are stored separately in the patch edition.

This is why online patching is efficient. Oracle does not create a full duplicate copy of every database object for the patch edition. It uses inheritance — the patch edition only stores what is different from the run edition. Everything else is shared.

Editioned Objects vs Non-Editioned Objects

Not all database objects can be editioned. This distinction is fundamental to understanding why some patches require downtime mode and why EBR has limits.

Editioned objects — can exist in multiple editions simultaneously

PL/SQL packages and package bodies
Procedures and functions
Triggers
Views (when defined as editioning views)
Synonyms
Types and type bodies

Non-editioned objects — exist in a single copy shared by all editions

Tables — the physical storage is always shared
Sequences
Materialized views
Certain synonyms that point to non-editioned objects
Database links
Queues

This is the direct reason why patches that modify non-editioned objects — particularly tables — require downtime mode. You cannot safely change a table structure while users in the run edition are actively reading and writing to it, because the table is shared between editions. There is only one physical copy.

When you see apply_mode=downtime in a patch README, it almost always means the patch modifies a table or other non-editioned object. The downtime mode bypasses the edition-based cycle entirely and applies the change directly to the shared object with all services down.

How EBS Handles Table Changes During Online Patching

Since tables cannot be editioned, Oracle EBS uses a clever workaround involving editioning views and cross-edition triggers to make table changes appear editioned even though the underlying table is shared.

Editioning views

In EBS R12.2, application code does not access base tables directly. Instead, it accesses them through editioning views — views that sit on top of the physical table and present a specific set of columns to each edition.

When a patch adds a new column to a table, the base table gets the new column immediately — but the run edition's editioning view does not expose it. Users in the run edition cannot see the new column. Only the patch edition's editioning view exposes it. This gives the appearance of two different table structures while there is only one physical table.

Cross-edition triggers

When a user in the run edition inserts or updates a row, that data must also be reflected correctly when the patch edition takes over at cutover. Cross-edition triggers handle this synchronisation automatically.

A forward cross-edition trigger fires on DML in the run edition and copies data into the new columns that the patch edition expects. A reverse cross-edition trigger does the opposite — it keeps the run edition's data consistent if the patch edition writes to the new columns before cutover.

This is why ADOP cutover is never truly instant even for small patches. During cutover, Oracle must fire and resolve any pending cross-edition triggers, ensure data consistency between editions, and then switch the default edition. The more active DML was happening during the patch cycle, the more work cutover has to do.

Seed data and ZD_EDITION_NAME

EBS seed data — rows in application setup tables like FND_LOOKUP_VALUES — is also versioned per edition. Each seed data table has a column called ZD_EDITION_NAME. During the apply phase, new seed data rows written by the patch are tagged with the patch edition name. Users in the run edition see only rows tagged with the run edition. At cutover, the default edition switches and users begin seeing the patch edition's seed data automatically.

The Three Filesystems and How They Map to Editions

EBR handles the database tier. The application tier has its own parallel structure based on three filesystems. Understanding how they map together completes the picture.

Filesystem	Also Known As	Maps to DB Edition	Contents
Run filesystem	fs1 or fs2 — whichever is active	Run edition	Forms, reports, libraries, configuration serving users right now
Patch filesystem	fs1 or fs2 — whichever is inactive	Patch edition	Where ADOP applies patch files during the apply phase
Non-editioned filesystem	fs_ne	Neither — shared by both	ADOP logs, patch directories, shared configuration that does not change per edition

fs1 and fs2 alternate roles with every cutover. If fs1 is the run filesystem today, it becomes the patch filesystem after the next cutover. fs2 becomes the new run filesystem. This is why you never hardcode fs1 or fs2 in your scripts — always use the environment variables $APPL_TOP (run) and source the correct environment file.

Check which filesystem is currently run vs patch # Source run environment and check source /u01/oracle/R122/EBSapps.env run echo "Run filesystem: $APPL_TOP" # Check the NE base — always the same regardless of cutover echo "Non-editioned filesystem: $NE_BASE" # Check current session edition in the database sqlplus apps/<apps_password> <<EOF SELECT sys_context('USERENV','SESSION_EDITION_NAME') FROM dual; EOF

How EBR Maps to Every ADOP Phase

With EBR understood, the five ADOP phases make complete sense. Here is exactly what is happening at the EBR level during each phase.

ADOP Phase	What Happens at the EBR Level
Prepare	A new patch edition is created as a child of the run edition in the database. The patch filesystem is synchronised with the run filesystem. Cross-edition triggers are put in place to keep data consistent during the patch cycle.
Apply	All database object changes — packages, procedures, views — are written to the patch edition only. Users in the run edition are completely unaffected. New seed data rows are written with ZD_EDITION_NAME set to the patch edition name.
Finalize	Invalid objects in the patch edition are compiled. Editioning views in the patch edition are updated to expose any new table columns added by the patch. Cross-edition triggers are validated.
Cutover	The database default edition is switched from run to patch. All new sessions now connect to the new run edition. The old run edition becomes the old edition. The patch filesystem becomes the new run filesystem. Services are briefly restarted.
Cleanup	The old edition is dropped from the database. Cross-edition triggers used during the patch cycle are removed. Obsolete code objects and seed data from the old edition are purged. The old patch filesystem is reset for the next cycle.

What Users Actually Experience During Each Phase

ADOP Phase	User Experience	Any Impact?
Prepare	No change — fully connected to run edition	None
Apply	No change — patch edition is invisible to users	None
Finalize	No change — compilation happens in patch edition	None
Cutover	Brief disconnection while services restart — 10 to 30 minutes	Yes — this is the only user-facing downtime
Cleanup	No change — fully connected to new run edition	Minor — cleanup may cause brief I/O spikes on large environments

Edition-Enabled Schemas in EBS

For EBR to work on a schema, that schema must be edition-enabled. In EBS R12.2, the APPS schema and all application product schemas are edition-enabled out of the box. This was done as part of the R12.2 upgrade process and cannot be reversed once enabled.

Check which schemas are edition-enabled sqlplus / as sysdba <<EOF -- List all edition-enabled schemas SELECT username, editions_enabled FROM dba_users WHERE editions_enabled = 'Y' ORDER BY username; EOF

Custom schemas: If you have custom application schemas in EBS R12.2, they must also be edition-enabled for online patching to work correctly with custom code. If a custom schema is not edition-enabled, custom PL/SQL objects in that schema will not be visible correctly across editions. Use ALTER USER <custom_schema> ENABLE EDITIONS — but note this cannot be undone.

Useful EBR Queries for EBS DBAs

EBR diagnostic queries — run as SYSTEM or APPS sqlplus / as sysdba <<EOF -- 1. All editions in the database SELECT edition_name, status, created FROM dba_editions ORDER BY created; -- 2. Current session edition SELECT sys_context('USERENV','SESSION_EDITION_NAME') AS session_edition FROM dual; -- 3. Count of objects per edition (patch vs run) SELECT edition_name, object_type, COUNT(*) AS object_count FROM dba_objects_ae WHERE owner = 'APPS' GROUP BY edition_name, object_type ORDER BY edition_name, object_type; -- 4. Check editioning views in APPS schema SELECT view_name FROM dba_editioning_views WHERE owner = 'APPS' ORDER BY view_name FETCH FIRST 20 ROWS ONLY; -- 5. Cross-edition triggers (active during patch cycle) SELECT trigger_name, trigger_type, status FROM dba_triggers WHERE owner = 'APPS' AND trigger_type LIKE '%EDITION%' ORDER BY trigger_name FETCH FIRST 20 ROWS ONLY; -- 6. Edition-enabled schemas SELECT username, editions_enabled FROM dba_users WHERE editions_enabled = 'Y' ORDER BY username; EOF

Common Questions About EBR in EBS R12.2

Question	Answer
Can I connect to the patch edition as a DBA?	Yes, but only while a patching cycle is in progress. Use `ALTER SESSION SET EDITION = <patch_edition_name>` after prepare and before cutover.
Why does cutover take 10 to 30 minutes if editions already exist?	Cutover must flush shared pool, resolve cross-edition triggers, switch the default edition, restart application services, and re-establish connections. The database switch itself is fast — the service bounce takes most of the time.
What happens if I skip cleanup?	The old edition remains in the database. Over many patch cycles, old editions accumulate and consume space. ADOP will run a quick cleanup automatically on the next prepare, but this delays the prepare phase.
Why do some patches still require downtime?	Those patches modify non-editioned objects — typically tables — that cannot be versioned by EBR. The change must be made to the single shared physical object, which requires all users to be disconnected first.
Can EBR be used for non-EBS applications?	Yes. EBR is a standard Oracle Database feature available to any application. EBS R12.2 is simply the most prominent example of an application built on top of it.
Does EBR require Oracle Enterprise Edition?	Yes. EBR is only available in Oracle Database Enterprise Edition. It is not available in Standard Edition.

Summary — The Five Things to Remember

EBR allows two versions of database code objects to exist simultaneously in the same database — the run edition for users and the patch edition for patching
Editioned objects — packages, procedures, views, triggers — can exist separately per edition. Non-editioned objects — tables, sequences — are shared by all editions and cannot be changed online
Editioning views and cross-edition triggers are how EBS makes table changes appear editioned even though the physical table is shared
The three filesystems — run, patch, and non-editioned — mirror the database edition structure on the application tier. fs1 and fs2 alternate roles at every cutover
Cutover is the only user-facing downtime because it is the only moment when the default database edition switches and services restart. Everything before cutover happens in the invisible patch edition