You use the adop
(AD Online Patching) utility to apply patches to the Oracle E-Business Suite
file
system or database. |
You can either allow adop to prompt for
the information required to apply a patch, or enter the
information without
being prompted. |
| Whichever method you choose, adop will
then perform the tasks required to apply the patch: |
|
most parameters can be defined
in at least two locations, with patchtop able to be defined in three
different locations. If multiple different definitions are specified, the
following order is used. |
| Command Line: An adop parameter specified
on the command line will take precedence over all others. |
Input File: An adop parameter given here
will only be lower in precedence to a parameter specified on
the command
line. |
| Defaults File: Parameters defined here
have the lowest level of precedence. |
|
|
| Patch Log Files |
It is advisable to review the relevant
log files after any patching operation. The adop log files are
located on the
non-editioned file system (fs_ne), under: |
| $NE_BASE/EBSapps/log/adop/<adop_session_id>/<phase>_<date>_<time>/<context_name>/log |
For example, if s_ne_base was
/u01/R122_EBS/fs_ne, the session ID was 15,
and the <CONTEXT_NAME> was
patch01_testsys, the path to the adop log files from 9th July 2014
would
resemble this: |
| /u01/R122_EBS/fs_ne/EBSapps/log/adop/15/apply_20140709_112226/patch01_testsys/log |
|
| adop Patching Modes |
| The adop utility is normally used to
apply patches in an online patching cycle. It can also be used: |
To run a patching cycle, and test patch
application without actually taking any apply actions,
in test mode |
| To apply patches outside a patching cycle
in downtime mode |
| To apply patches without connecting to
the database in preinstall mode |
|
|
|
| Test Mode |
In test mode, adop does not apply the
patch. Instead, it lists each file it would have copied, relinked,
executed,
or generated, and shows exactly what actions it would have performed had it
applied the
patch. It also runs AutoConfig in test mode to determine any
impending changes to the configuration
files. This allows you to see the
effects of a patch on your system before you apply it. |
| To run adop in test mode, add the
apply=no parameter to the adop command you would use if you were actually
going to apply the patch. In test mode, adop will go through the process of
applying the patch but will not perform any of the following actions: |
| Copy files from the patch directory to
the Oracle E-Business Suite file system |
| Archive object modules into the product
libraries |
| Relink executables |
| Generate forms, reports, PL/SQL
libraries, or menu files |
| Run SQL or EXEC commands (commands that
change the database) |
| Instantiate new configuration files |
| Update the patch information files |
| Update patch information and release
version in the database |
|
| Downtime Mode |
To optimize the process of upgrading to
Oracle E-Business Suite Release 12.2, support is provided for
the capability
to apply Oracle E-Business Suite patches in downtime mode. |
| When applying patches in this mode, adop
will first confirm that the application tier services are down, |
and will then proceed to apply the patch
to the run edition of the Oracle E-Business Suite database and
file
system. |
Downtime mode patching does not use an
online patching cycle. The process of applying a patch in
downtime mode
completes more quickly than in online mode, |
| but at the cost of increased system
downtime. |
To run adop in downtime mode, you use the
following command line options. In this example,
patch 123456 is applied in
downtime mode: |
| $ adop phase=apply patches=123456
apply_mode=downtime |
| Important: Be aware that: |
| Release 12.2 patches are not normally
tested in downtime mode. |
Downtime mode is only supported for
production use where explicitly documented, or when directed
by Oracle
Support or Development. |
|
| Preinstall Mode |
Preinstall mode is generally used during
the upgrade process to update AD utilities, apply pre-upgrade
patches, or
work around other patching issues. |
| adop asks all startup questions except
those relating to the database. |
| Important: Run adop in preinstall mode
only if the patch readme instructs you to do so. |
To run adop in preinstall mode, include
preinstall=y on the adop command line. It performs the
following actions: |
| Compares version numbers |
| Copies files |
| Relinks FND and AD executables |
| Saves patch information to the file
system |
Because adop does not read driver files
in preinstall mode, it copies all product files in the patch to the
APPL_TOP
directory. |
Additionally, even if a file in the patch
should be both in the APPL_TOP and in another directory
(such as in
$OA_HTML), adop copies the file only to the APPL_TOP. |
In preinstall mode, adop validates
codelevels against the files Preinstall_Codelevel_AD.txt and
Preinstall_Codelevel_MP.txt. |
These files are located in the
$APPL_TOP/admin directory, and contain codelevel information about
AD and
other products registered in the database tables. |
| Since no database connection is available
in preinstall mode, |
adop tries to validate whether the
current patch should be applied based on the codelevel information
in these
two files, as follows: |
If Preinstall_Codelevel_AD.txt is missing
from the APPL_TOP, adop will apply the patch in preinstall
mode without
validating the patch for codelevel compatibility. |
If Preinstall_Codelevel_MP.txt is missing
from the APPL_TOP, adop will proceed with patch
application without
validating the patch for codelevel compatibility of the entities. |
| If both files are missing, adop will not
validate codelevels in preinstall mode. |
| Note the following restrictions when
applying a patch in preinstall mode: |
| NLS patches cannot be applied on the
instance. |
| Baseline or codelevel-introducing patches
cannot be applied on the instance. |
| adop will not check to see if the patch
is already applied on the system. |
|
|
|
| Running adop |
The following is a summary of the steps
you use to run adop. For a complete procedural description
of all the steps,
see Creating Customized Instructions for Patching Using PAA. |
|
| Step 1: Set the environment |
You must set the environment to apply the
configuration parameters that define your system. This task
is common to many
AD utilities, and is performed using the following command: |
| $ . <EBS_ROOT>/EBSapps.env run |
<EBS_ROOT> represents the Oracle
E-Business Suite base install directory, such as /u01/oracle.
There is no
associated environment variable. |
| Note: The EBSapps.env file is provided by
the AD-TXK release update packs. |
|
| Step 2: Unzip the patch |
Download and unzip the patch into the
patch top directory, which is identified by the $PATCH_TOP
environment
variable. |
|
| Step 3: Review the information in the
readme file |
In the directory where you unzipped the
patch, you will find a README.txt file and a README.html
file. |
Review either readme file for information
about the patch and for instructions on using Oracle Patch
Application
Assistant (PAA) to generate customized instructions for your system. |
|
| Step 4: Run Oracle Patch Application
Assistant |
Run PAA (admsi.pl) to generate customized
instructions for your system. Follow the steps in the
customized instructions
to start the patching process. |
|
| Step 5: Run adop |
| The customized instructions generated by
PAA describe how to run adop using the adop command. |
Note: You can add arguments on the
command line to refine the way adop runs. See adop Modes and
Command Line
Arguments. |
A simple example of the commands to
execute a complete online patching cycle for patch 123456 is
as follows: |
| $ . <EBS_ROOT>/EBSapps.env run |
| $ adop phase=prepare |
| $ adop phase=apply patches=123456 |
| $ adop phase=finalize |
| $ adop phase=cutover |
| $ . <EBS_ROOT>/EBSapps.env run |
| $ adop phase=cleanup |
|
| Monitoring Status |
| You can obtain a brief report for the
current patching session by running the command: |
| $ adop -status |
| If you want information about a
particular session, specify the relevant session ID: |
| $ adop -status <session ID> |
| If you want additional details of
operations performed: |
| $ adop -status -detail |
This option will give a summary of last
ten adop session IDs, and full details of the file system and
database
changes introduced by a patch. |
| It also shows the log file location of
the current patching cycle. |
|
| Aborting an Online Patching
Cycle |
If a patching cycle is failing and the
issue cannot be resolved quickly, it is possible to abort the
patching cycle
and return to normal runtime operation. |
| The patch edition will be dropped. |
| You can abandon a patching cycle (without
applying any patches) by running the command: |
| $ adop phase=abort |
Important: This abort command can only be
used before successful completion of the cutover phase.
After cutover, the
system is running on the new edition, |
| and abort is no longer possible for that
patching cycle. |
Aborting a patching cycle will drop the
patch edition, but you must then run the cleanup and
fs_clone phases before
starting a new patching cycle. The cleanup must be a full cleanup. |
|
| For example: |
| $ adop phase=prepare |
| $ adop phase=apply patches=123456 |
| [Patch application encounters problems
and you want to abort] |
| $ adop phase=abort |
| $ adop phase=cleanup cleanup_mode=full |
| $ adop phase=fs_clone |
| Optionally, you can combine the abort and
cleanup commands as follows: |
|
| $ $ adop phase=abort,cleanup
cleanup_mode=full |
Note: You cannot abort application of a
patch applied in hotpatch mode
(adop phase=apply apply_mode=hotpatch). |
|
|
| End of ADOP Utility -Concept |
