adop -examples
Applications DBA Online Patching Tool (adop)
See Oracle E-Business Suite Maintenance Guide for a full description of
adop features, operation, and usage.
Standard Online Patching Cycle:
In Oracle E-Business Suite Release 12.2, patches are normally applied
using an online patching cycle. The online patching cycle consists of
five phases which are executed in order.
Example - Typical online patching cycle:
source <ebs_root>/EBSapps.env run
adop phase=prepare
adop phase=apply patches=123456
adop phase=finalize
adop phase=cutover
source <ebs_root>/EBSapps.env run
adop phase=cleanup
Note that after cutover the command line environment should be re-loaded
as the run edition file system has changed.
In a multi-node deployment, adop commands are only executed from the
primary node. The primary adop session uses remote execution to
automatically perform required actions on any secondary node.
Multiple phases can be executed in a single adop command.
Example - combined finalize/cutover/cleanup:
adop phase=finalize,cutover,cleanup
Prior to cutover, it is possible to execute additional
"apply" and "finalize" phases as needed.
Example - applying multiple patches using separate apply commands:
source <ebs_root>/EBSapps.env run
adop phase=prepare
adop phase=apply patches=123456
adop phase=apply patches=223456
adop phase=finalize
adop phase=apply patches=323456
adop phase=finalize
adop phase=cutover
source <ebs_root>/EBSapps.env run
adop phase=cleanup
Note that it is possible to apply additional patches after running the
finalize phase, but if you do so then you will need to run the finalize
phase again. Finalize must always be run immediately prior to cutover.
General parameters applicable to all phases:
workers=<number> [default: computed]
Number of parallel workers used to execute tasks. Default value is
computed principally according to number of available CPU cores.
Example:
adop phase=prepare workers=8
The example command executes the prepare phase with 8 parallel workers.
Not all processing can be executed with parallel workers, and in such
cases the workers parameter is ignored. In multi-node systems the
workers parameter indicates workers per node.
input_file=<file_name>
As well as being entered directly on the command line, adop parameters
can be specified in a text file, with one
<parameter>=<value>
on each line of the file. Command line parameters override input file
parameters.
Example - Input File text "empty_cycle.txt" for empty patching cycle:
phase=prepare,finalize,cutover,cleanup
workers=4
loglevel=statement
Example - Use input file to execute empty patching cycle:
adop input_file=empty_cycle.txt workers=1
The example command will execute an empty patching cycle with a
single worker and maximum log detail.
loglevel=(statement|procedure|event|warning|error|unexpected)
[default: event]
Controls the level of diagnostic log detail displayed on the
console output. Each log message is tagged with a level:
1) statement - internal debugging messages
2) procedure - internal procedure begin/end messages
3) event - significant processing action
4) warning - important user message or possible problem
5) error - a patching action has failed, processing continues
6) unexpected - a critical action has failed, processing halted
Setting loglevel will display messages at that level and higher.
Example - Display full log details:
adop phase=prepare loglevel=statement
Example - Display only warnings and errors:
adop phase=prepare loglevel=warning
prompt=(yes|no) [default: yes]
Specifies whether adop should prompt for user input on warnings.
By default adop will ask user whether to continue or exit on
some warning messages. If this parameter is set to "no" adop
will remain fully non-interactive, and will continue past any
warning messages without user confirmation.
Example - Disable user prompt for warnings:
adop phase=cutover prompt=no
Diagnostic Parameters, normally not used unless directed by Support:
allowcoredump=(yes|no) [default: no]
Specifies whether adop should create a core dump if it crashes. This
option should only be used if directed by support.
Example - Enable writing of core dump files:
adop phase=cutover allowcoredump=yes
analytics=(yes|no) [default: no]
Controls whether adop writes additional reports with information
that might be helpful in some diagnostic situations. This option
should not be used unless directed by Support.
Example - Enable additional analytic reports
adop phase=finalize analytics=yes
defaultsfile=<file_name> [default: adalldefaults.txt]
Name of the response file providing default parameter values for
non-interactive execution of adadmin and adop. The file must be in
the $APPL_TOP/admin/$TWO_TASK directory in both run edition and patch
edition file systems. The default file "adalldefaults.txt" is
maintained by AutoConfig and normally you should not need to change
any values.
Example - Using a custom AD Defaults file:
adop phase=apply defaultsfile=adcustomdefaults.txt
Prepare Parameters:
skipsyncerror=(yes|no) [default: no]
Specifies whether to ignore errors that may occur during incremental
file system synchronization. This might happen if you applied
a patch in the previous patching cycle that had errors but decided
to continue with the cutover. When the patch is synchronized on
the next patching cycle, the apply errors may occur again, but
can be ignored.
sync_mode=(delta|patch) [default: patch]
Specifies the method used to synchronize the patch file system
with the run file system.
'delta' mode uses the file system synchronization command
specified in $AD_TOP/patch/115/etc/delta_sync_drv.txt.
'patch' mode reapplies the patches that were applied on
the run file system.
Example:
adop phase=prepare skipsyncerror=yes sync_mode=delta
Note: sync_mode has been deprecated and replaced with prepare_sync_mode
(for prepare phase) and fs_clone_sync_mode (for prepare and fs_clone
phases).
prepare_sync_mode=(patch|delta) [default:patch]
Specifies the method used to synchronize the patch file system
with the run file system.
This parameter replaces sync_mode, which has been deprecated.
'delta' mode uses the file system synchronization command
specified in $APPL_TOP_NE/ad/admin/delta_sync_drv.txt.
'patch' mode reapplies the patches that were applied on
the run file system.
Example:
adop phase=prepare prepare_sync_mode=patch
adop phase=prepare prepare_sync_mode=patch fs_clone_sync_mode=cp
fs_clone_sync_mode=(cp|delta) [default:cp]
Specifies the method used to synchronize the patch file system
with the run file system.
This parameter replaces sync_mode, which has been deprecated.
'delta' mode uses the file system synchronization command
specified in $APPL_TOP_NE/ad/admin/delta_sync_drv.txt.
'cp' mode creates the complete patch file system from run file system.
Example:
adop phase=prepare fs_clone_sync_mode=cp
adop phase=prepare prepare_sync_mode=patch fs_clone_sync_mode=cp
Apply Parameters:
apply=(yes|no) [default: yes]
Controls whether adop actually applies the patch. You can specify
"apply=no" to run adop in test mode, where the patch will not actually
be applied, and adop will record what it would have done in the log.
Example - Execute adop apply in test mode:
adop phase=apply apply=no patches=1234
patches=<patch#>[,<patch#>...]
patches=<patch_directory>:<driver>[,<patch_directory>:<driver>...]
This parameter specifies a comma-separated list of patches to be
applied. Patches can be specified either as the patch number or
by the patch directory and driver file. All patches are expected
to be in the $PATCH_TOP directory on all tiers. Patches are applied
serially unless the merge=yes parameter is specified.
Example - Apply two patches in series:
adop phase=apply patches=1234,5678
Example - Apply patch and its translation:
adop phase=apply patches=1012464,10124646_AR:u10124646.drv
patchtop=<directory_name> [default: $PATCH_TOP]
Path to a user-specified directory where patches are unzipped.
The default and recommend location is the $PATCH_TOP directory
automatically created by the install. When using an alternate
patchtop you must ensure that the location is not within the
editioned file systems (fs1, fs2) and is accessible by the same
path for all nodes of a multi-node deployment.
Example - Apply patch from alternate patchtop directory:
adop phase=apply patches=123456 patchtop=/install/patches
apply_mode=(online|downtime|hotpatch) [default: online]
Use online mode to apply a patch to the patch edition during an
online patching cycle; downtime mode to apply a patch to the
run edition when application services are down; and hotpatch
mode to apply a patch to the run edition when application
services are up. Only use hotpatch mode when explicitly
directed by documentation.
Example - apply a patch in downtime mode:
adop phase=apply patches=123456 apply_mode=downtime
In downtime mode, adop will validate that application services
are shutdown before apply the patch. The patch will be applied
to the run edition of the system. Downtime mode cannot be used
if there is an online patching cycle in progress.
Example - apply a patch in hotpatch mode:
adop phase=apply patches=123456 apply_mode=hotpatch
In hotpatch mode, adop will apply the patch to the run edition
of the system while application services are still running. Patches
that can be safely applied in hotpatch mode (such as NLS and Online
Help patches) will document this in the patch readme. Hotpatch mode
cannot be used if there is an online patching cycle in progress.
merge=(yes|no) [default: no]
Indicates whether adop should merge a list of patches before applying.
By default, adop will apply a list of patches serially in the order
specified. You can also use AD Merge Patch to merge multiple patches
ahead of the apply command.
Example - Merge multiple patches before applying
adop phase=apply patches=1234,5678 merge=yes
In some cases it may be necessary to merge patches, such as when
an additional patch corrects an installation issue in the main patch.
If the merge parameter is required, this will be documented in the
patch readme.
restart=(yes|no) [default: no]
Use restart=yes to resume the previous failed apply command
from where processing terminated. If an apply command fails,
check the log files for further information. If the problem
can be corrected, you can then restart the apply command where
it left off using the restart parameter.
Example - Restart a apply command
adop phase=apply patches=123456 restart=yes
When restarting a failed apply it is important to use the
same parameters as the failed command, with only the addition
of the restart=yes parameter.
abandon=(yes|no) [default: no]
Use abandon=yes to abandon the previous failed apply command
and start a new apply command. Note that any changes made
to the system by the failed command will remain in effect.
The abandon flag is most useful when applying a replacement
patch for the failing patch.
Example - Abandon previous apply command and apply replacement
adop phase=apply patches=223456 abandon=yes
If a patch fails to apply and there is no replacement patch,
you may also abort the online patching cycle. See abort phase
later in this text.
options=<patch_option>[,<patch_option>...]
Options can be specified in a comma-separated list to control
advanced features when a patch is applied. These options are normally
not needed unless specified by documentation or support. Note
that these options can be prefixed with "no", e.g. "nocheckfile",
to disable the behavior, and for some options "no" is the default.
checkfile - Skip running exec, SQL, and exectier
commands if they are recorded as already run.
[default: checkfile]
compiledb - Compile invalid objects in the database
after running actions in the database driver.
[default: compiledb]
compilejsp - Compile out-of-date JSP files, if the patch
has copy actions for at least one JSP file.
[default: compilejsp]
copyportion - Run commands found in a copy driver.
[default: copyportion]
databaseportion - Run commands found in a database driver.
[default: databaseportion]
generateportion - Run commands found in a generate driver.
[default: generateportion]
integrity - Perform patch integrity checking
[default: nointegrity]
autoconfig - Run AutoConfig.
[default: autoconfig]
actiondetails - Turn off display of action details.
[default: actiondetails]
parallel - Run actions that update the database or
actions that generate files in parallel.
[default: parallel]
prereq - Perform prerequisite patch checking prior to
running patch driver files.
[default: noprereq]
validate - Connect to all registered Oracle E-Business
Suite schemas at the start of patch application.
[default: novalidate]
phtofile - Save patch history to file
[default: nophtofile]
forceapply - Reapply a patch that has already been applied.
Useful in combination with "nocheckfile" option
to rerun files that have already been executed.
[default: noforceapply]
Example - Apply patch again, force re-execution of driver commands:
adop phase=apply patches=123456 options=forceapply,nocheckfile
This command will apply the patch again, and will execute SQL, exec
and exectier actions even if they have already been executed.
flags=<patch_flag>[,<patch_flag>...]
Flags can be specified in a comma-separated list to control advanced
features when applying a patch. Note that these flags can be prefixed
with "no", e.g. "nologging", to disable the behavior and for some
flags "no" is the default.
hidepw - Omit the "HIDEPW:" comments in the log file.
[default: hidepw]
trace - Log all database operations to a trace file.
[default: notrace]
logging - Create indexes in LOGGING or NOLOGGING mode.
[default: nologging]
autoskip - To proceed with adpatch execution even if some
driver actions failed. Failed actions are
recorded in a log file.
[default: noautoskip]
Example - Skip apply failures:
adop phase=apply patches=123456 flags=autoskip
preinstall=(yes|no) [default: no]
Allows a patch to be applied to the file system without connecting
to the database. Do not use this parameter unless directed by Oracle.
wait_on_failed_job=(yes|no) [default: no]
Controls whether adop apply command exits when all workers have
failed. Instead of exiting, you can force adop to wait, and use
the "adctrl" to retry failed jobs.
printdebug=(yes|no) [default: no]
Controls whether to display additional debugging information.
uploadph=(yes|no) [default: yes]
Controls whether to upload patch history information to database after
applying the patch.
Finalize Parameters:
finalize_mode=(full|quick) [default: quick]
Quick mode will provide the shortest execution time, by
skipping non-essential actions.
Full mode performs additional actions such as gathering
statistics that may improve performance after cutover.
Example - Perform additional optimizations during Finalize:
adop phase=finalize finalize_mode=full
Using full mode after applying a major patch can help maintain
optimal system performance.
Cutover Parameters:
mtrestart=(yes|no) [default: yes]
Specifies whether to restart application tier servers after cutover.
Leave at default unless you need to perform any manual steps during
downtime.
Example - Perform downtime actions after cutover:
adop phase=cutover mtrestart=no
<Perform downtime steps>
adstrtal.sh
cm_wait=<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.
Example - cutover with maximum wait of 15 minutes:
adop phase=cutover cm_wait=15
Note that any concurrent requests killed during forced shutdown
may need to be manually re-submitted after cutover. To avoid
killing concurrent requests, schedule cutover at a time of
minimal user activity or manually shutdown Concurrent Manager
in advance of cutover.
Cleanup Parameters:
cleanup_mode=(full|standard|quick) [default: standard]
Quick mode provides the shortest execution time, by
skipping non-essential actions.
Standard mode performs additional processing to drop
obsolete code objects from old editions.
Full mode performs additional processing to drop empty
database editions and unused table columns.
Example - Run quick cleanup for minimum delay to next prepare:
adop phase=cleanup cleanup_mode=quick
Example - Run full cleanup for maximum space recovery:
adop phase=cleanup cleanup_mode=full
Special Operations:
Cloning the Patch Edition File System:
The patch edition file system is normally synchronized with the
run edition file system during the prepare phase. There are some
cases where it is helpful or required to manually re-clone the patch
edition file system from the run edition.
1) After aborting an online patching cycle.
2) After manually changing the run edition file system.
3) After patching middle-tier technology components.
4) After applying an EBS RUP.
By re-cloning the patch edition file system, you can be certain that
it is correctly synchronized, and also minimize any synchronization
delay that would normally occur on the next prepare command.
Example - Re-clone the patch edition file system:
adop phase=fs_clone
If there is any error you must examine log files and correct the
problem, then restart the fs_clone by running the command again.
If fs_clone does not restart correctly you can force the process
to restart from the beginning.
Example - Restart failed fs_clone from the beginning:
adop phase=fs_clone force=yes
You can specify the method used to synchronize the patch file system
with the run file system by setting the fs_clone_sync_mode parameter:
fs_clone_sync_mode=(cp|delta) [default:cp]
This parameter replaces sync_mode, which has been deprecated.
'delta' mode uses the file system synchronization command
specified in $APPL_TOP_NE/ad/admin/delta_sync_drv.txt.
'cp' mode creates the complete patch file system from run file system.
Example - fs_clone with new parameter fs_clone_sync_mode
adop phase=fs_clone fs_clone_sync_mode=cp
Aborting an online patching cycle:
If an online patching cycle encounters problems that cannot be
fixed immediately you can abort the patching cycle and return
to normal runtime operation.
Example - Aborting a failed online patching cycle:
adop phase=prepare
adop phase=apply patches=123456
### serious unfixable error reported
adop phase=abort
adop phase=cleanup cleanup_mode=full
adop phase=fs_clone
The abort command drops the database patch edition and
returns the system to normal runtime state. Immediately
following abort, you must also run a full cleanup and
fs_clone operation to fully remove effects of the failed
online patching cycle.
Dropping old database editions:
As online patching cycles are completed, the system will build
up a number of old database editions. When the number of old
database editions reaches about 25, you should consider running
a special maintenance operation to drop old database editions.
Example - Actualize_All and Full Cleanup:
adop phase=prepare
adop phase=actualize_all
adop phase=finalize
adop phase=cutover
adop phase=cleanup cleanup_mode=full
Warning: This maintenance operation will take much longer than a
typical online patching cycle, and should only be performed when
there is no immediate need to start a new online patching cycle.
The actualize all and full cleanup can be done separately as shown
above, or can be executed in conjunction with an online patching
cycle.
Example - Actualize_All and Full Cleanup combined with patching:
adop phase=prepare
adop phase=apply patches=123456
adop phase=actualize_all
adop phase=finalize
adop phase=cutover
adop phase=cleanup cleanup_mode=full
adop exiting with status = 0 (Success)
