| 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 use the features of Oracle Fusion Applications Patch Manager.
This chapter contains the following topics:
The primary function of Oracle Fusion Applications Patch Manager (Patch Manager) is to apply standard and one-off patches. It can also validate whether patches can be applied and generate patching reports.
Patch Manager provides a command-line interface to coordinate its patching functions. A single patch may include changes to both Oracle Fusion Middleware and database artifacts, and these Oracle Fusion Middleware artifacts may be deployed to Managed Servers running on different nodes. The artifacts are updated in the Oracle Fusion Applications Oracle home that is shared by the different nodes. To patch both types of artifacts, two patching tools are called by Patch Manager to manage the actions involved: OPatch for the Oracle Fusion Middleware artifacts and Oracle Fusion Applications AutoPatch (AutoPatch) for artifacts associated with the database. Both AutoPatch and OPatch have long been used as the standard patching tools in previous releases of Oracle products.
The same set of patching-related software and database tables is used by both Patch Manager and Oracle Fusion Middleware Extensions for Applications (Applications Core). Patch Manager and Applications Core each reside in their own separate Oracle home and use their specific shell scripts to support their product-specific patching requirements. These scripts are uniquely defined to reference the appropriate Oracle home, set the patching configuration and environment, and then call the AutoPatch utility for database patching. There can be only one patching session active for Oracle Fusion Applications or Applications Core at a time.
For more information about patching Applications Core, see Chapter 6, "Patching Oracle Fusion Middleware Extensions for Applications".
The following topics provide additional information about Patch Manager:
Patch Manager examines patch metadata and determines which actions must be performed by OPatch and which must be performed by AutoPatch. If Patch Manager discovers that a patch contains only database changes, it assigns the patch directly to AutoPatch for processing. If the patch is related only to Oracle Fusion Middleware changes, Patch Manager orchestrates the application of the changes across domains and the Oracle home. If the patch contains both database and Oracle Fusion Middleware changes, Patch Manager coordinates the application of both changes, applying database changes first, followed by Oracle Fusion Middleware changes. You apply the patch in a single operation, regardless of the type of artifacts that are updated.
Figure 3-1 illustrates the patching process coordinated by Patch Manager.
Example of Patch Coordination
The following high-level phases occur when you apply a patch in online mode that contains an Oracle Application Development Framework (Oracle ADF) library and a seed data file for a product family:
Patch Manager interprets the contents of the patch by reading the patch metadata.
AutoPatch updates the seed data.
OPatch applies the change to the Oracle ADF library in the form of a JAR file.
Patch Manager coordinates with OPatch and forces an immediate shutdown and restart of the impacted Managed Servers so the change to the Oracle ADF library takes effect.
Patch Manager consolidates and provides results and status for the overall patching tasks in the Log Summary and the Diagnostics report.
When a patch contains updates to database artifacts, such as application seed data, the database schema, PL/SQL objects, and SQL scripts, Patch Manager calls AutoPatch to coordinate the following tasks:
Worker calculation: Calculates the default number of workers that should be used. If patching is run on the same machine as the database server, the default number of workers is calculated as 0.5 times the number of VCPUs on the database server. If patching is run on a machine different from the database server on a Linux platform, the default number of workers is calculated as the minimum of the VCPUs available on the database server and the patching machine. On non-Linux platforms, the default number of workers is equal to the number of VCPUs on the database server. You must reduce the number of workers if the machine where you are applying the patch has a lower number of VCPUs when compared to those on the database server. To override the default number of workers when you apply a patch, specify the number of workers by using the workers option, as described in Table 3-3.
The number of workers used for patching database artifacts also imposes a requirement on the open file descriptors configured for your system. Patching requires that the open file descriptors be set to a minimum of 8000 times the number of workers used for the patch session. For more information, see "Increase the Open Files Limit" in the Oracle Fusion Applications Installation Guide.
For more information about workers, see Section 3.1.2.1, "Worker Processes".
Patch validation: Validates whether the database portion of the patch is compatible with your environment and can be applied. If the patch is not valid, the patching session fails. The following validations are performed:
Platform check: Compares the operating system platform for each Oracle Fusion Applications Oracle home against the platform metadata in the patch.
Prerequisite check: Validates that all patch prerequisites have been applied.
Application of the patch: Copies the database artifacts to the Oracle home and then makes changes in the Oracle Fusion Applications database using the updated files.
Compilation of invalid objects: Compiles all invalid objects in the database. For more information, see Section 3.1.2.3, "Compiling Invalid Objects".
Consolidation of log files: Collects the patching results and location of log files for reporting purposes.
A patch with database-related changes includes a patch driver file that provides instructions to AutoPatch about how to apply the patch. The patch driver file specifies the types of actions to be executed and the phases in which they must be executed. To achieve efficient processing time, the database tasks are performed by worker processes and the number of tasks performed is minimized by file version verification. For more information, see Section 3.1.2.1, "Worker Processes" and Section 3.1.2.2, "File Version Verification".
An AutoPatch manager process reads the patch driver file and determines the set of tasks to be performed. It then spawns processes called workers to execute the tasks. The manager and its workers communicate through a table in the database that contains one row for each worker process. The manager assigns tasks to workers by updating the worker row in the table. Each worker process checks the table for updates to its row and carries out the task. When the task is complete, the worker updates the status in the table, and the manager then assigns another task to the worker.
This AutoPatch feature enables incremental running of database-related actions in a patch so that only the actions that have not already been performed against your database are actually run. The first time a database update action runs, the version of the file used to update the database is recorded in tables in the applications database. The next time AutoPatch applies a patch containing that action, it compares the version of the last file run against the current version of the file in the patch. It runs the action only if the version in the patch is newer than the last version run.
Patch Manager uses the standard database-supplied compile utility, which compiles all invalid objects in the database, if no specific schema is supplied. If a schema is supplied it compiles all objects in the schema that are in an invalid state, including those invalid objects that were not affected by the patch. Dependencies between objects can be complex, such as when patching an object causes other objects to become invalid, even though those objects are not in the patch. The purpose of compiling invalid objects after a patch applies is to have a clean database where all objects are in a valid state.
Oracle Fusion Middleware artifacts may be deployed to Managed Servers running on different nodes, but the artifacts are copied to the Oracle Fusion Applications Oracle home that is shared by the different nodes. When a patch contains updates to Oracle Fusion Middleware artifacts, such as Java EE applications or Service-Oriented Architecture (SOA) composites, Patch Manager coordinates the following tasks during online patching:
Patch preparation: Sets up credentials and other necessary environment variables.
Patch validation: Validates the patch against the patch inventory under the Oracle home and domain to ensure that the patch is compatible and the prerequisite patches can be applied.
Topology discovery: Queries the taxonomy tables to find information relevant to the artifacts contained in the patch, such as domains, hosts, the Administration Server URL and Oracle homes. If the query returns exceptions, patching may proceed or fail, depending on the artifact type.
Application of the patch: Calls OPatch to copy the Oracle Fusion Middleware artifacts from the patch to the Oracle Fusion Applications Oracle home. Also deploys those artifacts to the appropriate run-time container so that they are usable, such as deploying a SOA composite to the appropriate SOA server. Note that all artifacts in the patch are copied, but deployment actions occur only for those product families that have been deployed during the provisioning process. Finally, tracks the success or failure of each patching action and performs validation as needed, based on the directives specified in the patch metadata.
Post-patch apply actions: Starts and stops the Managed Servers impacted by the patch in the respective domains, only in online mode. Performs the deployment of certain Oracle Fusion Middleware artifacts.
Consolidation of log files: Collects the patch results and location of log files for reporting purposes.
For more information, see Table 4-1, "Oracle Fusion Middleware Artifacts Supported by Oracle Fusion Applications Patch Manager".
Patch Manager supports two patching modes: online and offline. To apply any patch in online mode, the Administration Servers must be running. For both offline and online modes, the database is still running, but it should be idle. Oracle WebLogic Server is not connected to the database for performing any transactions, so no requests from users should be processed. As the patch administrator, it is your responsibility to ensure that there are no active transactions or processes running during patching.
The primary difference between online and offline modes is that in online mode, Patch Manager automates the post-apply steps, such as shutting down and starting the impacted Managed Servers, and deploying supported Oracle Fusion Middleware artifacts, such as SOA composites, Oracle Business Intelligence Publisher (Oracle BIP) artifacts, and Flexfields. For more information, see Section 4.1, "Oracle Fusion Applications Patch Manager Middleware Artifact Support". When patching in online mode, Patch Manager provides messages about the steps you must take after the patch is applied, to resolve any failures that occurred during the post-apply tasks.
To enable online patching mode, you specify the online option when you run Patch Manager. You must also use the stoponerror option, as described in Table 3-3. Patch Manager determines which domains the patch affects by referencing the taxonomy URL, either by an environment setting or by using the taxonomyurl option. For more information, see Section 2.1.6, "Taxonomy URL".
Note that this automation feature attempts to stop and start only those impacted servers that are running. No stop or start operations are performed on those servers that are not in a running state even if the patch impacts an application that is deployed on this server. During online patching, all servers and applications are running, but they must be idle. Applications login should be restricted and no Oracle Fusion Applications functions should be available to users during online patching. If you prefer to start and stop your Managed Servers using your own process, you can apply online patches in offline mode.
After you apply a patch in offline patching mode, you must manually start and stop the impacted Managed Servers and manually deploy certain Oracle Fusion Middleware artifacts, such as SOA composites, Oracle BI Publisher artifacts, and Flexfields. Before you apply the patch, you can run the Patch Impact report to see which servers will be impacted by the patch. For information about server management for offline patching, see "Starting and Stopping a Product Family Oracle WebLogic Server Domain" in the Oracle Fusion Applications Administrator's Guide.
To minimize downtime, you could choose to leave servers running and start and stop the servers impacted by the patches after the patching session ends. In offline mode, all applications are unavailable to users, but only the servers impacted by the patch must be shut down. The net effect is that the system is unavailable, but the system downtime is minimized if only certain servers are shut down and then started.
If you use the Patch Plan feature in My Oracle Support, you have the option to apply all of the patches in the patch plan during one Patch Manager session. You can also validate these patches in one session. Depending on the contents of the patches, Patch Manager applies the patches either one at a time or it divides the patches into groups, to optimize server management. Applying groups of patches in a single execution minimizes down time because any impacted Managed Servers are stopped and restarted only once.
A set of patches can be applied in a single execution, rather than individually, only if servers can be shutdown at the beginning of the apply session and none of the included patches require the servers to be available. Therefore, true multiple patch application in online mode occurs if the patches involved contain only the following types of artifacts:
Oracle Business Process Management (Oracle BPM) templates
Common Resource artifacts
Database artifacts other than flexfields
Diagnostic Testing Framework (DTF) JAR files
Java EE artifacts
Oracle Data Integrator (ODI) artifacts
SOAEXTENSION artifacts
If any of the patches in the patch plan contain additional artifact types, then Patch Manager applies each patch in the plan sequentially, one patch at a time, because certain servers must be running to deploy certain artifacts. In this case, the server shutdown and restart occurs multiple times, as required by each patch.
For more information about patch plans, see the online help in the Patches & Updates tab in My Oracle Support.
For more information about applying multiple patches, see Section 3.7, "End-to-End Process for Applying Multiple Patches".
You run Patch Manager by using the command line utility, fapmgr, located in the FA_ORACLE_HOME/lcm/ad/bin directory (FA_ORACLE_HOME\lcm\ad\bin for Windows). Its shell script sets the environment and calls the utility. For UNIX, the shell script is fapmgr.sh and for Windows, it is fapmgr.cmd. You can run fapmgr with various commands and options. Only one patching session can be running at any given time. All patch administrators log in as the same operating system user to apply patches. This user must be an owner of the Oracle Fusion Applications Oracle home.
The following command shows the basic syntax for the fapmgr utility:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh command [-options] (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd command [-options]
In the preceding example, the following variables are used:
command: The fapmgr utility manages patching-related activities by using one of the commands as described in Table 3-1.
options: The fapmgr commands accept options by using command-line arguments, as described in the specific sections for each fapmgr command.
Table 3-1 Oracle Fusion Applications Patch Manager Commands
| Command | Description and Link to Documentation |
|---|---|
|
|
Reads the actions in the patch metadata to determine whether a patch is compatible with your environment and can be applied. See Section 3.3, "Validating Patches". |
|
|
Applies a patch. See Section 3.4, "Applying Patches". |
|
|
Provides options for generating reports related to patching. See Section 3.5, "Running Patching Reports". |
|
|
Provides the ability to retry post-apply tasks that failed. See Section 10.3.4, "Retrying Failed Post-Patching Tasks in a Previous Session". |
|
|
Updates the Oracle Fusion Applications Patch Manager data model. See Section 4.16, "Patching Oracle Fusion Applications Patch Manager Artifacts". |
|
|
Abandons the previous patching session that failed. See Section 10.3.2, "Abandoning a Failed Patching Session". |
|
|
Forces a previously hung session to fail. See Section 10.3.3, "Recovering from an Interrupted Patching Session". |
To view additional information for any fapmgr command, use the following syntax:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh command -help (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd command -help
To display basic help for the fapmgr command, enter fapmgr with no options.
Note:
In command syntax examples, the brackets ([]) indicate that the value inside the brackets is optional.
The fapmgr validate command reads the actions in the patch driver file to determine whether a patch is compatible with your environment and can be applied successfully. It looks for the status of impacted servers, patch conflicts, and prerequisites, but it does not perform any updates. Validation can be performed in both offline and online modes.
Patch Manager automatically performs patch validation when you run the fapmgr apply command. The steps for validating a patch are provided here because Oracle recommends that you validate every patch before applying it, especially those patches that contain updates to SOA composites. You can reduce downtime and potential failures during patching by validating SOA composite patches because you can resolve validation issues before you apply the patch. For more information about resolving these issues, see Section 10.4.2, "Troubleshooting SOA Composite Validation Failures".
Validation performs the following actions:
Checks if prerequisite patches have been applied
Checks whether required taxonomy details can be successfully retrieved
Checks whether the servers that are required for automated deployment of the Oracle Fusion Middleware artifacts in the patch are running
Checks whether an Oracle Fusion Middleware artifact will be copied based on version checking
Checks for patch conflicts
Syntax
Use the following syntax for the validate command:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh validate -patchtop (or grouptop) patchtop_directory \ [-patchingplan path_to_patch_plan_xml_file][-online] [-taxonomyurl hostname:portnumber] [-logfile log_file_name][-loglevel log level] (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd validate -patchtop (or grouptop) patchtop_directory \ [-patchingplan path_to_patch_plan_xml_file][-online] [-taxonomyurl hostname:portnumber] [-logfile log_file_name] [-loglevel log level]
Options
Table 3-2 lists the options available for the validate command.
Table 3-2 validate Command Options
| Option | Description | Mandatory |
|---|---|---|
|
|
Identifies the directory where the patch is unzipped |
Yes, unless applying patches in a patch plan. |
|
|
Identifies the directory where the patches in a patch plan are unzipped |
Yes, when applying patches in a patch plan. |
|
|
Identifies the directory path to the My Oracle Support patch plan XML file |
Yes, when applying patches in a patch plan. |
|
|
Validates patch in online mode so the status of impacted servers is checked. |
No, default value is not online. |
|
|
Identifies the host name and port number that overrides the default taxonomy information stored in the environment properties file. The Administration Server passes this value to Patch Manager. |
Conditionally required only when you want override the value present in the environment properties file and when using the online option. |
|
|
Overrides the default log file name and sends the processing information to the file you specify, under the |
No, the utility generates a log file under |
|
|
Records messages in the log file at the level you specify. See Section 10.1, "Oracle Fusion Applications Patch Manager Logging". |
No, default value is |
|
|
Displays help. |
No. |
You apply patches to an Oracle Fusion Applications environment by running the fapmgr apply command. Only one patching session can be active at a time.
Syntax
Use the following syntax for the apply command:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh apply -patchtop (or grouptop) path_to_unzipped_patch [-patchingplan path_to_XML_file] [-stoponerror] [-online][-taxonomyurl hostname:portnumber] [-workers number_of_database_workers] [-logfile log_file_name] [-loglevel level] (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd apply -patchtop (or grouptop path_to_unzipped_patch [-patchingplan path_to_XML_file] [-stoponerror] [-online] [-taxonomyurl hostname:portnumber] [-workers number_of_database_workers] [-logfile log_file_name] [-loglevel level]
Example
The following example applies a patch using 10 database workers in online mode:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh apply -patchtop path_to_unzipped_patch [-stoponerror] -online -workers 10 (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd apply -patchtop path_to_unzipped_ patch [-stoponerror] -online -workers 10
Options
Table 3-3 lists the options available for the apply command.
Table 3-3 apply Command Options
| Option | Description | Mandatory |
|---|---|---|
|
|
Identifies the directory where the patch is unzipped. |
Yes, when applying an individual patch. |
|
|
Identifies the directory where the patches in a patch plan are unzipped |
Yes, when applying patches in a patch plan. |
|
|
Identifies the directory path to the My Oracle Support patch plan XML file |
Yes, when applying patches in a patch plan. |
|
|
Patching session fails after a post-apply error is reported. You can then manually resolve the issue and start the session again, using the same command. |
Yes, when patching in online mode. |
|
|
Identifies the number of workers to use when running database tasks. If you provide a value for the number of workers that is outside the calculated range, you are prompted to provide a value that is within the optimal range. If you do not use the |
No, default value is calculated if patch contains database tasks. See "Worker Calculation" in Section 3.1.2, "Patching Database Artifacts". |
|
|
Applies patch in online mode so that impacted servers are shut down and started and supported artifacts are deployed. See Section 3.1.4, "Online and Offline Patching". |
No, default value is not online. Use this option only when applying online patches. |
|
|
Identifies the host name and port number that overrides the default taxonomy information stored in the environment properties file. The Administration Server passes this value to Patch Manager. |
Conditionally required only when you want to override the value present in the environment properties file and when using the online option. |
|
|
Overrides the default log file name and sends the processing information to the file you specify, under the |
No, the utility generates a log file under |
|
|
Records messages in the log file at the level you specify. See Section 10.1, "Oracle Fusion Applications Patch Manager Logging". |
No, default value is |
|
|
Displays help. |
No. |
You can generate Patch Manager reports by running the fapmgr report command. You can view patch-related information from different perspectives to plan your patching strategy. These reports provide information that can be useful both before and after you apply patches.
Table 3-4 describes the patching reports that can be generated by Patch Manager.
Table 3-4 Patching Reports
| Report Name | Report Option | Description | Variations |
|---|---|---|---|
|
|
Displays the impact of a patch in terms of bug fixes, prerequisites, and product families, by displaying what exists on your system. Also provides a list of artifact types, along with related servers and required manual actions. |
None. |
|
|
|
Displays a list of installed components (product families) and their versions. |
You can specify a list of product families or you can see all product families. |
|
|
|
Displays information about patches and bug fixes that have been applied to your system. |
You can specify a list of product families or you can see all product families. |
|
|
|
Tells you whether specific patches or bug fixes were applied to your system. |
None. |
|
|
- |
Displays the progress of a patching session that is currently running. |
This report runs automatically after each patching session. You can also run it during a patching session. |
The fapmgr report command requires an option to specify which report you want to run, followed by mandatory and optional parameters.
Use the following syntax to run a report:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh report -report_option -mandatory parameters [optional parameters] (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd report -report_option -mandatory parameters [optional parameters]
The Patch Impact report compares the contents of the patch to be applied with the files that currently exist on your system. You get a complete picture of what file system changes will occur when you apply the patch. You can plan your system downtime by viewing the servers that will be impacted by the patch, along with any manual deployment actions that are required after the patch applies. This report reads the patch metadata, local patch inventory, and the current view snapshot. For more information, see Section 9.2, "Maintaining Snapshot Information". Note that you cannot run the Patch Impact report when you are applying multiple patches that were download in a patch plan.
The Patch Impact report displays the impact information about a patch in five sections: bug fixes, prerequisite bug fixes, impacted product families, servers impacted, and files included in the patch.
Bug Fixes
This section provides the following information about the bug fixes included in the patch:
Bug Number: The number of the bug fix or patch
Bug Description: The description of the bug fix or patch
Exists in Oracle home: Whether the bug fix or patch was already applied (Yes or No)
Prerequisite Bug Fixes
This section provides the following information about patches that must be applied before the current patch can be applied:
Bug Number: The number of the prerequisite bug fix or patch
Bug Description: The description of the prerequisite bug fix or patch
Exists in Oracle home: Whether the prerequisite bug fix or patch was already applied (Yes or No)
Prerequisite Bug Fixes Not In FA_ORACLE_HOME
This section provides the following information about patches that must be applied before the current patch can be applied. These patches are not applied to FA_ORACLE_HOME.
Bug Number: The number of the prerequisite bug fix or patch
Bug Description: The description of the prerequisite bug fix or patch
Exists in Oracle home: Whether the prerequisite bug fix or patch was already applied (No)
Product Families Impacted
This section provides the following information about which product families are impacted by the patch:
Product Family: The name of the product family (component) that is updated by the patch
Product: The name of the product that is updated by the patch
LBA: The logical business area that is updated by the patch
Servers Impacted
This section provides the following information about which servers will be impacted by the patch. Note that all artifacts in the patch are copied, but server life cycle actions occur only for those product families that have been deployed during the provisioning process.
Artifact Type: The type and name of the artifact included in the patch
Domain (Servers): The servers that are impacted by the artifacts in the patch
Expectation/Impact: The description of what servers must be running, what actions will be taken during the patch apply phase by Patch Manager, and what manual actions must be taken
Files Included in the Patch
This section provides the following information about the files that are included in the patch:
File Name: The name of the file
File Type: The type of the file
File Version: The version of the file
Before you run the Patch Impact report, ensure that the snapshot is current for the environment. For more information, see Section 9.2, "Maintaining Snapshot Information". Note that you cannot run the Patch Impact report when you are applying multiple patches that were download in a patch plan.
Use the following syntax to run the Patch Impact report:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh report -patchimpact -patchtop path_to_unzipped_patch [optional parameters] (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd report -patchimpact -patchtop path_to_unzipped_patch [optional parameters]
The following table describes the parameters used by the Patch Impact report.
| Parameter | Mandatory | Description |
|---|---|---|
|
|
Yes |
Identifies the directory where the patch is unzipped. |
|
|
No |
Sends the report output to the file you specify after this parameter. You cannot use an existing file name. If you do not use this parameter, no output file is created. |
|
l |
No |
Overrides the default log file name and sends the processing information to the file you specify, under the FAPatchManager_report-patchimpact_timestamp.log
|
|
l |
No |
Records messages in the log file at the level you specify. See Section 10.1, "Oracle Fusion Applications Patch Manager Logging". |
|
|
No |
Sets the column width to either 80 columns or 132 columns by specifying |
The Product Families report provides a list of installed product families along with each associated Oracle Universal Installer (OUI) component name and version. You can run the report for all product families or you can select specific product families. This report reads the local patch inventory and the current view snapshot.
The report includes the following information:
OUI Component: Component name assigned to the product family
Version: The version of the product family
Product Family: The product family name
Description: The product family description
Before you run the Product Families report, ensure that the snapshot is current for the environment. For more information, see Section 9.2, "Maintaining Snapshot Information".
Use the following syntax to run the Product Families report:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh report -listcomps [optional parameters] (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd report -listcomps [optional parameters]
The following table describes the parameters used by the Product Families report.
| Parameter | Mandatory | Description |
|---|---|---|
|
|
No |
Supply a comma-separated list of product families (components) you want to see on the report. The report includes all product families if you do not use this parameter. |
|
|
No |
Sends the report output to the file you specify after this parameter. You cannot use an existing file name. If you do not use this parameter, no output file is created. |
|
l |
No |
Overrides the default log file name and sends the processing information to the file you specify, under the FAPatchManager_report-listcomps_timestamp.log
|
|
l |
No |
Records messages in the log file at the level you specify. See Section 10.1, "Oracle Fusion Applications Patch Manager Logging". |
|
|
No |
Sets the column width to either 80 columns or 132 columns by specifying |
Examples of the command syntax for running the Product Families report follow:
How to show all installed product families and their versions
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh report -listcomps (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd report -listcomps
How to show specific product families and specify the report output file name and log file name
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh report -listcomps -comps oracle.fusionapps.crm, oracle.fusionapps.fin -outputfile listproducts.txt -logfile /log/listproducts.log (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd report -listcomps -comps oracle.fusionapps.crm, oracle.fusionapps.fin -outputfile listproducts.txt -logfile \log\listproducts.log
The Patches Applied report provides information about patches that have been applied to an environment. You can run the report for specific product families or all product families. This report depends on a current snapshot having been run.
The report is organized by product family (OUI component) and each product family section contains the following information:
Patch Number: The patch number
Patch Type: Possible values are Standard or ONE-OFF
Date Applied: The date the patch was applied
Bugs Fixed: The bug fixes included in each patch that was applied
Before you run the Patches Applied report, ensure that the snapshot is current for the environment. For more information, see Section 9.2, "Maintaining Snapshot Information".
Use the following syntax to run the Patches Applied report:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh report -listpatches [optional parameters] (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd report -listpatches [optional parameters]
The following table describes the parameters used by the Patches Applied report.
| Parameter | Mandatory | Description |
|---|---|---|
|
|
No |
Supply a comma-separated list of product families (components) you want to see on the report. The report includes all product families if you do not use this parameter. |
|
|
No |
Sends the report output to the file you specify after this parameter. You cannot use an existing file name. If you do not use this parameter, no output file is created. |
|
l |
No |
Overrides the default log file name and sends the processing information to the file you specify, under the FAPatchManager_report-listpatches_timestamp.log
|
|
l |
No |
Records messages in the log file at the level you specify. See Section 10.1, "Oracle Fusion Applications Patch Manager Logging". |
|
|
No |
Sets the column width to either 80 columns or 132 columns by specifying |
Examples of the command syntax for running the Patches Applied report follow:
How to show all patches applied and set the report width to 132
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh report -listpatches -reportwidth WIDE (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd report -listpatches -reportwidth WIDE
How to show all patches applied for a list of product families
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh report -listpatches -comps oracle.fusionapps.fin, oracle.fusionapps.crm (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd report -listpatches -comps oracle.fusionapps.fin, oracle.fusionapps.crm
The Patch Status report tells you if specific patches or bug fixes have been applied to an environment. You provide a list of patch numbers or bug fixes when you run the report and the output indicates whether each patch or bug fix has been applied. This report queries the local patch inventory and current view snapshot. For more information, see Section 9.2, "Maintaining Snapshot Information".
The report output contains a table with the following columns:
Bug Number: The bug number.
OUI Component: Component name associated with the product family. This column displays Not Applied if the patch was not applied.
Status: Possible values are Applied and Not Applied.
Patch: The patch number. This column displays Not Applied if the patch was not applied.
Date Applied: The date the patch was applied. This column is null if the patch was not applied.
Use the following syntax to run the Patch Status report:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh report -isapplied -bug or -patch [comma-separated_list_of_patches/bug_fixes [optional parameters] (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd report -isapplied -bug or -patch comma-separated_list_of_patches/bug_fixes [optional parameters]
The following table describes parameters used by the Patch Status report.
| Parameter | Mandatory | Description |
|---|---|---|
|
|
Yes, unless the |
Supply a comma-separated list of bug fixes. If you want to request language bug fixes, append the language code to the bug number, for example, |
|
|
Yes, unless the |
Supply a comma-separated list of patches. If you want to request language patches, append the language code to the patch number, for example, |
|
|
No |
Sends the report output to the file you specify after this parameter. You cannot use an existing file name. If you do not use this parameter, no output file is created. |
|
l |
No |
Overrides the default log file name and sends the processing information to the file you specify, under the FAPatchManager_report-listpatches_timestamp.log
|
|
l |
No |
Records messages in the log file at the level you specify. See Section 10.1, "Oracle Fusion Applications Patch Manager Logging". |
|
|
No |
Sets the column width to either 80 columns or 132 columns by specifying |
After each patching sessions ends, the Diagnostics report is automatically generated so that you can view the results of the session. You can also use this report to monitor a patching session that is currently running, by generating the report from the command line. The report output is in HTML format so that it can be viewed from a browser and is located in the FA_ORACLE_HOME/admin/FUSION/log/directory. If the Diagnostics report is generated by RUP Installer, it is located in the FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.6.0.0 directory. The file name is FAPMgrDiagnosticsSummary_mode_timestamp.html. If you are using this report to monitor a session, you can refresh the report output as the patch progresses.
The Diagnostics report contains three sections.
Module Execution Summary
The Module Execution Summary displays high-level information about the tools used during a patching session, such as Patch Manager, OPatch, and AutoPatch. For each tool, the report displays the following information:
Module: Tool called during the patching session, such as Patch Manager
Status: Completion status of the task, such as Success, Failed, or Skipped
Duration: Total time that the module ran
Start Time: Time and date the module started
End Time: Time and date the module ended
Log Files: Link to the Log Summary generated by Patch Manager. For more information, see Section 10.2.1, "Log Summary".
Module Phase Summary
The Module Phase Summary displays summary information about tasks executed by Patch Manager. The tasks are summarized by each AutoPatch and OPatch phase and the following information is displayed:
Mode: The patching mode is either Generic, Database or Middleware
Phase: The name of the patching phase
Duration: Total time the task ran
Start Time: Time and date the task started
End Time: Time and date the task ended
Task Count: Total number of tasks within the phase
Skipped: The number of tasks that were skipped during the phase
Failed: The number of tasks that failed during the phase
Completed: The number of tasks that completed successfully during the phase
Percent Complete: The percentage of tasks that completed successfully during the phase
Tasks With Warnings or Failures
This section displays detailed information about each task that produced a warning or failed. The following information is displayed for each task:
Mode: The patching mode is either Generic, Database or Middleware
Phase: The name of the patching phase and sub-phase
Product Family: The short name of the product family, which displays only for database tasks.
Task: The name of the artifact related to the task including the full path, and the domain, if applicable.
Status: Completion status of the task, such as Failed or Skipped.
Warning/Error Message: The error message is displayed if the task failed. Nonfatal messages appear as warning messages. The message also includes additional steps that are required to resolve the failure, if applicable.
Log File: The name and location of the log file.
Line Number: The line numbers within the log file that pertain to the task.
Module Task Details
The Module Task Details section displays detailed information about each task executed by Patch Manager. The following information is displayed for each task:
Mode: The patching mode is Database, Middleware, or Generic. In Generic mode, database validation and taxonomy URL validation are performed.
Phase: The name of the patching phase, such as Patch Validation, Environment Validation, and Patch Application.
Product Family: The short name of the product family, which displays only for database tasks.
Task: The name of the artifact related to the task including the full path, and the domain, if applicable.
Status: Completion status of the task, such as Success, Failed, or Skipped.
Duration: Total time the task ran.
Start Time: Time and date the task started.
End Time: Time and date the task ended.
Warning/Error Message: The error message is displayed if the task failed. Nonfatal messages appear as warning messages. The message also includes additional steps that are required to resolve the failure, if applicable.
Log File: The name and location of the log file.
Line Number: The line numbers within the log file that pertain to the task.
Tasks to be Completed
The Tasks to be Completed section displays a summary of the tasks you must complete after the patch applies. The following information is displayed:
Mode: The patching mode is Database, Middleware, or Generic. In Generic mode, database validation and taxonomy URL validation are performed.
Phase: The name of the patching phase, such as Patch Validation, Environment Validation, and Patch Application.
Product Family: The short name of the product family, which displays only for database tasks.
Task: The description of the task that must be performed.
Use the following syntax to run the Diagnostics report while a patch session is active:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh report -patchprogress [optional parameters] (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd report -patchprogress [optional parameters]
The following table describes the parameter used by the Diagnostics report.
| Parameter | Mandatory | Description |
|---|---|---|
|
|
No |
Supply with the full directory path and name of the report output. The default value is |
The end-to-end process of obtaining and applying individual patches using Patch Manager, includes the following steps. This process assumes that you apply patches in online mode. If you are applying patches in a patch plan, see Section 3.7, "End-to-End Process for Applying Multiple Patches".
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.
When you have an issue that can be resolved by a patch for Oracle Fusion Applications, research the issue on My Oracle Support:
After you find patches that may resolve your issues, you should confirm whether you previously applied them to your system. Select one of these options for finding whether patches were applied:
Run the Patch Status report to see if specific patches were applied, as described in Section 3.5.4, "Patch Status Report".
Run the Patches Applied report to see all patches applied for a specific product family, as described in Section 3.5.3, "Patches Applied Report".
Upon determining that you need new patches, download the patches from My Oracle Support. Unzip the patch ZIP files in your PATCH_TOP directory.
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. If there are patches listed under "Other Patches" in the README file, you must download and apply them before you apply the Oracle Fusion Applications patch.
Run the Patch Impact report to see the artifacts and Managed Servers impacted by this patch. For more information, see Section 3.5.1, "Patch Impact Report".
An example of the report command follows:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh report -patchimpact -patchtop path_to_unzipped_patch (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd report -patchimpact -patchtop path_to_unzipped_patch
Run the fapmgr validate command to alert you to any potential issues that could result in failure while applying the patch. You should resolve all validation failures during this step, to prevent failures during patch application. This validation step is strongly recommended, especially for patches that deliver artifacts whose deployment is automated by Patch Manager, such as SOA composites. Note that if you validate a patch that contains BI Publisher artifacts, the BI OPMN control process, which is similar to a node manager, has to be up for online mode validation to succeed.When you apply a patch, the patch validation runs again by default. For more information, see Section 3.3, "Validating Patches".
An example of the validate command follows:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh validate -patchtop path_to_unzipped_patch -online (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd validate -patchtop path_to_unzipped_patch -online
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 environment:
Confirm that the database is running and in an idle state.
Confirm that there are no active jobs or processes running against the database. If there are, stop all background jobs, including jobs in the database and active processes
Confirm that the Managed Servers are not in "Edit and Lock" mode, so that Patch Manager can stop and start servers as needed.
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 Oracle Enterprise Scheduler Service Components" in the Oracle Fusion Applications Administrator's Guide for more information.
Cancel any in-progress requests. See "Cancelling Oracle Enterprise Scheduler 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 "Starting and Stopping a Product Family Oracle WebLogic Server Domain" in the Oracle Fusion Applications Administrator's Guide for more information.
If the patch contains BI Publisher reports, ensure that you have your own versions of any customized BI Publisher reports. If a patch includes an update to a catalog object that was delivered with an Oracle Fusion application, the patch will overwrite any customizations applied to the original report. For more information, see "Before You Begin Customizing Reports" in the Oracle Fusion Applications Extensibility Guide.
If the patch contains BI Publisher artifacts, the BI OPMN control process, which is similar to a node manager, has to be up for online mode validation to succeed.
This step is for the Windows operating system only. Ensure that there are no active files. If the lock is not released fapmgr will not be able to copy files.
Apply the patch using the fapmgr apply command as described in Section 3.4, "Applying Patches". An example of the apply command follows:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh apply -patchtop path_to_unzipped patch -online [-workers number_of_database_workers] (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd apply -patchtop path_to_unzipped patch -online [-workers number_of_database_workers]
Monitor the progress of the patching session and verify its successful completion by reviewing the Log Summary from a browser. For more information, see Section 10.2, "Monitoring Patching Sessions".
Review the Diagnostics report to determine if any artifacts require manual deployment or Managed Servers require restart. For example, this report displays the full path of SOA composites that restarted successfully and those that did not restart successfully, which requires additional manual steps. If any servers must be restarted manually, the report provides the target domain and the names of the cluster and Managed Servers that must be restarted. For more information, see Section 3.5.5, "Diagnostics Report".
You can manually perform these steps or you can use the fapmgr retry command. For more information, see Section 10.3.4, "Retrying Failed Post-Patching Tasks in a Previous Session".
For additional information about the deployment of Oracle Fusion Middleware artifacts, see Section 4.1, "Oracle Fusion Applications Patch Manager Middleware Artifact Support".
The end-to-end process of obtaining and applying multiple patches using Patch Manager, assumes that you create and download a patch plan from My Oracle Support and you apply these patches in online mode. A set of patches can be applied in one execution, rather than individually, only if servers can be shutdown at the beginning of the apply session and none of the included patches require the servers to be available. See Section 3.1.5, "Applying Multiple Patches Using a My Oracle Support Patch Plan" for a list of artifact types that allow multiple patches to be applied in one execution. If one patch fails to apply, the entire process stops.
If any of the patches in the patch plan contain any other artifact types, then Patch Manager applies each patch in the plan sequentially, one patch at a time. In this case, the server shutdown and restart occurs multiple times, as required by each patch.
This process of applying multiple patches in a patch plan 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.
When you have an issue that can be resolved by one or more patches for Oracle Fusion Applications, research the issue on My Oracle Support:
After you find patches that resolve your issues, you should confirm whether you previously applied them to your system. Select one of these options for finding whether patches were applied:
Run the Patch Status report to see if specific patches were applied, as described in Section 3.5.4, "Patch Status Report".
Run the Patches Applied report to see all patches applied for a specific product family, as described in Section 3.5.3, "Patches Applied Report".
Upon determining that you need new patches, create a patch plan and download the patch plan from My Oracle Support. Unzip the patch ZIP files in your PATCH_TOP directory.
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. If there are patches listed under "Other Patches" in the README file, you must download and apply them before you apply the Oracle Fusion Applications patch.
Run the fapmgr validate command to alert you to any potential issues that could result in failure while applying the patches. You should resolve all validation failures during this step, to prevent failures during patch application. This validation step is strongly recommended, especially for patches that deliver artifacts whose deployment is automated by Patch Manager, such as SOA composites. Note that if you validate a patch that contains BI Publisher artifacts, the BI OPMN control process, which is similar to a node manager, has to be up for online mode validation to succeed.
When you apply patches, the patch validation runs again by default. For more information, see Section 3.3, "Validating Patches".
An example of the validate command follows:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh validate -grouptop path_to_unzipped_patches -patchingplan path_to_patch_plan_xml_file -online (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd validate -grouptop path_to_unzipped_patches -patchingplan path_to_patch_plan_xml_file -online
The patch plan XML file is downloaded from My Oracle Support when you download the patch plan.
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 environment:
Confirm that the database is in an idle state.
Confirm that there are no active jobs or processes running against the database. If there are, stop all background jobs, including jobs in the database and active processes
Confirm that the Managed Servers are not in "Edit and Lock" mode, so that Patch Manager can stop and start servers as needed.
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 Oracle Enterprise Scheduler Service Components" in the Oracle Fusion Applications Administrator's Guide for more information.
Cancel any in-progress requests. See "Cancelling Oracle Enterprise Scheduler 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 "Starting and Stopping a Product Family Oracle WebLogic Server Domain" in the Oracle Fusion Applications Administrator's Guide for more information.
If any of the patches contain BI Publisher reports, ensure that you have your own versions of any customized BI Publisher reports. If a patch includes an update to a catalog object that was delivered with an Oracle Fusion application, the patch will overwrite any customizations applied to the original report. For more information, see "Before You Begin Customizing Reports" in the Oracle Fusion Applications Extensibility Guide.
If the patch contains BI Publisher artifacts, the BI OPMN control process, which is similar to a node manager, has to be up for online mode validation to succeed.
This step is for the Windows operating system only. Ensure that there are no active files. If the lock is not released fapmgr will not be able to copy files.
Apply the patch using the fapmgr apply command as described in Section 3.4, "Applying Patches". An example of the apply command follows:
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh apply -grouptop path_to_unzipped_patches -patchingplan path_to_patch_plan_xml_file -online -stoponerror [-workers number_of_database_workers] (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd apply -grouptop path_to_unzipped_patches -patchingplan path_to_patch_plan_xml_file -online -stoponerror [-workers number_of_database_workers]
Monitor the progress of the patching session and verify its successful completion by reviewing the Log Summary from a browser. For more information, see Section 10.1.2, "Log Files for Multi-apply Patch Manager Sessions".
Review the Diagnostics report to determine if any artifacts require manual deployment or Managed Servers require restart. For example, this report displays the full path of SOA composites that restarted successfully and those that did not restart successfully, which requires additional manual steps. If any servers must be restarted manually, the report provides the target domain and the names of the cluster and Managed Servers that must be restarted. For more information, see Section 3.5.5, "Diagnostics Report".
You can manually perform these steps or you can use the fapmgr retry command. For more information, see Section 10.3.4, "Retrying Failed Post-Patching Tasks in a Previous Session".
For additional information about the deployment of Oracle Fusion Middleware artifacts, see Section 4.1, "Oracle Fusion Applications Patch Manager Middleware Artifact Support".
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
