Oracle Applications R12.2 patching
Application patching Introduction
There are various phases for Online patching.
adop phase=prepare
adop phase=apply
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 of adop can be executed in a single line command. Example of combined finalize/cutover/cleanup:
adop phase=finalize,cutover,cleanup
Prior to cutover, it is possible to execute additional “apply” and “finalize” phases as needed.
source <ebs_root>/EBSapps.env run
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.
ADOP Apply Phase
The phase has below specific 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.
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.
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.
apply_mode=(online|downtime|hotpatch) [default: online]
It is used to specify how the patch will be applied. There 3 option can be explained as below:
online – It will apply a patch to the patch edition during an online patching cycle.
downtime – It will apply a patch to the run edition when application services are down. When using this mode, you only run the apply phase.
hotpatch – apply a patch to the run edition when application services are up. When using this mode, you only run the apply phase
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 patching does not use an online patching cycle and hence if there is an online patching cycle in progress. The process of applying a patch in downtime mode completes more quickly than in online mode, but at the cost of increased system downtime.
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.
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.
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. 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 blog.
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 [default: checkfile] – Skip running exec, SQL, and exectier commands if they are recorded as already run.
compiledb [default: compiledb] – Compile invalid objects in the database after running actions in the database driver.
compilejsp [default: compilejsp] – Compile out-of-date JSP files, if the patch has copy actions for at least one JSP file.
copyportion [default: copyportion] – Run commands found in a copy driver.
databaseportion [default: databaseportion] – Run commands found in a database driver.
generateportion [default: generateportion] – Run commands found in a generate driver.
integrity [default: nointegrity] – Perform patch integrity checking
autoconfig [default: autoconfig] – Run AutoConfig.
actiondetails [default: actiondetails] – Turn off display of action details.
parallel [default: parallel] – Run actions that update the database or actions that generate files in parallel.
prereq [default: noprereq] – Perform prerequisite patch checking prior to running patch driver files.
validate [default: novalidate] – Connect to all registered Oracle E-Business Suite schemas at the start of patch application.
phtofile [default: nophtofile] – Save patch history to file
forceapply [default: noforceapply] – Reapply a patch that has already been applied. Useful in combination with “nocheckfile” option to rerun files that 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 [default: hidepw] – Omit the “HIDEPW:” comments in the log file.
trace [default: notrace] – Log all database operations to a trace file.
logging [default: nologging] – Create indexes in LOGGING or NOLOGGING mode.
autoskip [default: noautoskip] – To proceed with adpatch execution even if some driver actions failed. Failed actions are recorded in a log file.
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.
ADOP Finalize Phase
Finalize Phase is performed to keep the system ready for Cutover phase. This phase perform various activities like:
1. Compiling Invalid Objects
2. Generating driverd objects
3. Pre-compute DDL to be run during Cutover
Finalize Phase have below specific 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.
ADOP Cutover Phase
Cutover phase perform below activities:
1. Bring down Application services
2. Promote Patch File System to the Run File System.
3. Promote Patch Database Edition to the Run Database Edition.
4. Perform Maintenance task
5. Bring up application services
Cutover Phase have below specific 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.
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.
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.
ADOP Cleanup Phase
This phase will cleanup the Application and Database for the next Patching Cycle.
Cleanup phase specific parameters are:
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.
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. Aborting an online patching cycle can be issue as below:
adop phase=abort
Note that once you are done with Cutover phase, you can abort ADOP Cycle.
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.
2 Apply Patching
2.1 Prepare Apps Tier
Prepare the application tier for patching
1. Log on to the primary node of the source system as the application user
2. Source the environment file of the Run Edition File system.
You can use the following command to confirm that the environment variable $ echo $FILE_EDITION It should return the value: run Execute the following commands: $su – appl<sid> Review the patch and download it from oracle support site Patch directory is $PATCH_TOP Based on a patch decide the patching method
online
$adop phase=prepare$adop phase=apply patches=123456,1234,12244 $adop phase=apply patches=123456,1234,12244 $adop phase=finalize Shutdown Concurrent Manager in before cutover (both internal and external) $adop phase=cutover $source <ebs_root>/EBSapps.env run (ebs root - /u01/app/oracle/<sid>) $adop phase=cleanup
hotpatch patching
$adop phase=apply patches=123456,1234,12244 patchtop=/u03/patches hotpatch=yes Note: Apply hot patch only if Oracle recommends
Dowmtime patching
$adop phase=apply patches=123456,1234,12244 patchtop=/u03/patches apply_mode=downtime For options please review appendix
2.2 Validate the patch
Login application or Database tier and execute SQLPLUS using Apps user ID
SQL> select * from ad_bugs where BUG_NUMBER=’patch number’;
2.3 Log file location
Login application tier using application user id
$cd $NE_BASE/EBSapps/log/adop/<adop_session_id>/<phase>_<date>_<time>/<context_name>/log
