How to Build a Quarterly Oracle EBS CPU Patching Calendar for Your DBA Team
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 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.
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.
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.
No comments:
Post a Comment