2 Patching Oracle Fusion Middleware with Oracle OPatch

This document describes patching in an Oracle Fusion Middleware environment.
The following topics are covered:

Section 2.1, "About Patching"
Section 2.2, "About OPatch"
Section 2.3, "OPatch in a Fusion Middleware Environment"
Section 2.4, "Running OPatch"
Section 2.5, "Troubleshooting OPatch in a Fusion Middleware Environment"

2.1 About Patching

Patches are a small collection of files copied over to an existing installation. They are associated with particular versions of Oracle products.

2.1.1 Types of Patches That can be Used with OPatch

OPatch can be used for the following types of patches:

A patch set exception (also known as a PSE, one-off, or interim patch)

This is usually a single fix for a single problem. One-offs in ST products (GC, DB/AS Control etc) are packaged and applied via OPatch. One-offs are bug fixes given to customers in critical need and are not cumulative, regressed or versioned. You can use the opatch lsinventory command to see which one-off patches are installed on your system.

A patch bundle (also known as an MLR patch)

This type of patch is created by putting several fixes into a single patch. This is usually done if several fixes are needed and the various interim patches apply to the same modules and cause the prior patch to be removed if applied individually as they can not coexist. Patch bundles are also applied using OPatch and metadata information about them are also kept in a set of XML files in the inventory and manipulated by OPatch.

Security Patches (also known as Critical Patch Updates or CPUs)

Security patches are different from other patch types in that they only fix a single or small number of problems, and that they should be applied as soon as possible – when a security patch is released extra attention is brought to the existence of the security problem. CPUs are periodic security bundles released by Oracle and are very much like interim patches and will be applied just like an interim patch using OPatch. Just like interim patches, CPUs are not versioned.

Patch Set Updates (PSUs)

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.

2.1.2 Types of Patches That can not be Used with OPatch

The only type of patch that cannot be used 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 all patches since the last base release. Patch sets and the Patch Set Assistant are usually applied through OUI-based product specific installers.

2.2 About OPatch

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://download.oracle.com/docs/cd/E11882_01/em.112/e12255/toc.htm

This section contains the following:

Section 2.2.1, "Getting OPatch"
Section 2.2.2, "Getting Patches"
Section 2.2.3, "OPatch Environment Variables"
Section 2.2.4, "OPatch System Requirements"
Section 2.2.5, "Backup and Recovery Considerations for Patching"

2.2.1 Getting OPatch

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.

2.2.2 Getting Patches

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.

2.2.3 OPatch Environment Variables

OPatch uses the environment variables listed in Table 2-1:

Table 2-1 OPatch Environment Variables

Variable	Description
`ORACLE_HOME`	Points to the location of the Oracle home directory.
`MW_HOME`	Points to the location of the Middleware home directory.
`PATH`	Points to the location(s) from which various commands should be run.

2.2.4 OPatch System Requirements

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.

2.2.5 Backup and Recovery Considerations for Patching

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.

2.3 OPatch in a Fusion Middleware Environment

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:

Section 2.3.1, "A Typical Patching Scenario"
Section 2.3.2, "Patching a Fusion Middleware Product"
Section 2.3.3, "Patching in a Distributed Environment"
Section 2.3.4, "Patching Artifacts Deployed Outside the Oracle Home"

2.3.1 A Typical Patching Scenario

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".

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 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.

2.3.2 Patching a Fusion Middleware Product

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.6.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.

2.3.3 Patching in a Distributed Environment

The process to patch in a distributed environment depends on whether or not your Middleware home directory is shared or not shared.

2.3.3.1 Patching with a Local Middleware Home

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."

2.3.3.2 Patching with a Shared Middleware Home

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.

2.3.4 Patching Artifacts Deployed Outside the Oracle 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.

2.4 Running OPatch

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-2.
Valid options for each command are described in the sections that describe each command.

Table 2-2 Commands for the OPatch Utility in a Fusion Middleware Environment

Command	Description
`apply`	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".
`rollback`	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`	Deploy the patch to a WebLogic domain. For details, see Section 2.4.3, "Deploying Patched Artifacts to WebLogic Servers".
`checkApplicable`	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".
`lshomes`	List the Oracle homes that have been used to create WebLogic Domains. For details, see Section 2.4.4, "Listing the Source Oracle Homes".
`lsdomains`	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".
`checkInstalledOneOffs`	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 \| stop`	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

2.4.1 Applying Patches and Deploying Patched Artifacts to WebLogic Servers

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.

2.4.1.1 Using the OPatch Property File

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.

2.4.1.2 Using the -auto Option

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.

2.4.1.2.1 Configuring Node Manager

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.

2.4.1.2.2 Using the -auto Option with the -domain Option

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.

2.4.1.3 Using the apply Command

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:
1. Staged mode applications.
2. 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-3.

Table 2-3 Options for the OPatch apply Command

Option	Description
`-auto [-domain` `domain_name`]	Optional - causes OPatch to automate the rollout of the patch to Oracle Fusion Middleware entities. If `-auto` is used then `-domain` must also be used to indicate the name of the domain in which the rollout should occur; the exception is when there is only one domain configured out of the Oracle home, in which case the `-domain` flag is optional. See Section 2.4.1.2, "Using the -auto Option" for more information.
`-mw_home` `MW_HOME`	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.
`-oh` `ORACLE_HOME`	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.
`-property_file` `name`	Optional - absolute path and name of the property file. See Section 2.4.1.1, "Using the OPatch Property File" for more information.
`-report`	Optional - print out the actions that will be taken by executing the command, but does not actually execute the command.

2.4.1.4 Sample Output for the apply 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 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.

2.4.2 Rolling Back Patches and Deploying Patched Artifacts to WebLogic Servers

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:
1. Staged mode applications.
2. 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-4.

Table 2-4 Options for the OPatch rollback Command

Option	Description
`-id` `patch_id`	Use the `-lsinventory` option to display all applied patch IDs. Each one-off patch is uniquely identified by an ID. To rollback to a previous patch version, that patch version's ID must be supplied.
`-auto [-domain` `domain_name`]	Optional - causes OPatch to automate the rollout of the patch to Oracle Fusion Middleware entities. If `-auto` is used then `-domain` must also be used to indicate the name of the domain in which the rollout should occur; the exception is when there is only one domain configured out of the Oracle home, in which case the `-domain` flag is optional. Refer to Section 2.4.1, "Applying Patches and Deploying Patched Artifacts to WebLogic Servers" for more information.
`-mw_home` `MW_HOME`	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.
`-oh` `ORACLE_HOME`	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.
`-property_file` `name`	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.
`-report`	Optional - print out the actions that will be taken by executing the command, but does not actually execute the command.

2.4.3 Deploying Patched Artifacts to WebLogic Servers

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-5.

Table 2-5 Options for the OPatch deploy Command

Option	Description
`-id` `patch_id`	The unique ID of the patch that is installed in the Oracle home.
`-ph` `patch_location`	The absolute path to the location of the patch. If none is specified, then the current directory is used.
`-auto [-domain` `domain_name`]	Optional - causes OPatch to automate the rollout of the patch to Oracle Fusion Middleware entities. If `-auto` is used then `-domain` must also be used to indicate the name of the domain in which the rollout should occur; the exception is when there is only one domain configured out of the Oracle home, in which case the `-domain` flag is optional. Refer to Section 2.4.1, "Applying Patches and Deploying Patched Artifacts to WebLogic Servers" for more information.
`-mw_home` `MW_HOME`	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.
`-oh` `ORACLE_HOME`	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.
`-property_file` `name`	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.
`-report`	Optional - print out the actions that will be taken by executing the command, but does not actually execute the command.

2.4.4 Listing the Source Oracle Homes

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-6.

Table 2-6 Options for the OPatch lshomes Command

Option	Description
`-domain` `domain_name`	Optional - list the Oracle homes that have been used to create or extend this WebLogic Domain.
`-domain_dir` `domain_location`	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.
`-mw_home` `MW_HOME`	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.
`-invPtrLoc` `path_to_oraInst.loc`	Optional - absolute path to the location of your `oraInst.loc` file; this option is needed if the installation was performed using the `-invPtrLoc` option.

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.

2.4.5 Listing the Domains Created from the Middleware Home or Oracle Home

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-7.

Table 2-7 Options for the OPatch lsdomains Command

Option	Description
`-oh` `ORACLE_HOME`	Optional - absolute path to the Oracle home directory.
`-mw_home` `MW_HOME`	Optional - absolute path to the Middleware home directory.
`-invPtrLoc` `path_to_oraInst.loc`	Optional - absolute path to the location of your `oraInst.loc` file; this option is needed if the installation was performed using the `-invPtrLoc` option.

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.

2.4.6 Listing the Applicable Oracle Homes for a Patch

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-8.

Table 2-8 Options for the OPatch checkApplicable Command

Option	Description
`-ph` `patch_location`	Optional - location of the patch for which you want to run the `checkApplicable` command. If not specified, then the patch in the current directory is used.
`-mw_home` `MW_HOME`	Optional - absolute path to the Middleware home directory.
`-oh` `ORACLE_HOME`	Optional - absolute path to the Oracle home directory.
`-invPtrLoc` `path_to_oraInst.loc`	Optional - absolute path to the location of your `oraInst.loc` file; this option is needed if the installation was performed using the `-invPtrLoc` option.

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.

2.4.7 Listing Patches Applied to an Oracle Home or WebLogic Domain

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-9.

Table 2-9 Options for the OPatch checkInstalledOneOffs Command

Option	Description
`-id` `patch_IDs`	ID of the patch or patches that you want to check. Separate multiple patch IDs with a comma (,) character.
`-mw_home` `MW_HOME`	Optional - absolute path to the Middleware home directory.
`-oh` `ORACLE_HOME`	Optional - absolute path to the Oracle home.
`-domain` `domain_name`	Optional - name of the WebLogic Domain.
`-invPtrLoc` `path_to_oraInst.loc`	Optional - absolute path to the location of your `oraInst.loc` file; this option is needed if the installation was performed using the `-invPtrLoc` option.

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

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.

2.4.8 Starting or Stopping a Runtime Instance

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-10.

Table 2-10 Options for the OPatch start and stop Commands

Option	Description
`-domain` `domain_name`	The name of the domain in which the specified targets will be started or stopped.
`-targets` `product_entity_name`	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.
`-target_type` `target_type`	The type of WebLogic or Fusion Middleware entity you want to start. Valid values are: fmwApplication fmwServer fmwCluster fmwContainer 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).
`-oh` `ORACLE_HOME`	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.

2.5 Troubleshooting OPatch in a Fusion Middleware Environment

This section describes common issues you may encounter when running the OPatch utility in a Fusion Middleware environment.

2.5.1 Notes About Patching the MDS Repository

For special information about patching the MDS repository, refer to "Understanding the MDS Repository" in the Oracle Fusion Middleware Administrator's Guide.

2.5.2 Setting the Machine Name and Listen Address

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:
1. Find the following line:
```
<name>AdminServer</name>
```
2. Add the following lines:
```
<machine>host_name</machine>
<listen-address>host_name</listen-address>
```
3. 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.

Latest Updates

Post Top Ad

28 January, 2013

Patching Oracle Fusion Middleware with Oracle OPatch