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

Oracle EBS 12.2 adop Phases and Options Reference (Online Patching)

A reference for the adop online patching utility in Oracle EBS 12.2: each phase, apply mode and common option, with an example command, whether it takes downtime and the mistakes that cause failed cycles. Options vary by AD-TXK level, so confirm with adop -help on your instance.

Download:

Command	Type	What it does	Downtime?	Example command	Gotchas
phase=prepare	Phase	Starts a patching cycle: checks the system, synchronises the patch file system with the run file system and creates the patch database edition	N	adop phase=prepare	If cleanup was not run after the previous cutover, prepare runs it first and the cycle starts late; run on the primary node, adop drives the other nodes
phase=apply	Phase	Applies one or more patches to the patch file system and patch edition	N	adop phase=apply patches=12345678	Users keep working on the run edition; can be repeated several times in one cycle before finalize
phase=finalize	Phase	Compiles invalid objects and gets the patch edition ready for cutover	N	adop phase=finalize	Run close to cutover to keep the cutover window short; finalize_mode=full can also gather statistics
phase=cutover	Phase	Stops services, makes the patch edition and file system the new run, restarts services	Y	adop phase=cutover	The only phase in a normal cycle that needs downtime; warn users and let running concurrent requests finish first
phase=cleanup	Phase	Drops obsolete editioned objects and cross-edition triggers left from the previous run edition	N	adop phase=cleanup	Run it explicitly after cutover; if skipped, the next prepare runs it automatically and starts late; default mode is standard
cleanup_mode=quick \| standard \| full	Option	quick does the minimum to allow the next cycle; standard also drops obsolete objects; full removes all old editions' data and is the most thorough	N	adop phase=cleanup cleanup_mode=full	Use full after abort and after actualize_all; quick is for tight schedules only
phase=fs_clone	Phase	Copies the run file system to the patch file system to re-synchronise them	N	adop phase=fs_clone	Needed after an abort and when the file systems are known to differ; takes much longer than the incremental sync in prepare
phase=abort	Phase	Abandons the current cycle before cutover and discards the patch edition	N	adop phase=abort	Only possible before cutover; afterwards run cleanup_mode=full and then fs_clone before the next prepare
phase=actualize_all	Phase	Creates actual copies of all code objects in the patch edition so old editions can be retired	N	adop phase=prepare,actualize_all,finalize,cutover,cleanup cleanup_mode=full	Run periodically when the number of database editions grows; long running, plan it as its own cycle
Combined phases	Phase	Runs several phases in one command	Y	adop phase=prepare,apply,finalize,cutover,cleanup patches=12345678	Includes cutover, so it takes downtime at the point cutover runs; fine for small patches in a maintenance window
apply_mode=downtime	Mode	Applies a patch directly to the run file system and edition with services down, no online cycle	Y	adop phase=apply patches=12345678 apply_mode=downtime	Only when the patch readme allows or requires it, typically for AD-TXK or initial upgrade patches; stop apps tier services first
apply_mode=hotpatch	Mode	Applies a patch to the run edition while the system is up, outside an online patching cycle	N	adop phase=apply patches=12345678 apply_mode=hotpatch	Only when the patch readme explicitly says hotpatch is allowed; cannot be used while an online patching cycle is in progress
patches=	Option	Comma-separated list of patch numbers (or driver files) to apply	N	adop phase=apply patches=12345678,23456789	Patches must be unzipped in the patch top directory; order matters unless merged
merge=yes	Option	Merges the listed patches into one before applying	N	adop phase=apply patches=12345678,23456789 merge=yes	Saves time for many small patches; a failure stops the whole merged patch
patchtop=	Option	Directory where the patches are unzipped	N	adop phase=apply patches=12345678 patchtop=/u01/patches	Defaults to $PATCH_TOP under fs_ne; use a path visible to all nodes in shared configurations
workers=	Option	Number of parallel AD workers for the patch	N	adop phase=apply patches=12345678 workers=8	Too many workers slow users on the run edition; size it to spare CPU during online apply
restart=yes	Option	Restarts a failed apply from where it stopped after you fix the cause	N	adop phase=apply patches=12345678 restart=yes	Read the worker log first; use adctrl to inspect worker status
abandon=yes	Option	Abandons a failed apply and starts that patch from the beginning	N	adop phase=apply patches=12345678 abandon=yes	Different from phase=abort, which throws away the whole cycle
options=	Option	Passes AD patching options to the apply, for example nocopyportion, nogenerateportion, nocompiledb	N	adop phase=apply patches=12345678 options=nocompiledb	Use only when the readme or Oracle Support tells you to; skipping portions can leave the patch incomplete
input_file=	Option	Reads adop parameters from a file of name=value lines	N	adop input_file=/u01/patches/apply_input.txt	Keeps long patch lists out of shell history; parameters on the command line and in the file must not conflict
mtrestart=no	Option	Leaves application tier services down after cutover	Y	adop phase=cutover mtrestart=no	Use when you need post-cutover manual steps before users return; start services yourself afterwards
adop -status	Utility	Shows the current or last session and the status of each phase on each node	N	adop -status	Check before every phase; a phase showing R (running) or F (failed) must be resolved first
adop -status -detail	Utility	Adds detail such as file system bases and per-node timings	N	adop -status -detail	Useful when one node in a multi-node install is out of step
adop -validate	Utility	Validates the online patching configuration across nodes without starting a cycle	N	adop -validate	Run after cloning or adding nodes, before the first prepare
AD_ADOP_SESSIONS	Utility	Table with one row per adop session and node, with a status column per phase	N	SELECT adop_session_id, node_name, prepare_status, apply_status, cutover_status, cleanup_status FROM ad_adop_sessions ORDER BY adop_session_id DESC	Read only; never update it to force a state, use abort or Oracle Support guidance
AD_ADOP_SESSION_PATCHES	Utility	Table of patches applied in each session, with status and file system	N	SELECT adop_session_id, bug_number, status, node_name FROM ad_adop_session_patches WHERE bug_number = '12345678'	BUG_NUMBER is a string; a row here does not prove the cycle reached cutover

Scope: EBS 12.2 online patching with adop. Behaviour and available options change with the AD-TXK code level; adop -help on your instance and the Maintenance Guide for your level are authoritative. Always follow the patch readme for the apply mode.

Patch cycle plan for your instance

Send us the patch list and your AD-TXK level. We will return an adop command sequence with apply modes taken from each readme and an expected downtime window.

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

Was this tool useful?

The online patching cycle in order

A normal cycle runs five phases from the primary apps node, with adop driving the other nodes. Only cutover takes the system down; everything else runs while users work on the run edition. You can run apply several times between prepare and finalize to stack patches into one cycle, and you can combine phases on one command line in a maintenance window.

1. prepare: sync patch file system, create patch edition
2. apply: patch the patch file system and edition (repeatable)
3. finalize: compile and get ready for cutover
4. cutover: short downtime, patch becomes run
5. cleanup: drop obsolete objects; if skipped, the next prepare runs it first
Out of cycle: abort (before cutover only), fs_clone, actualize_all

What runs on the run versus patch edition

During prepare, apply and finalize, users and concurrent managers keep using the run file system and the run database edition. adop works only on the patch file system and the patch edition, using editioning views and cross-edition triggers so data changed by users is carried forward. That is why patches applied online must be online-patching compliant, and why custom code must follow the 12.2 development standards (no direct DDL on base tables outside the supported AD_ZD utilities). Cutover stops services, switches the default database edition, swaps RUN_BASE and PATCH_BASE and restarts. Cleanup then removes what the old run edition left behind. Heavy apply workers still use database and CPU resources, so schedule large patches outside peak hours even though no downtime is taken.

Abort versus abandon

The two are easy to confuse and do very different things. abandon=yes is an apply option: a patch failed, you want to throw away that attempt and start the same patch again from the beginning in the same cycle. phase=abort ends the entire cycle: the patch edition and everything applied in it are discarded, and the run edition is untouched. Abort is only possible before cutover; after cutover the patch is in production and the way back is a fix-forward patch or a restore. After an abort, run adop phase=cleanup cleanup_mode=full and then adop phase=fs_clone so the patch file system matches the run file system again before the next prepare. restart=yes is the third choice: fix the cause and continue the failed apply where it stopped.

Hotpatch and downtime mode restrictions

apply_mode=hotpatch applies a patch straight to the run edition while users are on the system, with no prepare or cutover. Use it only when the patch readme explicitly says hotpatch is supported, and never while an online patching cycle is active. apply_mode=downtime also patches the run edition directly but with services stopped; readmes call for it mainly for AD and TXK infrastructure patches and some upgrade steps. Both modes change the run file system, so the patch file system falls behind: the next prepare synchronises it, or run fs_clone if the readme says so. If a readme gives no instruction, use the normal online cycle. Check adop -status before and after each command and keep the session logs from $NE_BASE/EBSapps/log/adop.

Frequently Asked Questions

What are the adop phases in Oracle EBS 12.2?

prepare, apply, finalize, cutover and cleanup form the normal cycle. Additional phases are abort (discard a cycle before cutover), fs_clone (re-synchronise the patch file system from the run file system) and actualize_all (create actual copies of all code objects so old database editions can be retired). Only cutover needs downtime in a normal cycle.

What is adop hotpatch?

apply_mode=hotpatch applies a patch directly to the running system without an online patching cycle and without downtime. Oracle supports it only for patches whose readme explicitly allows hotpatch mode. It cannot run during an active cycle, and because it changes the run file system, the next prepare synchronises the patch file system.

How do I abort an adop cycle?

Run adop phase=abort before cutover. This discards the patch edition and everything applied in the cycle; the run system is unaffected. Then run adop phase=cleanup cleanup_mode=full and adop phase=fs_clone before starting a new cycle with prepare. After cutover you cannot abort; you fix forward or restore.

How do I check the status of an adop session?

Run adop -status for the current or last session, or adop -status -detail for per-node information. The same data is in AD_ADOP_SESSIONS, one row per session and node with a status column for each phase, and the patches in AD_ADOP_SESSION_PATCHES. Session logs are under $NE_BASE/EBSapps/log/adop/<session_id>.

If you want an assistant that reads adop session logs on your own servers and explains in plain English why a phase failed, we can set that up privately.

Talk to an Expert Explore More Free Tools