Oracle® Fusion Middleware Patching Guide 11g Release 1 (11.1.1.7.0) Part Number E16793-20 |
|
|
PDF · Mobi · ePub |
This document describes patching in an Oracle Fusion Middleware environment.
The following topics are covered:
Patches are a small collection of files copied over to an existing installation. They are associated with particular versions of Oracle products.
Note:
Oracle recommends that all customers upgrade to the latest version of OPatch. Review the following My Oracle Support note and follow the instructions to update to the latest version if needed:
Note 224346.1
- Opatch - Where Can I Find the Latest Version of Opatch?
Note:
As of 11g Release 1 (11.1.1.7.0) Oracle is implementing a new patch nomenclature for Oracle products. The new patch names and the previous names are listed below for reference.
OPatch can be used for the following types of patches:
Table 2-1 Patches that can be used with OPatch
New Name | Old Name(s) | Description |
---|---|---|
Interim Patch |
PSE MLR Exception release One-Off x-fix Hotfix Security One-Off |
A patch containing one or more fixes made available to customers who cannot wait until the next patch set or new product release to get a fix. |
Bundle Patch |
Maintenance Pack Service Pack MLRs Cumulative Patch Update Release Bundle Patch |
An iterative, cumulative patch that is issued between patch sets. Bundle patches usually include only fixes, but some products may include minor enhancements. Examples are the Database Windows Bundles and SOA Bundle Patches. |
Security Patch Update (SPU) |
Critical Patch Updates CPUs |
An iterative, cumulative patch consisting of security fixes. Formerly known as Critical Patch Update. Note: The program name which delivers SPUs will still be called Critical Patch Update, as defined below: Critical Patch Update: Oracle's program for quarterly release of security fixes. Patches released as part of this program may be Patch Set Updates, Security Patch Updates, and Bundle Patches. Regardless of the patch type, the patches are cumulative. |
Patch Set Updates (PSUs) |
Patch Set Updates are used to patch Oracle WebLogic Server only. Patch Set Updates are released on a quarterly basis, following the same schedule as the Critical Patch Updates (CPUs). These come out the closest Tuesday to the 15th of the months of January, April, July and October. Patch Set Update content is intended to address the top fifty critical bugs affecting the broad customer base. |
The only type of patch that is not applied with OPatch is a patch set. A patch set contains a large number of merged patches, is thoroughly tested, changes the version of the product it is applied to, and can sometimes introduce new functionality. Patch sets are cumulative bug fixes that fix all bugs and consume most patches since the last base release.
Patch sets and the Patch Set Assistant are usually applied through OUI-based product specific installers. For more information, see Chapter 3, "Applying the Latest Oracle Fusion Middleware Patch Set".
OPatch is a Java-based utility that runs on all supported operating systems and requires installation of the Oracle Universal Installer. This document contains information pertaining to OPatch commands that are most commonly used in an Oracle Fusion Middleware environment. You can use all supported OPatch commands if you choose; for a full list of OPatch commands and for more information about the OPatch utility, refer to the Oracle Universal Installer and OPatch User's Guide at the following URL:
http://docs.oracle.com/cd/B28359_01/em.111/b31207/toc.htm
This section contains the following:
Section 2.2.2, "Getting Patches that Can be Applied with OPatch"
Section 2.2.5, "Backup and Recovery Considerations for Patching"
OPatch can be found in your Fusion Middleware product's ORACLE_HOME/OPatch
(on UNIX operating systems) or ORACLE_HOME\OPatch
(on Windows operating systems) directory.
Oracle recommends that you always check for and obtain the latest version of OPatch from My Oracle Support (formerly Oracle MetaLink).
Access and log into My Oracle Support at the following location:
http://support.oracle.com/
In the Search Knowledge Base field, enter 224346.1. This is the ID of the document that describes how to obtain the latest version of OPatch.
In the search results, click on the link corresponding to document ID 224346.1.
In the document, click on the Patch 6880880 link which will take you to the screen where you can obtain the latest version of OPatch based on release versions and platforms.
Make sure you verify that the OPatch release number in the "Release" column is "11.1.0.0.0" as this is the correct version of OPatch for Oracle Fusion Middleware 11g products.
You can obtain the latest patches by specifying the patch ID in My Oracle Support (formerly MetaLink):
Access and log into My Oracle Support at the following location:
http://support.oracle.com/
Click the Patches & Updates link.
Enter the Patch ID or Number, then click Search. A Patch Search Results table appears.
Using the Release and Platform columns, find the desired patch, then click the associated Patch ID.
In the page that now appears, click the Download button in the right-hand column.
OPatch uses the environment variables listed in Table 2-2:
The OPatch utility has the following requirements:
The ORACLE_HOME
environment variable must point to a valid Oracle home directory and match the value used during installation of the Oracle home directory.
If the -invPtrLoc
command-line argument was used during installation, then it must be used when using the OPatch utility. Oracle recommends the use of the default central inventory for a platform.
The java
, ar
, cp
, and make
commands must be available in one of the directories listed in the PATH
environment variable. The commands are not available for all platforms.
It is highly recommended that you back up the ORACLE_HOME
before any patch operation. You can back up the ORACLE_HOME
using your preferred method. You can use any method such as zip
, cp -r
, tar
, and cpio
to compress the ORACLE_HOME
.
If the ORACLE_HOME
does not appear when you execute the opatch lsinventory -detail
command, the ORACLE_HOME
might be missing from the Central Inventory, or the Central Inventory itself could be missing or corrupted.
If the ORACLE_HOME
is listed when you execute the opatch lsinventory -detail
command, but the products and components within the ORACLE_HOME
are not listed, the inventory within the ORACLE_HOME
(local inventory) might be missing or corrupted.
If the local inventory is corrupted or lost for some reason, you can simply restore the ORACLE_HOME/inventory
(on UNIX operating systems) or ORACLE_HOME\inventory
(on Windows operating systems) if it was backed up. If a backup does not exist, you may have to reinstall the software.
This section describes the Oracle OPatch utility as it pertains to an Oracle Fusion Middleware environment. You should be familiar with the Oracle Fusion Middleware concepts introduced in the Oracle Fusion Middleware Installation Planning Guide, which is available at the following URL:
http://download.oracle.com/docs/cd/E15523_01/install.1111/b32474/toc.htm
This section contains the following:
Consider a common, non-distributed Fusion Middleware topology for Oracle SOA Suite and Oracle WebCenter, as show in Figure 2-1:
Note:
OPatch can be used to patch any Fusion Middleware product, even though only a few are shown in this example. OPatch can not be used to patch Oracle WebLogic Server.
Figure 2-1 Common Fusion Middleware Topology for Oracle SOA Suite and Oracle WebCenter
Suppose you have a problem in the SOA Domain. Below is a typical patching process:
Step 1. Contact Oracle Support
You can contact your Oracle support representative, or you can go to My Oracle Support (formerly OracleMetaLink):
http://support.oracle.com/
Step 2. Check for Existing Patches
If Oracle Support is not able to resolve the issue, they may ask to see if you have any patches already installed on your system. To determine this information, you should run the opatch lsinventory
command.
To check if a particular patch is installed in the Oracle home (or the set of Oracle homes within a Middleware home) you use the opatch checkInstalledOneOffs
command. See Section 2.4.7, "Listing Patches Applied to an Oracle Home or WebLogic Domain" for more information about this command.
Step 3. Obtain OPatch and the Necessary Patch
Upon determining that you are in need of a new patch and it has not already been installed on your system, you should do the following:
Make certain that you have the latest version of OPatch, as described in Section 2.2.1, "Getting OPatch".
Obtain the patch as described in Section 2.2.2, "Getting Patches that Can be Applied with OPatch".
Step 4. Determine the Oracle Home
Once you obtain the patch, determine the Oracle home directory to which you are going to apply the patch.
The most common type of patch available in a Fusion Middleware environment involves patching a specific Oracle home directory. Some patches (for example, a patch pertaining to JRF) may apply to multiple Oracle home directories within a specific Middleware home. A third type of patch could involve client components in one Oracle home and server components in a different Oracle home (for example, Oracle WebCenter in the WebCenter Oracle home depends on BPEL Process Manager in the Oracle SOA Suite Oracle home).
If you do not know the name of your Oracle home, you should run the opatch lshomes
command as described in Section 2.4.6, "Listing the Applicable Oracle Homes for a Patch" to obtain a list of Oracle homes that pertain to the domain. In this example, the Oracle home to which the patch should be applied is the SOA Oracle home.
After you determine your Oracle home, you should run the opatch checkApplicable
command as described in Section 2.4.6, "Listing the Applicable Oracle Homes for a Patch" to make sure that the patch can actually be applied to the Oracle home.
As the Middleware home is the top-level entity in a Fusion Middleware topology, the location of your Middleware home will be required for many of the OPatch commands in a Fusion Middleware environment.
Step 5. Read the README File
Read the README file that accompanies the patch. This file contains important information and instructions that must be followed prior to applying your patch.
For example, the README file may instruct you to apply the patch using the -auto
option (described in Section 2.4.1.2, "Using the -auto Option"). The more common scenario is that the README will instruct you to use a series of OPatch commands, including opatch stop
and opatch start
(see Section 2.4.8, "Starting or Stopping a Runtime Instance").
Step 6. Apply the Patch
After you determine the Oracle home to which you need to apply the patch, you should apply the patch with the opatch apply
command as described in Section 2.4.1, "Applying Patches and Deploying Patched Artifacts to WebLogic Servers".
After Applying the Patch...
In most cases, after you apply the patch the instructions in the README file will tell you to run the opatch start
command to re-start your servers.
After the patching is complete and your servers are restarted, you should check your product software to verify that the issue has been resolved.
If for some reason the result is not satisfactory, you can use the opatch rollback
command to remove the patch from the Oracle home. See Section 2.4.2, "Rolling Back Patches and Deploying Patched Artifacts to WebLogic Servers" for more information, and consult the README file for specific instructions.
Many Fusion Middleware artifacts are deployed to a runtime environment, where applications pick up these binaries for execution. A common example of this are J2EE artifacts (for example, .ear
, .war
, or .rar
files) or J2EE shared libraries deployed to a Managed Server or cluster running within a domain. Patching in a Fusion Middleware environment involves updating and replacing these artifacts in the Oracle home. The servers to which the artifacts are deployed need to be restarted for the changes to take effect.
After the artifacts are deployed, there are various staging modes that affect how WebLogic Server treats these artifacts, which in turn determine how the applications are patched. All artifacts in Oracle Fusion Middleware 11g Release 1 (11.1.1.7.0) are deployed in NoStage Mode, which means that each Managed Server must access the archive files from a single source directory for deployment. If a J2EE application is deployed to three Managed Servers within a cluster, each Managed Server must be able to access the same application archive files from a shared or network-mounted directory in order to deploy the new J2EE application.
Take note of the following:
If multiple Managed Servers on multiple machines are used, the path to the application bits must be the same on all machines because there is a single point of entry for the application in the domain configuration.
Since the source location for the application bits is fixed and points back to its own ORACLE_HOME location, all domains that were created using a given ORACLE_HOME will pick up the patched bits once the ORACLE_HOME is patched.
If you are using multiple Managed Servers on multiple machines and the product ORACLE_HOME
is not shared or network-mounted on the target Managed Servers, then each machine must have the product installed on an ORACLE_HOME
on the local file system from which the Managed Servers can access the application binaries. Therefore, the ORACLE_HOME
on each local file system of each machine must be patched separately.
The steps that need to be performed for this scenario are as follows:
Stop all Managed Servers in the WebLogic Domain to which the application is deployed.
Use the opatch apply
command to apply the bits to an Oracle home.
Restart all the Managed Servers in the same WebLogic Domain.
Steps 1 and 3 are performed by the Fusion Middleware capabilities in OPatch.
The process to patch in a distributed environment depends on whether or not your Middleware home directory is shared or not shared.
Consider the environment shown in Figure 2-2. This is a distributed environment, where you have identical topologies on separate machines, each with its own local Middleware home and Fusion Middleware products inside the Middleware home:
Figure 2-2 Distributed Fusion Middleware Topology for Oracle SOA Suite and Oracle WebCenter
If you encountered a problem in the SOA domain, you would have to patch the corresponding Oracle home on each machine separately, according to the instructions in the README file. After you patch the SOA Oracle home on "Middleware Host 1," for example, you must then repeat the same procedure on "Middleware Host 2."
Consider the environment shown in Figure 2-3. This is also a distributed environment, where you have identical topologies on separate machines, but the Middleware home on "Middleware Host 2" is shared or NFS mounted:
Figure 2-3 Distributed Fusion Middleware Topology for Oracle SOA Suite and Oracle WebCenter
In this topology, if you encountered a problem in the SOA Domain, you would only need to patch the SOA Oracle home on either "Middleware Host 1" or "Middleware Host 2" in accordance with the instructions in the README file, and OPatch would automatically patch all of the matching Oracle homes that share the same Middleware home.
Some applications, such as Oracle Enterprise Manager Fusion Middleware Control and Oracle Web Services Manager Policy Manager (WSM-PM), are deployed outside of the product Oracle home (in the Oracle Common Home or oracle_common
) directory. OPatch can also apply patches to files that reference the oracle_common
directory.
The OPatch utility is located in the ORACLE_HOME/OPatch
(on UNIX operating systems) or ORACLE_HOME\OPatch
(on Windows operating systems) directory. Below is the syntax for the OPatch utility:
path_to_opatch/opatch command -options
Acceptable values for command are described in Table 2-3.
Valid options for each command are described in the sections that describe each command.
Table 2-3 Commands for the OPatch Utility in a Fusion Middleware Environment
Command | Description |
---|---|
|
Apply the patch to an Oracle home and deploy the patch to a WebLogic domain. For details, see Section 2.4.1, "Applying Patches and Deploying Patched Artifacts to WebLogic Servers". |
|
Remove the patch from an Oracle home. For details, see Section 2.4.2, "Rolling Back Patches and Deploying Patched Artifacts to WebLogic Servers". |
|
Deploy the patch to a WebLogic domain. For details, see Section 2.4.3, "Deploying Patched Artifacts to WebLogic Servers". |
|
List all Oracle homes to which a patch can be applied. For details, see Section 2.4.6, "Listing the Applicable Oracle Homes for a Patch". |
|
List the Oracle homes that have been used to create WebLogic Domains. For details, see Section 2.4.4, "Listing the Source Oracle Homes". |
|
List all WebLogic domains created from the Middleware home or specific Oracle home. For details, see Section 2.4.5, "Listing the Domains Created from the Middleware Home or Oracle Home". |
|
Check if certain patches are installed on any Oracle homes. For details, see Section 2.4.7, "Listing Patches Applied to an Oracle Home or WebLogic Domain". |
|
Start or Stop a WebLogic Administration Server, Managed Server, or Cluster. For details, see Section 2.4.8, "Starting or Stopping a Runtime Instance". |
To view additional information for these Fusion Middleware options, use the following command:
path_to_OPatch/opatch -help -fmw
The apply
command in a Fusion Middleware environment applies the patch to the Oracle home on the local machine.
Note:
The option to apply a patch to a Middleware home (including all Oracle homes inside that Middleware home) is not yet available.
Sensitive information such as Administration Server credentials, and other important information such as the Administration Server URL, domain location and applications directory location, are obtained by prompts from the console. In some cases, default values may be found and specified by OPatch; in these cases, press Enter to use these default values.
Automation applications such as Grid Control may invoke OPatch with the -silent
option, which does not prompt for any input from the console. To supply the necessary Administration Server credentials and other information, a response file can be created and passed to OPatch as an argument with the -property_file
option.
For Fusion Middleware components, userConfigFile
and userKeyFile
can be specified in the property file as keys with corresponding file names. The userConfigFile
file contains an encrypted user name and password, while the userKeyFile
contains a secret key that is used to encrypt and decrypt the user name and password. Similarly, the AdminServerURL
(URL of the Administration Server), DomainHome
(full path to the domains
directory) and ApplicationsDir
(full path to the applications
directory) can also be specified in the properties file.
Some patches are certified by Oracle Product Support as capable of being used with the -auto
option, which can automate certain portions of your patching procedure. The -auto
option applies the patch to the Oracle home; verifies that the patch is actually applied, then performs any necessary redeploy operations against the specified WebLogic Domain, including stopping and starting all the servers that are affected by the patch. If your patch is certified for use with the -auto
option, you will be informed of such in the patch's README file.
Beginning with OPatch release 11.1.0.8.2, the -auto
option requires the Node Manager user name and password. In order for OPatch to be used properly:
The Administration Server must be up and running.
If the Managed Servers are up and running, OPatch will stop the servers, apply the patch, then restart the servers.
If the Managed Servers are not running, OPatch will apply the patch but then you must manually start the servers in order to see the effects of the patch.
To configure Node Manager, refer to "General Node Manager Configuration" in Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server.
The -auto
option should be used in conjunction with the -domain
option; the only exception is if only one WebLogic Domain was configured from the Oracle home. In such cases, OPatch will use that domain as the default domain. If multiple domains have been created and the -domain
option is not used, then it is the user's responsibility to run opatch deploy
to redeploy the patched artifacts to their respective domains, and also stop and start the affected servers in each of the domains.
The apply
command (with the -auto
option specified) performs the following:
Stops all affected target servers.
This might involve stopping server instances on other nodes for:
Staged mode applications.
NoStage mode applications sharing the Oracle home.
Applies the patch to the Oracle home on the local machine.
Performs any required deploy operations for patched artifacts.
Restarts all affected servers.
The syntax for the apply
command is shown below:
opatch apply [-auto [-domain domain_name]] [-mw_home MW_HOME] [-oh ORACLE_HOME] [-property_file path_to_property_file] [-report]]
A summary of the options for the apply
command are described in Table 2-4.
Table 2-4 Options for the OPatch apply Command
Option | Description |
---|---|
|
Optional - causes OPatch to automate the rollout of the patch to Oracle Fusion Middleware entities. If See Section 2.4.1.2, "Using the -auto Option" for more information. |
|
Optional - The Middleware home to which the patch will be applied. The Middleware home specified here supersedes the MW_HOME environment variable. If neither is specified, then the Middleware home from where the command is run will be used. |
|
Optional - This option is used to specify the Oracle home to which the patch should be applied. This value supersedes the ORACLE_HOME environment variable. If neither is specified, OPatch will apply the updates to the Oracle home from which it was launched. |
|
Optional - absolute path and name of the property file. See Section 2.4.1.1, "Using the OPatch Property File" for more information. |
|
Optional - print out the actions that will be taken by executing the command, but does not actually execute the command. |
Below is a sample output from the opatch apply
command on a UNIX operating system:
[aime@stadn41 Oracle_SOA1]$ ./OPatch/opatch apply -auto /OracleFMW/Middleware_PS1_RC2/FMWPatches/9991008/ -oh /OracleFMW/Middleware_PS1_RC2/oracle_common/ -domain MySOAWebCenterDist Invoking OPatch 11.1.0.6.9 Oracle Interim Patch Installer version 11.1.0.6.9 Copyright (c) 2009, Oracle Corporation. All rights reserved. Oracle Home : /OracleFMW/Middleware_PS1_RC2/oracle_common Central Inventory : /ade/aime_dte6989/oracle/work/EM_SH_1/oraInventory from : /etc/oraInst.loc OPatch version : 11.1.0.6.9 OUI version : 11.1.0.7.0 OUI location : /OracleFMW/Middleware_PS1_RC2/oracle_common//oui Log file location : /OracleFMW/Middleware_PS1_RC2/oracle_common/cfgtoollogs/opatch/opatch2009-12-06_09-44-02AM.log Patch history file: /OracleFMW/Middleware_PS1_RC2/oracle_common/cfgtoollogs/opatch/opatch_history.txt OPatch detects the Middleware Home as "/OracleFMW/Middleware_PS1_RC2" Please enter the WebLogic Admin Server username:> weblogic Please enter the WebLogic Admin Server password:> Please enter the WebLogic Admin Server URL(t3://stadn41:7011):> Please enter the WebLogic domain directory location(/OracleFMW/MyDomains/domains/MySOAWebCenterDist):> Please enter the WebLogic applications directory location(/OracleFMW/MyDomains/applications/MySOAWebCenterDist):> [FMW] Running apply '-auto' prerequisite checks... [FMW] ProductDriver::preReq_Product() succeeded [FMW] ProductDriver::preReq_Deploy() succeeded All the applications affected by this patch are deployed in 'No Stage' mode. Redeploy operation will not be performed for the affected applications. Please refer to the log file for more details. [FMW] ProductDriver::preReq_LifeCycle() succeeded [FMW] Apply '-auto' prerequisite checks succeeded... ApplySession applying interim patch '9991008' to OH '/OracleFMW/Middleware_PS1_RC2/oracle_common' Running prerequisite checks... You selected -local option, hence OPatch will patch the local system only. Please shutdown Oracle instances running out of this ORACLE_HOME on the local system. (Oracle Home = '/OracleFMW/Middleware_PS1_RC2/oracle_common') Is the local system ready for patching? [y|n] y User Responded with: Y Backing up files and inventory (not for auto-rollback) for the Oracle Home Backing up files affected by the patch '9991008' for restore. This might take a while... Backing up files affected by the patch '9991008' for rollback. This might take a while... Patching component oracle.jrf.j2ee, 11.1.1.2.0... Copying file to "/OracleFMW/Middleware_PS1_RC2/oracle_common/modules/oracle.jrf_11.1.1/jrf-api.jar" Patching component oracle.jrf.dms, 11.1.1.2.0... Copying file to "/OracleFMW/Middleware_PS1_RC2/oracle_common/modules/oracle.dms_11.1.1/dms.war" ApplySession adding interim patch '9991008' to inventory Verifying the update... Inventory check OK: Patch ID 9991008 is registered in Oracle Home inventory with proper meta-data. Files check OK: Files from Patch ID 9991008 are present in Oracle Home. The local system has been patched and can be restarted. [FMW] Ignoring Deploy operations as all patched artifacts are deployed in 'No Stage' mode [FMW] Performing Auto Post-Deploy Actions [FMW] Performing Auto Post-Bounce Actions -------------------------------------------------------------------------------- The following warnings have occurred during OPatch execution: 1) OUI-67851: All the applications affected by this patch are deployed in 'No Stage' mode. Redeploy operation will not be performed for the affected applications. Please refer to the log file for more details. -------------------------------------------------------------------------------- OPatch Session completed with warnings. OPatch completed with warnings.
The rollback
command allows you to remove an existing one-off patch by specifying the unique patch ID.
The rollback
command (with the -auto
option specified) performs the following:
Stops all affected target servers.
This might involve stopping server instances on other nodes for:
Staged mode applications.
NoStage mode applications sharing the Oracle home.
Rolls back the patch on the Oracle home on the local machine.
Performs any required deploy operations for patched artifacts.
Restarts all affected servers.
The syntax for the rollback
option is shown below:
opatch rollback -id patch_id [-auto [-domain domain_name]] [-mw_home MW_HOME] [-oh ORACLE_HOME] [-property_file path_to_property_file [-report]]
A summary of the options for the rollback
command are described in Table 2-5.
Table 2-5 Options for the OPatch rollback Command
Option | Description |
---|---|
|
Use the |
|
Optional - causes OPatch to automate the rollout of the patch to Oracle Fusion Middleware entities. If Refer to Section 2.4.1, "Applying Patches and Deploying Patched Artifacts to WebLogic Servers" for more information. |
|
Optional - The Middleware home to which the patch will be applied. The Middleware home specified here supersedes the MW_HOME environment variable. If neither is specified, then the Middleware home from where the command is run will be used. |
|
Optional - This option is used to specify the Oracle home to which the patch should be applied. This value supersedes the ORACLE_HOME environment variable. If neither is specified, OPatch will apply the updates to the Oracle home from which it was launched. |
|
Optional - absolute path and name of the property file. Refer to Section 2.4.1, "Applying Patches and Deploying Patched Artifacts to WebLogic Servers" for more information. |
|
Optional - print out the actions that will be taken by executing the command, but does not actually execute the command. |
This operation deploys modified artifacts from the Fusion Middleware ORACLE_HOME to the Fusion Middleware domain.
The location of the patch binaries must be specified using the -ph
option. If the patch is installed in the current Oracle home (the Oracle home from which you are running this command) then the -ph
option is not required.
If the patch is already applied to the Oracle home, the -id
option can be used to specify the patch you want to use for deployment.
The syntax for the deploy
command is shown below:
opatch deploy -id patch_id -ph patch_location [-auto [-domain domain_name]] [-mw_home MW_HOME] [-oh ORACLE_HOME] [-property_file path_to_property_file [-report]]
A summary of the options for the deploy
command are described in Table 2-6.
Table 2-6 Options for the OPatch deploy Command
Option | Description |
---|---|
|
The unique ID of the patch that is installed in the Oracle home. |
|
The absolute path to the location of the patch. If none is specified, then the current directory is used. |
|
Optional - causes OPatch to automate the rollout of the patch to Oracle Fusion Middleware entities. If Refer to Section 2.4.1, "Applying Patches and Deploying Patched Artifacts to WebLogic Servers" for more information. |
|
Optional - The Middleware home to which the patch will be applied. The Middleware home specified here supersedes the MW_HOME environment variable. If neither is specified, then the Middleware home from where the command is run will be used. |
|
Optional - This option is used to specify the Oracle home to which the patch should be applied. This value supersedes the ORACLE_HOME environment variable. If neither is specified, OPatch will apply the updates to the Oracle home from which it was launched. |
|
Optional - absolute path and name of the property file. Refer to Section 2.4.1, "Applying Patches and Deploying Patched Artifacts to WebLogic Servers" for more information. |
|
Optional - print out the actions that will be taken by executing the command, but does not actually execute the command. |
The lshomes
command lists all the Oracle homes pertaining to logical entities such as Host or Domain. For a Host, the list of Oracle homes is obtained from the machine's central inventory. For a WebLogic domain, the list of homes is limited to product Oracle homes that are installed within a top-level Middleware home.
If the -domain
or -domaindir
option is used, the command lists the Oracle homes that have been used to create or extend the WebLogic domain. If not, all the homes registered with the machine's central inventory or the inventory location specified using -invPtrLoc
are listed.
The Middleware home can be specified by using the -mw_home
option or by setting the MW_HOME environment variable. When the Middleware home is specified and the -domain
or -domaindir
option is not specified, this command will list all the Oracle homes within the Middleware home that are registered with the machine's central inventory or the specified inventory location.
The syntax for the lshomes
option is shown below:
opatch lshomes [-domain domain_name | -domain_dir domain_location] [-mw_home MW_HOME ] [-invPtrLoc path_to_oraInst.loc]
A summary of the options for the lshomes
command are described in Table 2-7.
Table 2-7 Options for the OPatch lshomes Command
Option | Description |
---|---|
|
Optional - list the Oracle homes that have been used to create or extend this WebLogic Domain. |
|
Optional - list the Oracle homes that have been used to create or extend the WebLogic Domain at this location. You must specify the absolute path to the WebLogic Domain. |
|
Optional - list only the Oracle homes registered with the machine's central inventory that are located in this Middleware home. You must specify the absolute path to the Middleware home directory; this value supersedes the MW_HOME environment variable. If neither is available, the Middleware home from which the command is executed will be used. |
|
Optional - absolute path to the location of your |
Below is an example of the opatch lshomes
command on a UNIX operating system:
[aime@stadn41 Oracle_SOA1]$ ./OPatch/opatch lshomes -domain MySOAWebCenterDist Invoking OPatch 11.1.0.6.9 Oracle Interim Patch Installer version 11.1.0.6.9 Copyright (c) 2009, Oracle Corporation. All rights reserved. UTIL session Oracle Home : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1 Central Inventory : /ade/aime_dte6989/oracle/work/EM_SH_1/oraInventory from : /etc/oraInst.loc OPatch version : 11.1.0.6.9 OUI version : 11.1.0.7.0 OUI location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/oui Log file location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch2009-12-06_10-57-49AM.log Patch history file: /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch_history.txt OPatch detects the Middleware Home as "/OracleFMW/Middleware_PS1_RC2" Invoking utility "lshomes" Home path = "/OracleFMW/Middleware_PS1_RC2/oracle_common" Home path = "/OracleFMW/Middleware_PS1_RC2/Oracle_SOA1" Home path = "/OracleFMW/Middleware_PS1_RC2/Oracle_WC1" OPatch command 'lshomes' done. OPatch succeeded.
The lsdomains
command lists all the WebLogic Domains that have been created from a certain Oracle home:
If the Oracle home is specified, then only those domains created from the specified Oracle home are listed. If no Oracle home is specified, OPatch will list the domains created from the Oracle home as defined by the ORACLE_HOME environment variable. If neither is available, then OPatch will use the Oracle home directory from which the command is run.
If a Middleware home is specified, all domains created from all Oracle homes within the specified Middleware home are listed.
If neither is specified, and neither the MW_HOME or ORACLE_HOME environment variable is defined, then OPatch will run the command for the Middleware home from where the command was run.
The syntax for the lsdomains
command is shown below:
opatch lsdomains [-oh ORACLE_HOME] [-mw_home MW_HOME] [-invPtrLoc path_to_oraInst.loc]
A summary of the options for the lsdomains
command are described in Table 2-8.
Table 2-8 Options for the OPatch lsdomains Command
Option | Description |
---|---|
|
Optional - absolute path to the Oracle home directory. |
|
Optional - absolute path to the Middleware home directory. |
|
Optional - absolute path to the location of your |
Below is an example of the opatch lsdomains
command on a UNIX operating system:
[aime@stadn41 Oracle_SOA1]$ ./OPatch/opatch lsdomains -oh /OracleFMW/Middleware_PS1_RC2/oracle_common Invoking OPatch 11.1.0.6.9 Oracle Interim Patch Installer version 11.1.0.6.9 Copyright (c) 2009, Oracle Corporation. All rights reserved. UTIL session Oracle Home : /OracleFMW/Middleware_PS1_RC2/oracle_common Central Inventory : /ade/aime_dte6989/oracle/work/EM_SH_1/oraInventory from : /etc/oraInst.loc OPatch version : 11.1.0.6.9 OUI version : 11.1.0.7.0 OUI location : /OracleFMW/Middleware_PS1_RC2/oracle_common/oui Log file location : /OracleFMW/Middleware_PS1_RC2/oracle_common/cfgtoollogs/opatch/opatch2009-12-06_11-04-41AM.log Patch history file: /OracleFMW/Middleware_PS1_RC2/oracle_common/cfgtoollogs/opatch/opatch_history.txt OPatch detects the Middleware Home as "/OracleFMW/Middleware_PS1_RC2" Invoking utility "lsdomains" Domain Name = "MySOAWebCenterDist" Path = "/OracleFMW/MyDomains/domains/MySOAWebCenterDist" Domain Name = "MyWebCenterOnly" Path = "/OracleFMW/MyDomains/domains/MyWebCenterOnly" OPatch command 'lsdomains' done. OPatch succeeded.
This checkApplicable
command produces a list of Oracle homes to which the patch can be applied. For Fusion Middleware, this command is limited in scope to the top-level Middleware home:
If only the Middleware home is specified, OPatch will check to see whether or not this patch can be applied to all Oracle homes within the specified Middleware home.
If an Oracle home is specified in addition to the Middleware home, OPatch will check to see if the patch can be applied to the specified Oracle home in the specified Middleware home.
If neither is specified, and neither the MW_HOME or ORACLE_HOME environment variable is defined, then OPatch will run the command for the Middleware home from where the command was run.
The syntax for the checkApplicable
command is shown below:
opatch checkApplicable [-ph patch_location] [-mw_home MW_HOME] [-oh ORACLE_HOME] [-invPtrLoc path_to_oraInst.loc]
A summary of the options for the checkApplicable
command are described in Table 2-9.
Table 2-9 Options for the OPatch checkApplicable Command
Option | Description |
---|---|
|
Optional - location of the patch for which you want to run the |
|
Optional - absolute path to the Middleware home directory. |
|
Optional - absolute path to the Oracle home directory. |
|
Optional - absolute path to the location of your |
Below is an example of the opatch checkApplicable
command on a UNIX operating system:
[aime@stadn41 Oracle_SOA1]$ ./OPatch/opatch checkapplicable -ph /OracleFMW/Middleware_PS1_RC2/FMWPatches/9991008/ Invoking OPatch 11.1.0.6.9 Oracle Interim Patch Installer version 11.1.0.6.9 Copyright (c) 2009, Oracle Corporation. All rights reserved. UTIL session Oracle Home : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1 Central Inventory : /ade/aime_dte6989/oracle/work/EM_SH_1/oraInventory from : /etc/oraInst.loc OPatch version : 11.1.0.6.9 OUI version : 11.1.0.7.0 OUI location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/oui Log file location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch2009-12-06_10-59-57AM.log Patch history file: /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch_history.txt OPatch detects the Middleware Home as "/OracleFMW/Middleware_PS1_RC2" Invoking utility "checkapplicable" "checkApplicable" passed for Patch "9991008" and Oracle Home "/OracleFMW/Middleware_PS1_RC2/oracle_common". "checkApplicable" failed for Patch "9991008" and Oracle Home "/OracleFMW/Middleware_PS1_RC2/Oracle_SOA1". The details are: Patch 9991008: Required component(s) missing : [ oracle.jrf.j2ee, 11.1.1.2.0 ] , [ oracle.jrf.dms, 11.1.1.2.0 ] "checkApplicable" failed for Patch "9991008" and Oracle Home "/OracleFMW/Middleware_PS1_RC2/Oracle_WC1". The details are: Patch 9991008: Required component(s) missing : [ oracle.jrf.j2ee, 11.1.1.2.0 ] , [ oracle.jrf.dms, 11.1.1.2.0 ] Some of the Oracle Homes under the Middleware Home "/OracleFMW/Middleware_PS1_RC2" have failed this check. OPatch command 'checkApplicable' done. -------------------------------------------------------------------------------- The following warnings have occurred during OPatch execution: 1) OUI-67124:Some of the Oracle Homes under the Middleware Home "/OracleFMW/Middleware_PS1_RC2" have failed this check. -------------------------------------------------------------------------------- OPatch Session completed with warnings. OPatch completed with warnings.
The checkInstalledOneOffs
command checks to see if the specified patch or patches have been applied to certain Oracle homes or WebLogic Domains:
If a Middleware home is specified, OPatch checks all the Oracle homes within the specified Middleware home that are registered with the machine's central inventory. If not specified, then the MW_HOME environment variable is used.
If an Oracle home is specified, OPatch checks the patch against the specified Oracle home only.
If neither is specified, and neither the MW_HOME or ORACLE_HOME environment variable is defined, then OPatch will run the command for the Middleware home from where the command was run.
If a WebLogic Domain is specified, OPatch checks against all the Oracle homes within the specified WebLogic Domain.
The syntax for the checkInstalledOneOffs
command is shown below:
opatch checkInstalledOneOffs -id patch_IDs [-mw_home MW_HOME] [-oh ORACLE_HOME] [-domain domain_name] [-invPtrLoc path_to_oraInst.loc]
A summary of the options for the checkInstalledOneOffs
command are described in Table 2-10.
Table 2-10 Options for the OPatch checkInstalledOneOffs Command
Option | Description |
---|---|
|
ID of the patch or patches that you want to check. Separate multiple patch IDs with a comma (,) character. |
|
Optional - absolute path to the Middleware home directory. |
|
Optional - absolute path to the Oracle home. |
|
Optional - name of the WebLogic Domain. |
|
Optional - absolute path to the location of your |
Below is an example of the opatch checkInstalledOneOffs
command on a UNIX operating system. In this example, patch 8965224 is installed in the SOA Oracle home and patch 9991008 is installed in the Oracle Common Home:
[aime@stadn41 Oracle_SOA1]$ ./OPatch/opatch checkinstalledoneoffs -id 8965224,9991008 Invoking OPatch 11.1.0.6.9 Oracle Interim Patch Installer version 11.1.0.6.9 Copyright (c) 2009, Oracle Corporation. All rights reserved. UTIL session Oracle Home : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1 Central Inventory : /ade/aime_dte6989/oracle/work/EM_SH_1/oraInventory from : /etc/oraInst.loc OPatch version : 11.1.0.6.9 OUI version : 11.1.0.7.0 OUI location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/oui Log file location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch2009-12-06_09-40-41AM.log Patch history file: /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch_history.txt OPatch detects the Middleware Home as "/OracleFMW/Middleware_PS1_RC2" Invoking utility "checkinstalledoneoffs" "checkInstalledOneOffs" failed for Oracle Home "/OracleFMW/Middleware_PS1_RC2/oracle_common". Not Installed Patch IDs: [8965224] "checkInstalledOneOffs" failed for Oracle Home "/OracleFMW/Middleware_PS1_RC2/Oracle_SOA1". Not Installed Patch IDs: [9991008] "checkInstalledOneOffs" failed for Oracle Home "/OracleFMW/Middleware_PS1_RC2/Oracle_WC1". Not Installed Patch IDs: [8965224, 9991008] Some of the Oracle Homes under the Middleware Home "/OracleFMW/Middleware_PS1_RC2" have failed this check. OPatch command 'checkInstalledOneOffs' done. -------------------------------------------------------------------------------- The following warnings have occurred during OPatch execution: 1) OUI-67124:Some of the Oracle Homes under the Middleware Home "/OracleFMW/Middleware_PS1_RC2" have failed this check. -------------------------------------------------------------------------------- OPatch Session completed with warnings. OPatch completed with warnings.
The start
and stop
commands allow Fusion Middleware runtime entities to be started or stopped, respectively. Only entities of the same type can be started or stopped; if you need to start or stop entities of multiple types, you must run this command separately for each entity type.
In order to run this command:
Node Manager must be configured and running on the target server machine.
The WebLogic_Home
/common/nodemanager/nodemanager.domains
(on UNIX operating systems) or WebLogic_Home
\common\nodemanager\nodemanager.domains
(on Windows operating systems) must be populated.
You must be able to connect to the Administration Server, which must be up and running.
The syntax for the start
and stop
commands is shown below:
opatch start|stop -domain domain_name -targets product_entity_name -target_type product_entity_type [-oh ORACLE_HOME]
A summary of the options for the start
and stop
commands are described in Table 2-11.
Table 2-11 Options for the OPatch start and stop Commands
Option | Description |
---|---|
|
The name of the domain in which the specified targets will be started or stopped. |
|
The name of the WebLogic or Fusion Middleware entity you want to start or stop. Only entities of the same type can be specified; multiple entities should be separated by a comma. |
|
The type of WebLogic or Fusion Middleware entity you want to start. Valid values are:
The fmwContainer option starts or stops the container (for example, the WebLogic Server) hosting the application. The fmwServer option starts or stops the actual java process that is running (for example, a Managed Server). |
|
Optional - the absolute path to the Oracle home directory. If this is not specified, the value in the ORACLE_HOME environment variable is used. If neither is available, then the Oracle home from which the command is executed is used. |
Below is an example of the opatch start
command on a UNIX operating system:
[aime@stadn41 Oracle_SOA1]$ ./OPatch/opatch start -targets soa_server1 -target_type fmwserver -domain MySOAWebCenterDist Invoking OPatch 11.1.0.6.9 Oracle Interim Patch Installer version 11.1.0.6.9 Copyright (c) 2009, Oracle Corporation. All rights reserved. UTIL session Oracle Home : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1 Central Inventory : /ade/aime_dte6989/oracle/work/EM_SH_1/oraInventory from : /etc/oraInst.loc OPatch version : 11.1.0.6.9 OUI version : 11.1.0.7.0 OUI location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/oui Log file location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch2009-12-06_12-30-31PM.log Patch history file: /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch_history.txt OPatch detects the Middleware Home as "/OracleFMW/Middleware_PS1_RC2" Invoking utility "start" Please enter the WebLogic Admin Server username:> weblogic Please enter the WebLogic Admin Server password:> Please enter the WebLogic Admin Server URL(t3://stadn41:7011):> [FMW] Performing Start Actions [FMW] Finished Start Actions OPatch command 'start' done. OPatch succeeded.
Below is an example of the opatch stop
command on a UNIX operating system:
[aime@stadn41 Oracle_SOA1]$ ./OPatch/opatch stop -targets soa_server1 -target_type fmwserver -domain MySOAWebCenterDist Invoking OPatch 11.1.0.6.9 Oracle Interim Patch Installer version 11.1.0.6.9 Copyright (c) 2009, Oracle Corporation. All rights reserved. UTIL session Oracle Home : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1 Central Inventory : /ade/aime_dte6989/oracle/work/EM_SH_1/oraInventory from : /etc/oraInst.loc OPatch version : 11.1.0.6.9 OUI version : 11.1.0.7.0 OUI location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/oui Log file location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch2009-12-06_11-13-59AM.log Patch history file: /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch_history.txt OPatch detects the Middleware Home as "/OracleFMW/Middleware_PS1_RC2" Invoking utility "stop" Please enter the WebLogic Admin Server username:> weblogic Please enter the WebLogic Admin Server password:> Please enter the WebLogic Admin Server URL(t3://stadn41:7011):> [FMW] Performing Stop Actions [FMW] Finished Stop Actions OPatch command 'stop' done. OPatch succeeded.
This section describes common issues you may encounter when running the OPatch utility in a Fusion Middleware environment.
For special information about patching the MDS repository, refer to "Understanding the MDS Repository" in the Oracle Fusion Middleware Administrator's Guide.
The machine name of the Administration Server and Managed Servers must be set to a valid value. It cannot be set to blank or None.
The listen address of the Administration and Managed Servers must be set to the real physical host's address (hostname, FQDN, or IP address). It cannot be set to blank or localhost.
These values need to be properly set only once; you will not need to reset them should you ever need to patch your software.
To set the machine name and listed address of the Managed Servers:
Open the Administration Console.
In the Domain Structure, navigate to domain_name > Environments > Machines.
If your WebLogic Server is running in Production Mode, click the Lock & Edit button on the left hand side. If your WebLogic Server is running in Development Mode, this step is not needed.
Click the New button to create a new machine. Specify a name and select the operating system.
Select the machine you just created, go to Configuration > Node Manager and change the Listen Address to the host on which the Node Manager is listening, then click the Save button.
In the Domain Structure, navigate to domain_name > Environments > Servers.
For each Managed Server, assign the machine you just created. In the Listen Address field, specify the name of the host on which the Node Manager is listening. Click Save when you are finished.
If your WebLogic Server is running in Production Mode, click the Activate Changes button on the left hand side. If your WebLogic Server is running in Development Mode, this step is not needed.
To set the machine name and listen address of the Administration Server:
Stop the Administration Server and all Managed Servers.
Back up the config.xml
file in the domain.
The default location of this file is the config
directory inside your Domain home.
Modify the existing config.xml
file as follows:
Find the following line:
<name>AdminServer</name>
Add the following lines:
<machine>host_name</machine> <listen-address>host_name</listen-address>
Save the file.
Restart the Administration Server and all the Managed Servers.
If you encounter any problems, revert back to the saved version of the config.xml
file and contact Oracle Support.