Ad Online Patching (ADOP) in Oracle Apps (E-Business Suite) R12.2

Start Here

Get in touch with a
TriCore Solutions specialist

Blog | Aug 10, 2017

Ad Online Patching (ADOP) in Oracle Apps (E-Business Suite) R12.2

Applying Oracle E-Business Suite patches without significant system downtime is referred to as the online patching, and there is a new utility called ADOP to apply patches. 


In this two part blog series, I will explain about ADOP phases, patch process cycle steps and some real time known ADOP issues and their fixes.  In Part one of my blog series I explains about ADOP phases and patch Process cycle Steps. In Part Two, I explains about  ADOP real time known issues and fixes. In this blog, I have briefly shared ADOP commands usage and tips. Click here to read Part 2...

Applying Oracle E-Business Suite patches without significant system downtime is referred to as the online patching, and there is a new utility called ADOP to apply patches.

oracle e-business patches

Image Source: 

ADOP Phases and Patch Process Cycle Steps

To apply a patch in R12.2 you need to use ADOP and run through all of the phases in a sequence as described below.

Download any required technology patches and unzip the contents. The patch contents may be unzipped into a $NE_BASE/EBSapps/patch.

Note: The ADOP utility sets its own environment. There is therefore no need to source the environment before running it.


Set the environment by executing (sourcing) the run/patch file system environment file:

Source <EBS install base>/EBSapps.env run

An online patching consists of several phases, which are specified on the ADOP command line as follows:

adop phase=<phase_name>

Prepare phase - Used to start a new online patching cycle:

$ adop phase=prepare

Apply Phase - Used to apply one or more patches to the patch edition of an Oracle E-Business Suite system:

In a normal online patching cycle, below steps should be executed from the patch file system after the prepare phase.

$ source <EBS install base>/EBSapps.env patch

$ adop phase=apply patches=123456,789101 workers=8

Note: All customization changes also can be deployed in apply phase.

Finalize Phase - Used to perform the final patching operations that can be executed while the application is still online:

$ adop phase=finalize

Cutover Phase - Used to perform the transition to the patched environment:

$ adop phase=cutover

Cleanup Phase - Used to remove old objects that are no longer needed:

$ adop phase=cleanup

Abort command

If necessary, an online patching cycle can be terminated, with the actions taken being discarded.

The command to perform this operation is:

$ adop phase=abort

This abort command is only available up to (but not including) the cutover phase. After cutover, the system is running on the new edition, and abort is no longer possible for that patching cycle.

Running all phases in a single command:

adop phase=prepare,apply,finalize,cutover,cleanup patches=<patch_number1>,<patch_number2>

actualize_all : Actualize all objects in the Patch Edition.  

cleanup_full  : Cleanup and drop Old Editions.  

abandon       : yes|no - Abandon failed patches.

Below are the other cleanup_modes that can be used on different occasions.

  1. cleanup_mode=quick –Performs minimum cleanup, including removal of obsolete crossedition triggers and seed data. Use quick cleanup when you need to start the next patching cycle as soon as possible.
  2. leanup_mode=standard – Does the same as quick mode, and also drops (removes) obsolete editioned code objects (covered objects).
  3. cleanup_mode=full –Performs maximum cleanup, which drops all obsolete code and data from earlier editions.


Abort PHASE is conditional phase. This phase cannot be specified with any other phase.

If for some reason either the Prepare or Apply phase fails or gives you problems, you can abort the patching cycle at either of these points by running a special phase with the Abort Command. The actions taken will be discarded (rollbacked).

IMPORTANT: This abort command is only available up to (but not including) the cutover phase. After cutover, the system runs on the new edition, and abort is no longer possible for that patching cycle.

The command to perform this operation is:

$ adop phase=abort

VERY IMPORTANT: After running abort, a full cleanup must be performed.

adop phase=cleanup cleanup_mode=full

Alternatively, you can run a combined command to abort the patching cycle and perform a full cleanup:

$ adop phase=abort,cleanup cleanup_mode=full

If any attempt was made to apply patches to the patch edition, after abort you must run the fs_clone phase (adop phase=fs_clone) to recreate the patch file system.


The fs_clone phase is a command that is used to synchronize the patch file system with the run file system. The fs_clone phase should only be run when mentioned as part of a specific documented procedure.

This command must be invoked from the run file system, before the next prepare phase is run.

$ source <EBS install base>/EBSapps.env RUN

$ adop phase=fs_clone

If an fs_clone operation fails, you can rerun it with the option force=yes to restart it from the beginning (with the same session ID), or force=no to restart it from the point where it failed.

Dropping Old Editions with the Actualize all Phase

As each online patching cycle is completed, the database starts accumulating additional old database editions. As the number goes up, the system performance gets affected. As soon as the number of old database editions reaches 25 or more, you should consider dropping all old database editions by running the adop actualize_all phase and then perform a full cleanup.

Tip:  This procedure will take a large amount of time (significantly longer than a normal patching cycle), and should only be performed when there is no immediate need to start a new patching cycle.

Before starting, you should ensure that the system has the recommended database patches and the latest AD-TXK code level installed.

To proceed, run the following commands in the order shown:

$ adop phase=prepare

$ adop phase=actualize_all

$ adop phase=finalize finalize_mode=full

$ adop phase=cutover

$ adop phase=cleanup cleanup_mode=full

You have now completed removal of the old database editions.

ADOP Command Tips.

cm_wait= time<minutes>  [default: forever] specifies the number of minutes to wait for Concurrent Manager shutdown.  Adop cutover starts by requesting a concurrent manager shutdown and then waits for in-progress requests to complete.

If Concurrent Manager does not shutdown within the specified time limit, remaining concurrent requests will be killed and cutover will proceed.

Below command is used when running cutover to specify how long to wait for existing concurrent processes to finish running before shutting down the Internal Concurrent Manager, in below example the cm wait time is 10 minutes. By default, adop will wait indefinitely for in-progress concurrent requests to finish.

adop phase=cutover cm_wait=10

Below command will implicitly stop and will not restart services, with this parameter, cutover will be complete without restarting the application tier services.

adop phase=cutover cm_wait=10 mtrestart=no

adop hotpatch steps (we cannot abort hotpatch and abondon cannot be done):

Hotpatch which can apply directly on run fs

$ adop phase=apply patches=<patch_list> hotpatch=yes

After hotpatch please run phase=cleanup and phase=fs_clone to sync the run fs with patch fs to prepare for next patching cycle

adop re-apply patch forcefully:

$ adop phase=apply patches=<patch list> hotpatch=yes options=forceapply

adop deal with "Continue As If It Were Successful" error:

$ adop phase=apply patches=<patch list> abandon=no restart=yes flags=autoskip

To define workers in adop:

$ adop phase=apply patches=<patch list> workers=5

 To define patchtop in adop:

$ adop phase=apply patches=<patch list> patchtop=<patch location base>

 adop merge patch:

$ adop phase=apply patches=<patch list> merge=yes

 Restarting adop From A Failed Session

 $ adop phase=abort

 $ adop phase=cleanup cleanup_mode=full

 $ adop phase=fs_clone

Then reapply the patch

 adop apply for language patch:

$ adop phase=apply patches=1234456_JA:u123456.drv

adop non-interactive with patch top and define driver:

$ adop phase=apply options=nocopyportion patchtop=$XLA_TOP/patch/115 patches=driver:xla123456.drv

 ADOP Steps to follow to skip the failed workers:

  1. Use adctrl and select option#8 (This will not be visible) to skip the failed jobs
  2. Restart adop using "restart=yes" parameter

** If the failed jobs are numerous, then better to re-start this patch once again with autoskip option

adop restart=no abandon=yes flags=autoskip

This command will restart the patch once again from starting onwards and will skip all of the failures if any occurred. However make sure to review the log file at the end of the patch application that you have skipped the failures that you want to.

ADOP is supported by the capability of storing multiple application editions in the database, and the provision of a dual application tier file system. At any given point in time, one of these file systems is designated as run (part of the running system) and the other as patch (either being patched or awaiting the start of the next patching cycle). Whichever is the current run file system appears to the user in exactly the same way as the single application tier file system did in Oracle E-Business Suite releases prior to 12.2. 

The existence of the dual file system has implications for patches that change the system configuration. The ADOP utility is required for applying software patches to the patch file system, however it is not required to perform configuration changes. Depending on the specific situation, configuration changes can be made to either the run file system or the patch file system: automatic synchronization subsequently takes place in both cases. For any questions on the topic click below. You can also leave a comment in the field below.

Ask Nagunaik