| Oracle® Fusion Applications Patching Guide 11g Release 6 (11.1.6) Part Number E16602-16 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Patching Guide 11g Release 6 (11.1.6) Part Number E16602-16 |
|
|
PDF · Mobi · ePub |
This chapter describes how to apply patches to update Oracle Fusion Middleware Extensions for Applications (Applications Core).
This chapter contains the following topics:
The same set of patching related software and database tables is used by both Oracle Fusion Applications Patch Manager and Oracle Fusion Middleware Extensions for Applications (Applications Core). Oracle Fusion Applications Patch Manager and Applications Core each have their own separate Oracle home. Product specific shell scripts used for database patching exist in each corresponding Oracle home location. The separate scripts are provided in order to support each product's individual patching requirements. The scripts are uniquely defined to reference the appropriate Oracle home, set the patching configuration and environment, and then call the appropriate utility for patching.
Oracle Fusion Applications Patch Manager automatically calls Oracle Fusion Applications AutoPatch (AutoPatch) when it detects patch metadata that indicates a patch contains database content. However, you run AutoPatch directly to apply an applications database patch for Applications Core.
Oracle Fusion Applications AutoPatch is used to apply patches that contain fixes or updates to applications database artifacts. It gathers the necessary information about the applications system and performs the following tasks required to apply a patch:
Reads patch metadata to determine patch dependencies and requirements
Uploads patch information from a prior patch session to the database (if needed)
Reads and validates the patch driver file
Compares version numbers of object modules from the product libraries and version numbers of the existing files against the patch files
Backs up all existing files that will be changed by the patch
Copies files
Updates database objects
Saves patch information to the database
Takes no action if a patch contains no new updates to files or database objects in your system
Detects if there is a previously failed Oracle Fusion Applications AutoPatch session and attempts to recover that session
Table 6-1 lists the types of artifacts that are supported by Oracle Fusion Applications AutoPatch.
Table 6-1 Database Artifacts Supported by Oracle Fusion Applications AutoPatch
| Artifact Type | Description | Patching Recommendations |
|---|---|---|
|
Applications Seed Data (XML,XLF files) |
Examples include static lists of values, functional or error messages, and lookup values. Any non-transactional data values loaded into your database can be considered seed data. |
Oracle recommends that patches containing seed data be applied from a machine that is co-located in the same subnetwork as the database server to maximize performance. |
|
Applications Database schema changes (SXML files) |
Examples include tables, triggers, views, sequences, synonyms, queues, queue tables, policies, and contexts. |
None |
|
PL/SQL objects (PDQ, PCB files) |
Package headers and bodies. |
Manually shut down the Oracle Enterprise Scheduler Service servers before applying patches that contain PL/SQL changes. |
|
SQL scripts |
Scripts that update the database. |
None |
You run Oracle Fusion Applications AutoPatch by using the command line utility, adpatch, located in the ATGPF_ORACLE_HOME/lcm/ad/bin directory. This is the directory under MW_HOME that contains the Applications Core code. The utility's shell script sets the environment for ATGPF_ORACLE_HOME and calls the utility. For UNIX, the shell script is adpatch.sh and for Windows, it is adpatch.exe. You direct the way adpatch operates by adding arguments and options to the command. Command line arguments use the token=value format.
The following command shows the basic syntax for the adpatch utility:
(UNIX) ATGPF_ORACLE_HOME/lcm/ad/bin/adpatch.sh patchtop=complete_path_to_unzipped_patch_directory \ driver=driver_name workers=number_of_workers [optional arguments=value] (Windows) ATGPF_ORACLE_HOME\lcm\bin\adpatch.exe patchtop=complete_path_to_unzipped_patch_directory \ driver=driver_name workers=number_of_workers [optional arguments=value]
Table 6-2 displays the arguments used by Oracle Fusion Applications AutoPatch:
Table 6-2 Arguments Used by Oracle Fusion Applications AutoPatch
| Argument | Description | Mandatory | Default Value | Example |
|---|---|---|---|---|
|
abandon |
Abandons a failed patching session |
No |
n for no |
abandon=y |
|
apply |
Applies the patch |
No |
y for yes |
apply=n |
|
backup |
Allows you to override the backup directory for files that are copied |
No |
|
backup= |
|
defaults file |
File delivered by Oracle that contains the environment information required to apply a patch |
Recommended |
None |
defaultsfile=ATGPF_ORACLE_HOME/admin/TWO_TASK/defaults.txt |
|
driver |
Name of the patch driver file |
Yes |
None |
driver=upatch_number.drv |
|
help |
Accesses help for adpatch |
No |
n for no |
help=y |
|
interactive |
Allows you to apply a patch non-interactively using information from the defaults file |
Yes |
y for yes |
interactive=n |
|
logfile |
Name for log file |
No |
adpatch_apply.log |
logfile=adpatch_apply_patch_number.log |
|
loglevel |
Records messages in the log file at the level you specify. Enter a value to override the default log level of |
No |
NOTIFICATION:16 |
loglevel=WARNING |
|
logtop |
Top level directory where log files are written |
No |
|
logtop=/tmp/admin/log |
|
max_trial_time |
The maximum time in minutes that deferred tasks are attempted |
No |
10 minutes |
max_trial_time=5 |
|
parallel_index_threshold |
Threshold block count in each table, which when exceeded for a tables, causes its indexes to be created using parallel slaves |
No |
10000 |
parallel_index_threshold=12000 |
|
patchtop |
Top level directory for the unzipped patch |
Yes |
None |
patchtop=/temp/patches/patch_number |
|
printdebug |
Displays additional debug information |
No |
n for no |
printdebug=y |
|
restart |
Resumes a failed patching session |
No |
None |
restart=y |
|
wait_on_failed_job |
Waits for user intervention when all tasks fail. If set to no, AutoPatch exits when all tasks assigned to workers have failed and require user intervention. |
Recommended |
n for no |
wait_on_failed_job=y |
|
workers |
Number of workers to use for database patching tasks |
Yes |
None |
workers=8 |
To access help for the adpatch command, type adpatch help=y. The output of the help argument provides a list of the options you can use to refine the operation of adpatch, along with a brief description of each option.
Oracle Fusion Applications AutoPatch should be run non-interactively from the command line by using the defaults.txt file that contains the information required to apply the patch. During the installation and configuration for Applications Core, the defaults.txt file is created in this location: ATGPF_ORACLE_HOME/admin/TWO_TASK/defaults.txt. Note that TWO_TASK is the name of the database to which you are applying the patch.
The end-to-end process of applying individual patches using AutoPatch, includes the following steps.
Note:
As part of the patching process, customers have their own backup and recovery management process. Oracle recommends that you always have a current backup before applying a patch.
Note:
There can be only one patching session active for Oracle Fusion Applications and Applications Core at a time.
When you have an issue that needs to be resolved by a patch for Applications Core, file a service request with Oracle Support Services or research the issue on My Oracle Support:
Upon determining that you need new patches, download the patches from My Oracle Support. Unzip the patch ZIP files in your PATCH_TOP directory. PATCH_TOP can be any location in your file system.
Read the README file that accompanies each patch. This file contains important information and instructions that must be followed.
If a patch contains preinstallation or postinstallation manual steps, they are described in the patch README file.
To prevent locks on patched objects and other data issues during patching of database artifacts, review and perform the following checklist before patching the target database system:
Confirm that the database system is in an idle state
Confirm that there are no active jobs or processes running against the database
Stop all background jobs, including jobs in the database and active processes
Manually shut down the Oracle Enterprise Scheduler Service (ESS) servers, especially when a patch contains a PL/SQL package, by performing the following steps:
Stop the ESS request processor and dispatcher to prevent new requests from being processed. See "Starting and Stopping a Request Processor or Dispatcher" in the Oracle Fusion Applications Administrator's Guide for more information.
Cancel any in-progress requests. For more information, see "Cancelling Oracle Enterprise Scheduling Service Job Requests" in the Oracle Fusion Middleware Administrator's Guide for Oracle Enterprise Scheduler for more information.
Shutdown the ESS WebLogic Server Managed server. See the "Starting and Stopping" table, specifically the "Managed Servers for the Oracle Fusion applications and Oracle Fusion Middleware components" row, in the Oracle Fusion Applications Administrator's Guide for more information.
If any prerequisite patches are required, as described in the README file, apply those patches with Oracle Fusion Applications AutoPatch.
Identify the Applications Core Oracle home (ATGPF_ORACLE_HOME). This is the directory under MW_HOME that contains the Applications Core code.
Apply the patch using the adpatch command. An example of the adpatch command follows:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/adpatch.sh defaultsfile=ATGPF_ORACLE_HOME/admin/TWO_TASK/defaults.txt \ patchtop=complete_path_to_unzipped_patch driver=upatch_number.drv \ workers=number_of_database_workers interactive=no [logfile=log_file_name]\ [logtop=ATGPF_ORACLE_HOME/admin/FUSION] [loglevel=level] wait_on_failed_job=yes (Windows) FA_ORACLE_HOME\lcm\ad\bin\adpatch.exe defaultsfile=ATGPF_ORACLE_HOME\admin\TWO_TASK\defaults.txt \ patchtop=complete_path_to_unzipped_patch driver=upatch_number.drv \ workers=number_of_database_workers interactive=no [-ogfile=log_file_name]\ [logtop=ATGPF_ORACLE_HOME\admin\FUSION] [loglevel=level] wait_on_failed_job=yes
You can monitor the progress of the patching session and verify its successful completion by using the AD Controller utility. For more information, see Section 6.4, "Monitoring and Troubleshooting Applications Core Patching Sessions".
Review the log files when the patch session is complete. For more information, see Section 6.3, "Log Files".
If any postinstallation patches are required, as indicated in the README file, apply them. Run any manual steps that are described in the README file.
You use the OPatch utility to patch Applications Core middleware artifacts. All patches are available for download from My Oracle Support.
To patch Applications Core middleware artifacts
Identify the Applications Core Oracle home (ATGPF_ORACLE_HOME). This is the directory under MW_HOME that contains the Applications Core code.
Set the ORACLE_HOME to ATGPF_ORACLE_HOME.
Example:
setenv ORACLE_HOME /server01/mwhome/Oracle_atgpf
Or:
export ORACLE_HOME=/server01/mwhome/Oracle_atgpf
Create a temporary directory to stage the Applications Core patches.
mkdir Temp_Directory
Unzip the OPatch patches in the temporary directory.
Review the README.txt file for information about any preinstallation and postinstallation steps.
Apply the patches using OPatch:
cd patch_top_directory ORACLE_HOME/OPatch/opatch apply -invPtrLoc ORACLE_HOME/oraInst.loc
For more information about OPatch, see "Patching Oracle Fusion Middleware with Oracle OPatch" in the Oracle Fusion Middleware Patching Guide.
Stop and start the WebLogic server. For more information, see "Starting and Stopping a Product Family Oracle WebLogic Server Domain" in the Oracle Fusion Applications Administrator's Guide.
Stop and start the Administration Server and all Managed Servers. For more information, see "Starting and Stopping" in the Oracle Fusion Applications Administrator's Guide.
Run the postinstallation steps, if applicable.
Apply the 'Deployment of Fusion APPS Attachments in UCM server OPatch' patch to your ECM_ORACLE_HOME. Follow the same instructions in Steps 1 through 9 to apply this patch.
MAR artifacts that contain Global Menus are delivered in Applications Core OPatch patches and copied to this location when you apply the patch using OPatch:.
ATGPF_ORACLE_HOME/atgpf/applications/exploded/FndSetup.ear/FndAppsMenuData.mar
After you apply the patch with OPatch, you must copy this MAR artifact to a specific location in FA_ORACLE_HOME and start the corresponding Managed Server. Use the following example syntax to copy the file:
cp ATGPF_ORACLE_HOME/atgpf/applications/exploded/FndSetup.ear/FndAppsMenuData.mar FA_ORACLE_HOME/fusionapps/applications/fs/deploy/FndSetup.ear
Extensible flexfields require synchronization between the Service Oriented Architecture (SOA) Metadata Service (MDS) and Oracle Fusion Applications MDS, which is delivered in the sca_UpdateSOAMDS_rev_number.jar file. When updates to this jar are delivered in a patch, you must manually deploy the SOA composite after you apply the patch using OPatch. To deploy the SOA composite, log in to Oracle Fusion Applications Control as the WebLogic user, navigate to SOAServer and select Deploy. For more information, see "Starting Fusion Applications Control" in the Oracle Fusion Applications Administrator's Guide.
Oracle Fusion Applications AutoPatch creates log files in the ATGPF_ORACLE_HOME/admin/FUSION directory. You specify the name of the main log file by using the logfile argument when you run Oracle Fusion Applications AutoPatch. The related log files are named based on the name of the main log file. For example, if the name of the main log file is adpatch_123456_apply.log, then the worker logs for the session are named adpatch_123456_apply_worker_worker_number.log.
Table 6-3 displays the Oracle Fusion Applications AutoPatch log files.
Table 6-3 Log Files for Oracle Fusion Applications AutoPatch
| Log file name | Log file description |
|---|---|
|
adpatch.log |
Main log file; Oracle recommends you override the default name by including the patch number in the name of the log file. |
|
adpatch.lgi |
Contains informational messages. |
|
adlibin.log |
Contains information about moving C object files into the C library. |
|
adlibout.log |
Contains information about moving C object files out of the C library. |
|
adpatch_workerworkernumber.log |
Worker log files for database tasks that run in parallel. |
|
language_filename_ldt.log |
Seed data loader files. |
The AD Controller utility, adctrl, can monitor, determine the status, and control the progress of the workers called by AutoPatch to update database content. For more information about workers, see Section 3.1.2.1, "Worker Processes".
The AD Controller utility can monitor database patching sessions that were started by both Oracle Fusion Applications AutoPatch and Oracle Fusion Applications Patch Manager. To start adctrl to monitor Applications Core patching sessions, make sure you start the session in ATGPF_ORACLE_HOME.
The following sections offer steps for troubleshooting issues that may occur during patching sessions for database content.
Follow these steps to start AD Controller:
Start AD Controller with the adctrl command.
(UNIX) FA_ORACLE_HOME/fusionapps/atgpf/lcm/ad/bin/adctrl.sh (Windows) FA_ORACLE_HOME\fusionapps\atgpf\lcm\ad\bin\adctrl.cmd
It prompts you to:
Confirm the value of the Applications Core Oracle home
Specify an AD Controller log file. This log file is written to the current working directory. The default is adctrl.log.
After the main menu displays, enter a number to select an option. You can press Enter at any time to return to the AD Controller main menu.
When AutoPatch or AD Administration runs tasks in parallel, it assigns tasks to workers for completion. There may be situations that cause a worker to stop processing. You can use AD Controller to determine the status of workers and manage worker actions.
Follow these steps to review the status of the workers from AD Controller:
Start AD Controller. For more information, see Section 6.4.1, "Starting AD Controller".
Review worker status.
Select Show worker status from the AD Controller main menu. AD Controller displays a summary of current worker activity. The summary columns are:
Control Worker: The worker number
Code: The last instruction from the manager to the worker
Context: The general action the manager is executing
Filename: The file the worker is running, if any
Status: The status of the worker
Table 6-4 describes the status that may be assigned to a worker.
Table 6-4 Worker Status
| Status | Meaning |
|---|---|
|
Assigned |
The manager assigned a task to the worker and the worker has not yet started. |
|
Completed |
The worker completed the task and the manager has not yet assigned it a new task. |
|
Failed |
The worker encountered a problem. |
|
Fixed, Restart |
You fixed the problem, and the worker will retry the task that failed. |
|
Restarted |
The worker is retrying a task or has successfully restarted a task. Note that the status does not change to Running. |
|
Running |
The worker is running a task. |
|
Wait |
The worker is idle. |
If the worker shows a status of Failed, refer to Section 6.4.3, "Determining Why a Worker Failed" for assistance in fixing the problem so AutoPatch can complete its processing.
When a worker fails its task, you do not have to wait until the other workers and the manager stop. You can review the worker log files to determine what caused the failure. Workers do not proceed to run tasks in the subsequent phase until all tasks in the current phase complete successfully. You must take action to resolve the failure so the workers can continue to run tasks in the next phase. If the task was deferred after the worker failed, there may be no action required from you.
The first time a task fails, the manager defers the task and assigns the worker a new task. If the deferred task fails a second time, the manager defers it a second time only if the runtime of the task is less than 10 minutes. If the deferred task failed a third time, or if its runtime is greater than 10 minutes, the task stays at a failed status and the worker waits for manual intervention. Action by you is then required because the worker stops any further processing.
Follow these steps to find out why a worker failed:
Follow the steps in Section 6.4.2, "Reviewing Worker Status" to find the worker number that failed.
Open and review the log file for the failed worker to determine the cause of the worker failure.
Each worker logs the progress of tasks assigned to it in adpatch_workerworkernumber.log. The worker log file contains information that describes exactly what task it was running and what error occurred that resulted in a failure. Review the worker log file for the failed worker to determine the source of the error. For more information, see Section 6.3, "Log Files".
Determine how to fix the problem that caused the failure.
Resolve the error using the information provided in the log files. Search for the resolution at the My Oracle Support site or file a service request with Oracle Support Services if you do not understand how to resolve the issue.
After you resolve the problem that caused the failure, restart the failed worker.
Select Tell worker to restart a failed job from the AD Controller main menu to tell the worker to restart the failed task. For more information, see Section 6.4.4, "Restarting a Failed Worker".
Verify the worker status.
Select Show worker status from the AD Controller main menu. The Status column for the worker that failed should now display Restarted or Fixed, Restart.
If a worker job failed or if you terminated a hanging worker process, you must manually restart the worker. Some worker processes spawn other processes called child processes. If you terminate a child process that is hung, the worker that spawned the process shows Failed as the status. After you fix the problem, you must restart the failed worker. After the worker restarts, the associated child processes start as well.
Follow these steps to restart a failed worker:
Start AD Controller. For more information, see Section 6.4.1, "Starting AD Controller".
Select Show worker status from the AD Controller main menu.
Take the appropriate action for each worker status:
If the worker status is Failed and its job has failed, select Tell worker to restart a failed job. When prompted, enter the number of the worker that failed.
If the worker status is Running or Restarted, but the job is hung, follow the steps in Section 10.5.5, "Terminating a Hung Worker Process".
The worker will restart its assigned tasks and spawn the associated child processes.
If your patch session failed, you can restart the session after you resolve the issue that caused the failure. Use the restart argument, as shown in the following example:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/adpatch.sh defaultsfile=ATGPF_ORACLE_HOME/admin/TWO_TASK/defaults.txt \ patchtop=/mypatches/1213456 driver=u123456.drv workers=8 \ interactive=n logfile=adpatch_apply_123456.log loglevel=WARNING]\ logtop=ATGPF_ORACLE_HOME/admin/FUSION wait_on_failed_job=y restart=y (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd defaultsfile=ATGPF_ORACLE_HOME\admin/TWO_TASK\defaults.txt \ patchtop=\mypatches\123456 driver=u123456.drv workers=8 \ interactive=no logfile=adpatch_apply_123456.log loglevel=WARNING \ logtop=ATGPF_ORACLE_HOME\admin\FUSION wait_on_failed_job=yrestart=y
If your patch session failed and you do not want to restart it, you must abandon the session to update the database tables, allowing you to start a new patch session. Use the abandon argument, as shown in the following example:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/adpatch.sh defaultsfile=ATGPF_ORACLE_HOME/admin/TWO_TASK/defaults.txt \ patchtop=/mypatches/1213456 driver=u123456.drv \ interactive=no logfile=adpatch_abandon_123456.log loglevel=WARNING\ logtop=ATGPF_ORACLE_HOME/admin/FUSION abandon=y (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd defaultsfile=ATGPF_ORACLE_HOME\admin/TWO_TASK\defaults.txt \ patchtop=/mypatches/1213456 driver=u123456.drv \ interactive=no logfile=adpatch_abandon_123456.log loglevel=WARNING\ logtop=ATGPF_ORACLE_HOME\admin\FUSION abandon=y
Note:
There can be only one patching session active for Oracle Fusion Applications and Oracle Middleware Extensions for Applications at a time. If there is a failed Oracle Fusion Applications Patch Manager session, see Section 10.3.2, "Abandoning a Failed Patching Session".
You must apply Applications Core patches to the correct Oracle home. For example, if you try to apply an Applications Core patch to the Oracle Fusion Applications Oracle home, you receive this error message:
Error: Incompatible Patch. Cannot apply ATGPF patch on FA_ORACLE_HOME
To resolve this issue, ensure that you are applying the patch to ATGPF_ORACLE_HOME.
AD Administration is a standalone utility that performs administration maintenance tasks for the products in your Applications Core Oracle home. The general purpose of the maintenance tasks is to keep your Applications Core files and database objects up-to-date. Some maintenance tasks should be performed systemwide on a regular basis, while others are required infrequently.
Run AD Administration by using the command-line utility, adadmin. This utility has a shell script that sets the environment and calls the utility. For UNIX, the shell script is adadmin.sh and for Windows it is adadmin.cmd. To run AD Administration for Applications Core, use this command syntax:
(UNIX) FA_ORACLE_HOME/fusionapps/atgpf/lcm/ad/bin/adadmin.sh [argument] (Windows) FA_ORACLE_HOME\fusionapps\atgpf\lcm\ad\bin\adadmin.cmd [argument]
Refer to Chapter 9, "Performing System Maintenance Tasks" for how to use AD Administration. This chapter describes using AD Administration for both Applications Core and Oracle Fusion Applications Patch Manager. The only difference is the location of the command you use to start AD Administration.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|