Oracle EBS 12.2 ADOP(AD Online Patching) Utility

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