adop utility in oracle apps R12.2

What is ADOP?

adop (Online Patching) Patching while End Users are accessing Applications. EBS R12.2 onwards all patching operations are online (system remains available during patching) unlike previous versions where system is unavailable for users during patching (Maintenance Mode).

Online Patching uses Edition Based Redefinition (EBR) which provides two copies of database objects (schema) pre and post patch.

A: Run Edition of database objects: used by online users and is not changed by patching

B: Patch Edition of database objects: used by patching tool and do not affect the running application

Note: There is third edition called Old Edition.

New Run Edition, previous Run Edition is marked as Old Edition. Full Cleanup Operation adop removes Old Edition.

Oracle provides this online patching system by using two Apps tier filesystems named fs1 and fs2 in Application tier, by using edition based redefinition feature of 11gR2 RDBMS in Database Tier.

Phases in adop

Normally, we have 5 phases when applying EBS patch. These phases are prepare, apply, finalize, cutover and cleanup.

Phases must be specified in the order they run, which is the order listed.

Prepareà Prepare the instance for online patching.

ApplyàApply patches to the patch edition.

FinalizeàReady the instance for cutover.

CutoveràPromote the patch edition to become the new run edition.

CleanupàDrop obsolete objects and seed data from old editions.

We start with prepare for synchronizing the patch file system for Applications and the patch version for db tier. Then we continue with apply phase. This phase is actual phase that the patch operations are done. adop uses patch file system to upload new apps tier files and uses the patch edition of the database to take db actions.  After apply we continue with adop=finalize. In this phase, application and database specific actions such as compilation takes place.

So those 3 phases require no downtime, but the next phase which is called cutover need a little downtime. It is automatic though. In cutover phase, adop switches the patched file system and db edition with the current/run file system and db edition. That's why Application Tier components are restarted in this phase. Downtime is coming from restarting the components.
The last phase is cleanup phase. It is self explanatory. In this phase ADOP starts cleaning up the old editions.

Examples of using adop:

To prepare instance for patching

$adop phase=prepare                      

To prepare instance for patching, specify patches, request merge, and apply with 4 workers.

$adop phase=prepare, apply patches=12345, 67890 merge=yes workers=4

To prepare instance for patching and apply patches interactively

$adop phase=prepare, apply

Running all phases in single command:

$adop phase=prepare, apply,finalize,cutover,cleanup patches=patch1,patch2

To apply patches with list of patches in the input_file.

$adop phase=apply input_file=adopsession20120702.txt

To fully automated patching with all parameters taken from input_file:

$adop input_file=adopsessions20120702.txt

To apply patches in hotpatch mode

$adop phase=apply input_file=adopsession20120702.txt hotpatch=yes

Parameters (all are optional):

$adop -status    (Status of the last or specific adop session)

$adop -help      (Provides usage details for the adop command)

cleanup_mode (optional cleanup processing control)

loglevel  (Takes values 'statement', 'exception', 'error', 'unexpected' [default: statement])

defaultsfile        (Path to custom adop defaults file)

patchtop             (Path to the user-specified directory where patches are unzipped)

mtrestart           (Takes values 'yes' or 'no' [default: yes]. Specifies whether to restart

the middle tier services at the end of cutover)

Parameters relevant for the apply phase

workers      (Specify number of parallel workers. If not specified, will be calculated automatically)

merge          (Merge patches before applying. Takes values 'yes' or 'no' [default: yes])

NOTE: This replaces AD Merge Patch

abandon

Abandon Used to specify whether to restart the previous run of adop. 
$adop phase=apply patches=10721639 abandon=yes

restart

Used to specify whether to restart the previous run of ADOP. May be useful if the previous action had an error.

$adop phase=apply patches=10721639 restart=yes

Note: If there was an error in the previous run, and 'abandon' is not set to 'yes', the same parameters will be re-used that were used in the failed run.

If you give a value for the 'restart' parameter, it cannot be the same as the value given for this parameter.

hotpatch

Applies patches in hotpatch mode. Takes values 'yes' or ‘no’ [default: no].

NOTE: This does not require or allow any other phases to be specified except 'apply'.

 How ADOP patches work on Multi node?

Adop patch is online "Patching Tool" uses remote APIs and ssh logging to execute patching operation on remote in a multi node environment. The Node that launch Adop become "Master node" and remote node become "salves".

NOTE: You only need to patch one node in a multi-node shared file system, but you must run AutoConfig manually on all the other nodes.

What is Adop Fs_Clone?

Fs_Clone is a command to copy the file system to the patch file system.

adop patching cycle in NON-INTERACTIVE mode

During apply phase, Non-interactive patching is a way to save time by avoiding some of the prompts and automating the patching process.

You can apply patches in non-interactive way by using a defaults file that contains much of the information you would have supplied at the adop prompts and by creating another file known as input file. Then, when you run adop, you specify the name of the input file. The location of the defaults file will also need to be included in the input file.

$ adop phase=apply input_file=<input_file.txt>

Locations of Default file on both the run APPL_TOP and patch APPL_TOP: $APPL_TOP/admin/<SID>_patch/adalldefaults.txt

NOTE: In R12.2, you don’t need to create this defaults file. The file is already created by oracle process. However you need to create one ‘input file’ to use with adop (The defaults file is not specified on the adop command line. It is the input file.) but in previous release we had to run autoconfig to create this file.

The input_file contents should include the following required parameters:

patches=<patch number>
workers=<number of workers>
patchtop=<directory where patches are staged>
defaultsfile=<defaults file on patch APPL TOP>

 To skip specific patching portion or action during apply phase

$adop phase=apply options=nodatabaseportion, nogenerateportion

In above command we are instructing adop to not run database and generate portion.

Other options can be

options=noactiondetails       (if you do not want the details to be printed.

options=noautoconfig 

if you are applying a number of patches in sequence and want to run AutoConfig only once in the

 end

options=nocheckfile  

to turn off the check file feature. Using check file adop skip some actions which are   already done

options=nocompiledb            when applying multiple NLS, documentations patches etc

options=nocompilejsp           when applying multiple NLS, documentations patches etc

options=nocopyportion        for skipping copy portion of the patch  

If adop phase=abort has run, then before proceeding further run below command

$adop phase=cleanup cleanup_mode=full

Error: Unable to continue as already another user is using adzdoptl.pl.

Previous session exist, cannot continue as per user input.

Workaround: Update the internal adop repository table for the latest session setting the status to completed.

Run the following statement to find out the session that is in running state:

SQL>select adop_session_id from ad_adop_sessions where status='R';

Set the status to 'C' (Completed) for that session, to re-try the phase that was interrupted:

SQL>update ad_adop_sessions set status='C' where status='R;

commit;

And try again!!!