OracleFree calculatorPDF, Excel, Word exportOracle E-Business SuiteAll Oracle E-Business Suite tools

Oracle EBS 12.2 Online Patching (adop) Cycle and Downtime Calculator

This calculator estimates how long an Oracle EBS 12.2 online patching cycle runs from prepare to cleanup, how many minutes of it users actually lose at cutover, and how that compares with applying the same patches in downtime mode. Use it to plan a patching window and to explain to the business why the cycle is long but the outage is short.

Your numbers

5 patches
min

Measured from your last cycle on the patch edition.

min
min
min
min
min
min
min

Your results

User downtime with online patching
35 min
Only cutover is user-facing downtime in a 12.2 online patching cycle.
Downtime avoided by online patching
90 min
Apply phase time
100 min
Patches x average apply time, reduced by 30% when merged (an assumption, measure your own).
Online patching cycle elapsed time
4 hrs
Prepare through cleanup. Users keep working except during cutover.
User downtime in downtime mode
125 min
Services stay down while all patches apply to the run edition.
Online downtime as share of downtime mode
28%

Defaults are planning placeholders, not Oracle figures. Replace them with phase times from adop -status -detail for your last cycle. The merge factor is an assumption. Downtime mode is only allowed where the patch README or Oracle Support permits it.

Save results:

User downtime vs number of patches

Sweeps Number of patches from 1 to 40, holding your other inputs fixed.

Send us your adop -status output

We will turn your last cycles into measured phase times and a realistic patching window for the next one.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to use it

Enter the number of patches in the cycle and the average apply time per patch, then the duration of each adop phase. The best source is your own history: adop -status -detail prints start and end times per phase and node, and AD_ADOP_SESSIONS records the status of each phase per session. Split cutover into stopping services, the file system and edition switch, and starting services, because start time on a multi-node system is often the largest part. The downtime-mode overhead is the time to stop and restart services around a downtime-mode apply.

  • Primary output: user downtime with online patching (cutover only).
  • Second primary: minutes of downtime avoided compared with downtime mode.
  • The chart sweeps the number of patches from 1 to 40.

The model behind the numbers

In 12.2 online patching, prepare synchronises the patch file system and creates the patch edition, apply runs the patches against the patch edition while users work on the run edition, finalize readies the system for cutover, cutover stops services, switches file systems and editions and restarts services, and cleanup removes obsolete objects. Oracle's Maintenance Guide describes cutover as the only phase that requires downtime, and cleanup can run after users are back. So the calculator treats online downtime as stop + switch + start, independent of the number of patches, while downtime mode costs the stop/start overhead plus the full apply time. Formulas: apply = patches x average x (0.7 if merged, else 1); cycle hours = (prepare + apply + finalize + cutover + cleanup) / 60.

Worked example

With the defaults (5 patches at 20 minutes, no merge, prepare 45, finalize 20, cutover 10 + 10 + 15, cleanup 30), apply takes 100 minutes and the full cycle runs about 3.8 hours, but users lose only 35 minutes at cutover. Applying the same five patches in downtime mode would cost 125 minutes of outage, so online patching avoids 90 minutes, and its outage is 28% of downtime mode. At 20 patches the cycle is about 8.8 hours, the cutover stays at 35 minutes in this model, and downtime mode would need 425 minutes.

Gotchas that change the numbers

Cutover is not truly constant: a cutover that has to run outstanding finalize work, many cross-edition triggers or a slow managed-server start on many nodes takes longer, so measure it per cycle. Prepare can be much longer after a large previous cycle because fs_clone or file synchronisation has more to copy. Cleanup in full mode after many patches can run for hours, which matters if you want to start another cycle the same day. Some patches, such as certain AD and TXK delta updates or the initial technology stack patches, require specific modes or hotpatch handling described in their README, and downtime mode is only for patches that permit it.

Frequently Asked Questions

What are the adop phases in Oracle EBS 12.2?

Prepare, apply, finalize, cutover and cleanup, with abort available before cutover to discard the patch edition. Users keep working on the run edition through prepare, apply and finalize; cutover is the outage, during which services stop, the patch file system and edition become the run ones, and services restart. Cleanup removes old editions and objects after users return.

How do I apply a patch in Oracle EBS 12.2?

Run adop phase=prepare, then adop phase=apply patches=<number> (comma list or a merged patch), then adop phase=finalize, adop phase=cutover and adop phase=cleanup, checking adop -status between phases. Read each patch README first: some require downtime mode (apply_mode=downtime) or hotpatch, and AD or TXK updates may have their own sequence.

How much downtime does online patching save?

It depends on how much apply time you move out of the outage. With online patching the outage is roughly the cutover duration, typically tens of minutes on a well-tuned system, while downtime mode costs the full apply time plus stop and start. The more patches in a cycle, the bigger the saving, which this calculator's chart shows.

Should I merge patches before applying them in 12.2?

Merging related patches with admrgpch usually shortens apply because common steps such as relinking, generation and driver processing run once. The 30% reduction in this tool is a planning assumption, not an Oracle figure. Check that every patch's README allows merging and test the merged patch in a clone, then use the measured time in the calculator.

If your DBAs want to ask how long the last cycles took and what is pending in plain English, answered from your EBS AD tables on your own servers, we can set that up.

ArchRay builder
Design the on-prem AI stack for Oracle E-Business Suite: model, GPUs, RAG pipeline, guardrails
See memory, speed and cost as you swap parts, then export the diagram. Free, in your browser.
Open the builder

Keep exploring

Free tools

ERP fixes and how-tos

Runs with your ERP

AI on your ERP

Integrations

Software