7 Patching Oracle Software with OPatch. OPatch is an Oracle-supplied utility that assists you with the process of applying interim patches to Oracle's software and rolling back interim patches from Oracle's software. This chapter provides information on using OPatch for these purposes.This chapter includes the following topics: About OPatch.
All patches may not be compatible with one another. For example, if a patch has been applied, all the bugs fixed by that patch could reappear after another patch is applied. This is called a conflict situation. OPatch detects such situations and raises an error when a it detects a conflict. This chapter includes the following topics:
Types of Conflicts
OPatch can detect the following types of conflicts:
You can use the
-silent, -force , and -no_bug_superset options in Real Application Clusters. Their expected behavior is described in Table 6–1.
Table 6-1 Truth Table
Patch Conflict Behavior for Apply and Napply
The expected behavior for the Apply and Napply commands is listed in Table 6–2.
Table 6-2 Expected Behavior for Apply and Napply Commands
Patch Conflict Detection and Resolution
OPatch detects and reports any conflicts encountered when applying an interim patch with a previously applied patch. The patch application fails in case of conflicts. You can use the
-force option of OPatch to override this failure. If you specify -force , the installer firsts rolls back any conflicting patches and then proceeds with the installation of the desired interim patch.
You may experience a bug conflict and might want to remove the conflicting patch. This process is known as patch rollback. During patch installation, OPatch saves copies of all the files that were replaced by the new patch before the new versions of these files are loaded, and stores them in $ORACLE_HOME/.patch_storage. These saved files are called rollback files and are key to making patch rollback possible. When you roll back a patch, these rollback files are restored to the system. If you have gained a complete understanding of the patch rollback process, you should only override the default behavior by using the
-force flag. To roll back a patch, execute the following command:
OPatch is an Oracle-supplied utility that assists you with the process of applying interim patches to Oracle's software and rolling back interim patches from Oracle's software. This chapter provides information on using OPatch for these purposes.This chapter includes the following topics:
About OPatch
OPatch is a platform-dependent utility that requires installation of the Oracle Universal Installer.
Patches are a small collection of files copied over to an existing installation. They are associated with particular versions of Oracle products. When applied to the correct version of an installed product, patches result in an upgraded version of the product.
Interim patches are bug fixes available to customers in response to specific bugs. They require a particular base release or patchset to be installed before you can apply them. They generally address specific bugs for a particular customer. These patches are not versioned and are generally available in a future patchset as well as the next product release.
OPatch Features
The OPatch 11.2 utility has the following features:
OPatch supports the following tasks:
Getting Interim Patches
Oracle releases interim patches frequently to fix a bug or a set of bugs. You can get the interim patches by doing the following:
Environment Variables OPatch Uses
OPatch uses the following environment variables:
ORACLE_HOME — Oracle home location.
PATH — Path information.
Requirements for OPatch
The OPatch utility requires the following environment:
Prerequisite Checks for OPatch
Before you invoke OPatch, perform the prerequisite checks described in the following sections.
Checks for Single Instances and Oracle Real Application Clusters
Check ORACLE_HOME and Environment Variable
OPatch verifies if the Oracle home is present. You must ensure that the
ORACLE_HOME environment variable is set to the Oracle home of the product you are trying to patch. Check the respective vendor documentation for details to set the environment variable.
Check for JRE
OPatch requires JRE version 1.4 or higher to work properly.
Check for System Space
When OPatch processes the script for the installation of a patch, it simultaneously generates a Rollback script and saves a copy of every file edited or deleted during the patching. OPatch also backs up the inventory information. Consequently, Oracle recommends that you have sufficient system space to accommodate the patch and the backup information.
Check for Oracle Universal Installer and OPatch Version Compatibility
OPatch 11.2 requires Oracle Universal Installer 11.2 or higher to work properly. If the Oracle Universal Installer version is less than what OPatch requires, OPatch errors out.
Check for Patch Applicable on Operating System
OPatch detects if a particular patch is applicable for an operating system. If it is not applicable, OPatch displays an error message.
Check for System Commands
OPatch supports a set of properties used for various software operations. You can use these properties to control the internal operations of OPatch. By default, OPatch uses the standard Java property format to specify the properties. The following list shows the default properties and their values:
You can specify OPatch properties in the following ways:
Additional Checks for Oracle Real Application Clusters
For Oracle Real Application Clusters, ensure that you perform the following prerequisite checks besides the other checks listed in the preceding section.
Check for User Equivalence
You must ensure that the cluster machines have user equivalence set for the user installing Oracle Clusterware/ Oracle Real Application Clusters. On UNIX, this means
rsh or ssh or both should be set up on the cluster machines. On Windows, this means the same <domain><user> should have administrative privileges on all the cluster machines, and the machines should be a member of the <domain> .
If the user equivalence is set properly, the following command will work properly:
Check for OPatch Lsinventory
Ensure that you are able to invoke the
opatch lsinventory -detail command and are able to see the node information being printed out. If you do not find the node information correctly printed out, you need to update the node list. For more information on updating the node list, see 'Updating the Nodes of a Cluster'.The following example shows the command output for the 134 installed products:
Backup and Recovery Considerations for PatchingError 73 Opatch Windows Oracle Download
Note:
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 if it was backed up. If a backup does not exist, you may have to reinstall the software.
OPatch Utility for OUI-based Oracle Homes
You can run the OPatch utility, located in the
<Path_to_Oracle_Home>/OPatch directory, with various commands and options. The following string shows the syntax for the OPatch utility:
where:
Table 7-1 OPatch OUI-based Commands
To view additional information for any command, use the following command:
If using Perl, use the following command:
To show the full syntax of the -help option, enter opatch -h to view the following display:
Apply Command for OUI-based Oracle Homes
This command applies an interim patch to an Oracle home from the current directory. The
ORACLE_HOME environment variable must be set to the Oracle home to be patched.
Note:
You must have write permission to the files in the Oracle home before using this command. Otherwise, OPatch fails.
Syntax
Use the following syntax for this command:
Options
Table 7-2 lists the options available for this command.
Table 7-2 Apply Options for OUI Patches
Note:
If a patch consists of SQL changes, follow the instructions in the patch readme, which is included with the patch to apply the SQL scripts.
Napply Command for OUI-based Oracle Homes
This command applies interim patches to several Oracle homes at the same time.
Note:
You must have write permission to the files in the Oracle home before using this command. Otherwise, OPatch fails.
Syntax
Use the following syntax for this command:
Examples
Options
Table 7-3 lists the options available for this command.
Table 7-3 Napply Options for OUI Patches
Auto Command for OUI-based Oracle Homes
Ordinarily, an Oracle Clusterware patch requires several manual steps before and after you apply the patch, such as:
The opatch auto command automates all of these tasks for patching the grid infrastructure home and all other applicable RDBMS homes.
Note:
You must have write permission to the files in the Oracle home before using this command. Otherwise, OPatch fails.
Syntax
Use the following syntax for this command:
.. where patch_location is path to the location for the patch. If you do not specify the patch location, the current directory is considered the patch location.
Auto Options
Table 7–4 lists the options available for this command.
Table 7-4 Auto Options for OUI Patches
Examples
Lsinventory Command for OUI-based Oracle Homes
This command lists the inventory for a particular Oracle home, or displays all installations that can be found. This command does not have any required options.
Note:
You must have write permission to the files in the Oracle home before using this command. Otherwise, OPatch fails.
Syntax
Use the following syntax for this command:
The following sections provide examples for the detail, bugs_fixed, and patch desc options. See Table 7–5 for descriptions of the command options.
-detail Option Example
The following example shows the output of
opatch lsinventory -detail for 134 products and one interim patch:
-bugs_fixed Option Example
The following example shows the output of
opatch lsinventory -bugs_fixed asc :
-patch desc Option Example
The following example shows the output of
opatch lsinventory -patch desc :
Lsinventory Options
Table 7–5 describes the options available for the lsinventory command.
Table 7-5 Lsinventory Options for OUI Patches
Query Command for OUI-based Oracle Homes
This command queries a specific patch for specific details. It provides information about the patch and the system being patched.
Note:
You must have write permission to the files in the Oracle home before using this command. Otherwise, OPatch fails.
Syntax
Use the following syntax for this command:
Options
Table 7-6 lists the options available for the Query command.
Table 7-6 Query Options
Rollback Command for OUI-based Oracle Homes
This command removes an existing one-off patch from the appropriate Oracle home directory indicated by the reference ID.
Note:
You must have write permission to the files in the Oracle home before using this command. Otherwise, OPatch fails.
Syntax
Use the following syntax for this command:
Options
Table 7-7 lists the options available for the Rollback command.
Table 7-7 Rollback Options for OUI Patches
Nrollback Command for OUI-based Oracle Homes
This command rolls back interim patches from several Oracle homes at the same time.
Note:
You must have write permission to the files in the Oracle home before using this command. Otherwise, OPatch fails.
Syntax
Use the following syntax for this command:
Example
The following example rolls back patches 1, 2, and 3 that have been installed in the Oracle home:
Options
Table 7-8 lists the options available for this command.
Table 7-8 Nrollback Options for OUI Patches
Version Command for OUI-based Oracle Homes
This command shows the current version number of the OPatch utility. Use the following syntax for this command:
Standalone Patching
Standalone patching is available for Oracle homes that have not been installed using the Oracle Universal Installer. Standalone patching does not have Central Inventory registration, but still generates inventory files for the one-off inventory and future conflict checking. OPatch uses the presence of the OUI directory under
ORACLE_HOME to determine whether it should operate in OUI-based or standalone mode.
The following sections discuss these standalone patching topics:
Unsupported Services for Standalone Patching
Standalone patching provides most of the services that OUI-based patching provides. However, standalone patching does not provide the following services that OUI-based patching provides.
Looking up the component inventory
Standalone OPatch enables you to look up which patches have been applied to a standalone Oracle home, but it does not support looking up product components. For example, if you run
opatch lsinventory on a JDeveloper Oracle Home, OPatch shows a list of patches applied on the home. It does not show which components the home has, however.
Looking up the Central Inventory
You cannot run
opatch lsinventory –all to list all Oracle homes registered on the host (through the Central Inventory repository).
Migrating from standalone to OUI-based patching and vice versa
The assumption is that after you have installed a product as standalone without OUI, it remains standalone. For example, after having installed JDeveloper, you cannot put OUI (through copying or proper installation) onto the Oracle home and expect OPatch to treat the home as an OUI-based Oracle home.
Conversely, the assumption is that after you have installed a product with OUI, it remains OUI-based. For example, after you install Oracle RDBMS, you cannot remove OUI (either by removing or proper deinstallation) and expect OPatch to treat the home as a standalone Oracle home. OPatch will not work properly in this case and will corrupt the home.
Interoperating between standalone and OUI-based patches
Since you cannot migrate a home from standalone to OUI-based and vice versa, OPatch does not support interoperability between standalone and OUI-based Oracle homes.
Seamlessly working on a cloned standalone Oracle home
If you clone a standalone Oracle home S1 to another Oracle home OH2, Opatch will not function properly on the new cloned OH2.
Supporting RAC
OPatch relies on OUI to detect Oracle RAC and propagate files. Hence, standalone OPatch does not support RAC; it does not attempt to detect RAC, and its utility will not work. That is, OPatch always runs as
opatch apply –local . OPatch does not support any patch propagation from one node to another node. Also, standalone OPatch does not support RAC-related utilities such as opatch util runRemoteMake (invokes relink on remote node).
Performing patch set operations
OPatch does not support patch set operations in either standalone or OUI modes. You need to use OUI for patch set operations.
Standalone Patching Requirements
Standalone patching requires the following environment:
All of the required files and directories must exist for OPatch to function correctly. If any of the files are missing, OPatch perceives that the patch has not been applied. You would then have to take corrective action, returning the standalone inventory to a stable state.
OPatch Utility for Standalone Homes
As with OUI-based patching, you can run the OPatch utility, located in the
<Path_to_Oracle_Home>/OPatch directory, with various commands and options. The following string shows the syntax for the OPatch utility:
where:
Table 7-9 lists the commands available for standalone patching.
Table 7-9 OPatch Standalone Commands
The following sections provide the syntax and options for each of these commands.
Apply Command for Standalone OPatch
The Apply command applies an interim patch to a standalone home from the current directory.
Syntax
Use the following syntax for this command:
Options
Table 7-10 lists the options available for the Apply command.
Table 7-10 Apply Options for Standalone Patches
Lsinventory Command for Standalone OPatch
The Lsinventory command lists the inventory for a particular Oracle home, or displays all installations that can be found. This command does not have any required options.
Syntax
Use the following syntax for this command:
Options
Table 7-12 lists the options available for the Lsinventory command.
Table 7-11 Lsinventory Options for Standalone Patches
Query Command for Standalone OPatch
This command queries a specific patch for specific details. It provides information about the patch and the system being patched.
Syntax
Use the following syntax for this command:
Options
Table 7-12 lists the options available for the Query command.
Table 7-12 Query Options
Rollback Command for Standalone OPatch
The Rollback command removes an existing one-off patch from the appropriate Oracle home directory indicated by the reference ID.
Syntax
Use the following syntax for this command:
Options
Table 7-13 lists the options available for the Rollback command.
Table 7-13 Rollback Options for Standalone Patches
Version Command for Standalone OPatch
This command shows the current version number of the OPatch utility. Use the following syntax for this command:
Use Cases
The following sections provide scenarios that administrators can encounter when implementing standalone patching for the following types of operations:
Inventory Operations
The following tables explain the purpose of the use case along with preconditions and the process that occurs during the patching process.
Table 7-14 Getting Patch Information
Table 7-15 Getting Detailed Patch Information
Patching Operations
The following tables explain the purpose of the use case along with preconditions and the process that occurs during the patching process.
Table 7-16 Applying an Interim Patch - Case 1
Table 7-17 Applying an Interim Patch - Case 2
Table 7-18 Applying an Interim Patch - Case 3
Table 7-19 Rolling Back an Applied Interim Patch
Utility Operations
The following tables explain the purpose of the use case along with preconditions and the process that occurs during the patching process.
Table 7-20 Loading an Arbitrary XML File
Table 7-21 Verifying that the Patch is Applied
Schema Patching
There are two types of schema patches:
The following sections discuss these topics:
Schema Patching Options
Table 7-22 shows the schema patching options that OPatch supports for Apply and Rollback:
Table 7-22 Schema Patching Options
Standalone SQL Execution
OPatch provides a utility to run only the SQL scripts to patch specified database instances. Use this utility only when you cannot apply or roll back SQL procedure actions using normal Apply or Rollback sessions.
The syntax for Apply is as follows:
The syntax for Rollback is as follows:
Online Patching
Regular patches typically contain
.o (object) files and/or .a (archive) libraries, and therefore require a relink of the RDBMS binary. Online patches, however, contain .so files, which are dynamic/shared libraries, and do not require a relink of the RDBMS binary. Consequently, since a relink is not needed, you can apply or roll back online patches while the RDBMS instance is running. This simplifies administration, because no downtime is needed, and also results in a much quicker turnaround time for installing or de-installing Online Patches.
A regular RDBMS patch can require many minutes to install, since it requires instance shutdown, a relink, and instance startup. On the other hand, you can install an online patch in just a few seconds.
Online patches are only applicable for Oracle RDBMS and not any other products. Online patches are currently supported on the following Windows and UNIX platforms for version 11.2.0.1.0 and later:
Oracle Real Application Clusters Patching
An Oracle Real Application Clusters environment enables active instances to concurrently execute transactions on a shared database. Patching in an Oracle Real Application Clusters environment is slightly different compared to patching a single node.
Interim Patching using OPatch follows a similar approach as that performed by Oracle Universal Installer to detect Oracle home and nodes of a cluster. OPatch interacts with the Oracle Universal Installer inventory through the Oracle Universal Installer Java SDK. If OPatch detects a cluster, it queries the inventory through Oracle Universal Installer to find the local node name and node list. If your node list is not updated, you can update it by using the
-updateNodeList flag of Oracle Universal Installer. You can bypass remote actions using the -local flag, as shown below:
If you want to specify the local node or remote nodes of an Oracle Real Application Clusters setup to OPatch, you can use the
LOCAL_NODE or REMOTE_NODES session variable and specify the node name(s), as shown below:
If OPatch does not automatically detect Oracle Real Application Clusters or its nodes, you need to investigate the contents of the inventory and ensure that it is complete.
You can patch Oracle Real Application Clusters in three different ways:
The following sections provide detailed information for these types of Oracle Real Application Clusters patching.
All Node Patching
Figure 7–1 shows a basic example of All Node Patching.
Systems A, B, and C are nodes in this cluster. When you perform All Node Patching in this cluster, you bring down systems A, B, and C, apply patches to all these nodes, then bring systems A, B, and C back up again.
Rolling Patching
In Rolling Patching, you shut down each node, apply the patch, then bring up each node again. You do this separately for each node until you patch all nodes in the cluster. This is the most efficient method of applying an interim patch to an Oracle Real Application Clusters setup, because there is absolutely no downtime during the application of patches, as only one system is brought down at any given time. Only some patches can be applied in this mode. The type is generally specified in the patch metadata.
Figure 7–2 shows a basic example of Rolling Patching.
When you perform Rolling Patching in this cluster, the patches are applied in a rolling fashion. You initially bring down system A, apply a patch to it, then bring it back up. You do the same thing for systems B and C.
Minimum Downtime Patching
In Minimum Downtime Patching, the nodes are divided into sets. Initially, you shut down the first set and apply a patch to it. After this, you shut down the second set. You then bring up the first set and apply a patch to the second set. You now bring up the second set. All the nodes in the cluster are now patched. This method leads to less downtime for Oracle Real Application Clusters when both sets are brought down. This mode is executed by using
-minimize_downtime command line option. You can also activate this option from the response file.
Figure 7–3 shows a basic example of Minimum Downtime Patching.
Systems A, B, and C are nodes in this cluster. It is divided into two sets: Set 1 contains systems A and B, and Set 2 contains system C. When you perform Minimum Downtime Patching in this cluster, you shut down Set 1 and apply a patch to it. You now shut down Set 2. Then, you bring up Set 1 and apply a patch to Set 2. After you apply the patch, you bring up Set 2 again. Now both Sets 1 and 2 are patched.
About Patch Conflicts
All patches may not be compatible with one another. For example, if you apply a patch, all the bugs the patch fixes could reappear after you apply another patch. This is called a conflict situation. OPatch detects such situations and raises an error when it detects a conflict.
Types of Conflicts
OPatch can detect the following types of conflicts.
Superset
If all the bugs fixed by a patch in the system are also fixed by the patch to be applied, this patch (the patch to be applied) is considered a superset of the patch already applied. If a bug superset condition is detected, it is not considered an error situation. All the subset patches are removed from the system and the new patch is applied.
Example
Consider the following scenario:
Patch C is considered a superset of Patch A.
Using the -no_bug_superset Flag
If you want OPatch to error out if the current patch bugs-to-fix is a superset or the same as an installed patch bugs-fixed in the Oracle home directory, you can use the
-no_bug_superset flag:
$ OPatch/opatch apply -no_bug_superset <Path_To_Patch>
The following example output shows the message you would see when you use the
-no_bug_superset flag:
Subset
Patches to be applied can be subsets of other patches installed in the Oracle home.
Example
Consider the following scenario:
Patch D is a subset of Patch A.
Using the skip_subset Option
When you want to skip patches formerly applied in the Oracle home that are now subsets of other patches you want to apply now, you can use the
skip_subset option of napply . For example, if you used napply yesterday for patch A that fixed bugs 1 and 2, then you use napply today with the skip_subset option for patch B that fixes bug 1 and patch C that fixes bugs 1, 2, and 3, then subset patch A is skipped, and patch C then becomes a superset of patch A.
Example 7-1 applies all patches under the
<patch_location> directory. OPatch skips duplicate patches and subset patches (patches under <patch_location> that are subsets of patches installed in the Oracle home).
Example 7-2 applies patches 1, 2, and 3 that are under the
<patch_location> directory. OPatch skips duplicate patches and subset patches (patches under <patch_location> that are subsets of patches installed in the Oracle home).
Example 7-2
See the description for the
skip_subset option in Table 7-3 for more information.
Duplicate
A duplicate patch fixes the same set of bugs fixed by another patch. For example, if you applied Patch A that fixed bugs 1, 2 and 3, and now apply Patch B that also fixes bugs 1, 2 and 3, then Patch B is a duplicate of Patch A. A patch is always a duplicate of itself.
Using the skip_duplicate Option
If you specify this option, OPatch removes duplicate patches from the list of patches to be applied. For example, if you used
napply yesterday for Patch A discussed above, then use napply today with the -skip_duplicate option for Patch A and other patches, duplicate Patch A is skipped.
Bug Conflict
A bug conflict occurs if a set of bugs to be fixed by the current interim patch intersects with some bugs already fixed by one or more previously installed interim patches. You must remove the bug conflict before you proceed with the patching by using the
apply command with the -force flag, which rolls back the conflicting patches before applying the new one.
Example
Consider the following scenario:
Patch E conflicts with Patch A.
File Conflict
A file conflict occurs if a set of files to be patched by the current interim patch includes files already patched by one or more previously installed interim patches, and it is not a bug superset.
Example
Consider the following scenario:
Patch F conflicts with Patch A.
Patch Conflict Behavior for Apply and Napply
The expected behavior for the Apply and Napply commands is listed in Table 7-23.
Table 7-23 Expected Behavior for Apply and Napply Commands
Patch Conflict Detection and Resolution
OPatch detects and reports any conflicts encountered when applying an Interim patch with a previously applied patch. The patch application fails in case of conflicts. You can use the
-force option of OPatch to override this failure. If you use this option, the installer first rolls back any conflicting patches and then proceeds with the installation of the desired interim patch.
You may encounter a bug conflict and might want to remove the conflicting patch. This process is known as patch rollback. During patch installation, OPatch saves copies of all the files the new patch replaced before the new versions of these files are loaded and stores them in
$ORACLE_HOME/.patch_storage . These saved files are called Rollback files and are the key to making patch rollback possible. When you roll back a patch, these Rollback files are restored to the system. You should only override the default behavior by using the -force flag if you completely understand the patch Rollback process. To roll back a patch, execute the following command:
$ OPatch/opatch rollback -id <Patch_ID>
Problem Resolution
The following sections provide information and instructions on the following tasks to resolve problems:
Logging and Tracing
Logging and tracing is a common aid for debugging. OPatch maintains logs for all Apply, Rollback, and Lsinventory operations. Each time you execute OPatch, a new log file is created. The log files are located in the
<ORACLE_HOME>/cfgtoollogs/opatch directory. Each log file is tagged with the timestamp of the operation. Log files are named as opatch_<date mm-dd-yyyy>_<time hh-mm-ss>.log .
For example, if a log file is created on May 17th, 2008 at 11.55 PM, it will be named as follows:
Note:
You can set OPatch to debug mode by setting the environment variable OPATCH_DEBUG to TRUE
Command Index
OPatch also maintains an index of the commands executed with OPatch and the log files associated with it in the
history.txt file located in the <ORACLE_HOME>/cfgtoollogs/opatch directory. An example of the history.txt file is as follows:
Levels of Logging
OPatch follows the Oracle Diagnostic Logging (ODL) guidelines. You can set the log level by using the
-logLevel <level> option available. This controls the amount of logging OPatch performs, according to the ODL guidelines.
OPatch supports the following log levels:
Recovering from a Failed Patching Session
During patching, updates can occur in two phases:
The following scenarios for single instance setups and Oracle Real Application Clusters setups explain how you can recover from a failed patching session.
Single Instance Setup
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |