online vs downtime mode in ADOP — When Oracle Forces a Full Outage
One of the most common assumptions EBS R12.2 DBAs make is that all patches run in online mode — that users stay connected throughout and the only downtime is the brief cutover window. This is usually true, but not always.
Some patches require downtime mode, which is a fundamentally different way of applying a patch. It bypasses the online patching cycle entirely, patches the run filesystem directly, and requires a full application outage during the apply phase — not just at cutover.
Understanding the difference between online mode, downtime mode, and hotpatch mode is essential before you start any patching session. Getting it wrong means either an unexpected outage or a failed patch apply.
The Three apply_mode Options
ADOP supports three modes through the apply_mode parameter. Each works differently and applies the patch to a different target.
| apply_mode | Target | Outage Required | Uses Patching Cycle |
|---|---|---|---|
online |
Patch edition and patch filesystem | Only at cutover — 10 to 30 min | Yes — full prepare to cleanup cycle |
downtime |
Run edition and run filesystem directly | Full outage during apply phase | No — no patching cycle needed |
hotpatch |
Run edition and run filesystem directly | None — services stay running | No — no patching cycle needed |
The default mode when you run adop phase=apply without specifying apply_mode is online. You never need to type apply_mode=online explicitly — it is assumed unless you specify otherwise.
Online Mode — The Standard Approach
Online mode is what ADOP was built for. The patch is applied to the patch edition of the database and the patch filesystem while the run edition continues serving users. The five-phase cycle runs in full — prepare, apply, finalize, cutover, cleanup.
# apply_mode=online is the default — no need to specify it adop phase=apply patches=36478206 workers=8 # Same result — explicit is fine but not required adop phase=apply patches=36478206 apply_mode=online workers=8
What happens during online mode
- Patch files are copied to the patch filesystem
- Database changes are applied to the patch edition only
- Users continue working on the run edition — fully unaffected
- Finalize compiles objects and generates forms in the patch edition
- Cutover is the only window where services restart — typically 10 to 30 minutes
All Oracle EBS R12.2 CPU patches are designed and tested for online mode. This is the mode you should use for every quarterly CPU patch unless the patch README explicitly states otherwise.
Downtime Mode — When Oracle Forces a Full Outage
Downtime mode bypasses the online patching cycle entirely. There is no prepare phase, no patch edition, and no dual filesystem switch. The patch is applied directly to the run edition and run filesystem — with all application services shut down first.
This is a fundamentally different process. It is not just a longer version of online mode. It is a separate patching method with its own rules.
# Shut down ALL application services before running this # ADOP will verify services are down before proceeding adop phase=apply patches=36478206 apply_mode=downtime # No prepare phase before this # No finalize, cutover, or cleanup after this # The patch is complete when the apply command finishes
What happens during downtime mode
- ADOP verifies that all application tier services are shut down
- If services are still running, ADOP will refuse to proceed
- The patch is applied directly to the run edition of the database
- The patch is applied directly to the run filesystem
- When apply completes, restart services manually — no cutover needed
Important rules for downtime mode from Oracle:
1. Downtime mode is only supported for production use where it is explicitly documented in the patch README, or when directed by Oracle Support or Development.
2. R12.2 patches are not normally tested in downtime mode. Use it only when Oracle mandates it — not as a shortcut.
3. No online patching cycle can be in progress when running downtime mode.
Shutting down services before downtime mode
Hotpatch Mode — Online Without a Patching Cycle
Hotpatch mode applies the patch directly to the run edition while services remain running — with no prepare phase and no patching cycle. It is the fastest mode but also the most restricted.
Hotpatch mode is only safe for patches that do not modify existing schema objects or code used by the running application. Oracle restricts hotpatch use to specific patch types — NLS patches, Online Help patches, and any patch whose README explicitly states hotpatch is supported.
# Only use when the patch README explicitly approves hotpatch adop phase=apply patches=36478206 apply_mode=hotpatch # Services remain running — no outage # No prepare, finalize, cutover, or cleanup needed
Do not use hotpatch mode for CPU patches. CPU patches modify schema objects and code. Applying them in hotpatch mode can cause application failures for users who are connected during the apply. Always use online mode for CPU patches.
How to Know Which Mode Your Patch Requires
This is the most practical question and the one most DBAs skip in their rush to start patching. The answer is always in the patch README. Here is how to check.
Step 1 — Read the patch README
Every patch downloaded from MOS includes a README.txt and README.html file. Open it before running any adop command. Look for these specific phrases:
Step 2 — Run a dryrun before the real apply
A dryrun simulates the apply without making any changes. If the patch requires downtime mode and you attempt it in online mode, the dryrun will flag the issue before you commit to the real apply.
Step 3 — Check MOS for the patch note
For CPU patches, the MOS availability document — MOSFS KA1539 for April 2026 — lists any patches that require downtime mode. Always read this before downloading patches.
Key Differences — Side by Side
| Factor | Online Mode | Downtime Mode | Hotpatch Mode |
|---|---|---|---|
| Prepare phase needed | Yes | No | No |
| Services during apply | Running | Must be down | Running |
| Patch applied to | Patch edition / patch filesystem | Run edition / run filesystem | Run edition / run filesystem |
| Cutover phase needed | Yes | No | No |
| Total user downtime | 10 to 30 min at cutover only | Full duration of apply | None |
| Tested by Oracle internally | Yes — standard | Not normally | Only for specific patch types |
| Safe for CPU patches | Yes | Only when README states it | No |
| Can abort if needed | Yes — adop phase=abort | No — no cycle to abort | No — use restart=yes or abandon=yes |
Why Some Patches Require Downtime Mode
Online patching in R12.2 works because of Edition-Based Redefinition (EBR) in the Oracle database. EBR allows two editions of database objects to exist simultaneously — the run edition for users and the patch edition for patching. This is what makes online patching possible.
However, not all database objects can be editioned. Objects like database triggers, sequences, synonyms, and certain types of tables are non-editioned — they exist in a single copy shared by both editions.
When a patch needs to modify a non-editioned object, it cannot do so safely while users are connected to the run edition. Making a structural change to a shared object while users are actively using it risks data corruption or application errors. Oracle therefore mandates downtime mode for patches that touch these objects.
- Editioned objects — packages, procedures, functions, views, types — safe for online mode
- Non-editioned objects — sequences, synonyms, triggers, certain tables — require downtime mode
- The patch README will always state which category applies
Planning Your Maintenance Window
The mode your patch requires directly determines how long your maintenance window needs to be. Plan accordingly before communicating downtime to your users.
| Mode | When to Communicate Downtime | Estimated Window |
|---|---|---|
| Online mode | For cutover phase only | 10 to 30 minutes at cutover |
| Downtime mode | For entire apply phase plus service restart | Duration of apply plus 15 to 30 min for service start/stop |
| Hotpatch mode | No downtime to communicate | Zero user-facing downtime |
When a CPU patch cycle includes both online patches and one downtime-mode patch, plan the maintenance window around the downtime-mode patch. Apply downtime patches in their own separate session. Do not mix modes in the same ADOP cycle.
Quick Decision Guide
| Situation | Mode to Use |
|---|---|
| Quarterly CPU patch — README says online patching cycle | apply_mode=online (default) |
| README explicitly says apply_mode=downtime | apply_mode=downtime — shut down services first |
| NLS patch or Online Help patch | apply_mode=hotpatch — only if README confirms |
| Oracle Support directs you to downtime mode | apply_mode=downtime — follow their instructions exactly |
| Not sure which mode to use | Read the README. Run dryrun. Default to online. Raise SR if unclear. |
Common Mistakes to Avoid
| Mistake | What to Do Instead |
|---|---|
| Running downtime mode without reading the README | Always read README first — downtime mode is only for patches that mandate it |
| Using downtime mode as a shortcut to skip the patching cycle | Online mode is the standard. Downtime mode is not a shortcut — it carries risk |
| Running downtime mode while services are still up | ADOP will refuse to proceed — shut down all services before running downtime mode |
| Using hotpatch mode for CPU patches | CPU patches modify schema objects — hotpatch mode will cause application errors |
| Running downtime mode while an online patching cycle is active | Complete or abort the existing cycle before running downtime mode |
| Not running dryrun before the real apply | Always dryrun first — it will flag mode-related issues before real apply starts |
Summary
- Online mode is the default and the standard for all CPU patches — users stay connected throughout, only cutover causes a brief outage
- Downtime mode bypasses the patching cycle, patches the run edition directly, and requires a full outage during apply — use only when the patch README mandates it
- Hotpatch mode patches the run edition with no outage — restricted to NLS, Online Help, and patches that explicitly document hotpatch support
- Always read the patch README before starting any apply session
- Always run
apply_mode=dryrunbefore the real apply - When in doubt, default to online mode and raise an SR with Oracle Support
No comments:
Post a Comment