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:
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
$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>
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!!!
