All EBS administrators must become very familiar with the OPatch utility. OPatch is used to patch the ORACLE_HOMEs in EBS Application and Database tiers. Security fixes delivered for these ORACLE_HOMEs through Critical Patch Updates are also applied using OPatch. It updates the central and per-product inventories with the details of each patch applied. Apart from the Oracle Universal Installer (which internally also uses OPatch), this is the only tool authorized to patch ORACLE_HOMEs.
Although it once had a reputation for being somewhat arcane, OPatch has evolved over the years into a more user-friendly and better-documented tool. I'll cover the essentials of using OPatch in this article.
Prerequisites for Running OPatch
OPatch is a set of perl scripts that allow the application and rollback of interim patches to the ORACLE_HOMEs. It requires the Perl language interpreter and requires, at minimum, Perl version 5.005_03 or higher. Version 5.6 or higher is recommended. OPatch expects jar, java, ar, cp, and make commands (depending on the platform) to be available in the current PATH. EBS users have these available as part of the current PATH once the respective tier environment file is sourced.
What Does OPatch Do?
In Oracle E-Business Suite releases where a Rapid Install option is available, the installation process installs and maintains the OUI inventory for each of the ORACLE_HOMEs using OPatch. A query of each of the ORACLE_HOMEs created by a Rapid Install lists the patches installed. OPatch can be used to:
Apply an interim patch
Roll back the application of an interim patch
Detect a conflict when applying an interim patch after previous interim patches have been applied. It also suggests the best options to resolve a conflict.
Oracle Universal Installer
When an installation is performed using the Oracle Universal Installer, the OUI inventory records the ORACLE_HOME, SID, location, products and technology versions installed. The E-Business Suite Rapid Install maintains a global inventory of all its Oracle products. The location on Linux is specified in the /etc/oraInst.loc file. [Editor: Also see: Oracle Universal Installer Inventory Essentials for Apps Sysadmins]
The file on Unix where the inventory location and the OS group of the install user.
This directory stores information about the patches applied.Important OPatch Runtime Options and Arguments
OPatch is located in the
<Path_to_Oracle_Home>/OPatch directory. You can run it with various commands and options. The following string shows the syntax for the OPatch utility:
<Path_to_OPatch>/opatch [-help] [-r[eport]] [command] [-option]
The most commonly-used commands running OPatch are:
1. opatch apply ... This command applies a patch from the patch directory. The OUI inventory is updated with the patch's information.
2. opatch rollback ....
This is the command to rollback or undo a patch installation. The respective patch information is removed from the inventory.
3. opatch lsinventory
lsinventory lists all the patches installed on the Oracle Home.
4. opatch lsinventory -detail
lsinventory -detail gives list of patches and products installed in the ORACLE_HOME.
5. opatch version
version option displays the version of OPatch installed.
6. opatch napply
napply applies the patches in a directory. This is used in EBS environments while applying a patch that is a bundle of individual patches. napply eliminates the overhead of running opatch multiple times by the administrator. The napply option skips subsets or duplicates if they are already installed.
7. opatch nrollback
nrollback rolls back the patches using the IDs specified.
8. opatch apply -minimize_downtime
This is specific to Real Application Clusters (RAC) enabled instances (DB tier patches). The -minimize_downtime option allows you to apply a patch by bringing down one database server instance at a time. OPatch applies the patch to the quiesced server instance, the instance is brought back up, and then OPatch moves on to the next database server in a Real Application Clusters pool.
9. opatch apply -force
-force overrides conflicts with an existing patch by removing the conflicting patch from the system. Caution: This option should be only used when explicitly it is said safe to be used in the README of the patch.
10. opatch apply -invPtrLoc <...>
The option -invPtrLoc can be used to specify the oraInst.loc file in case it's not in the default location e.g., /etc/oraInst.loc in Linux. The argument to this option is the location of this file.
11. opatch query
The query command can be used to find out useful information about the patch Syntax to be used:
opatch query [-all] [-jre <LOC> ] [-oh <LOC> ] \ [-get_component] [-get_os] [-get_date] [-get_base_bug] \ [-is_rolling_patch] [-is_online_patch] \ [-has_sql] [ <Patch Location> ]
Retrieves all information about a patch. This is equivalent to setting all available options.
Retrieves bugs fixed by the patch.
Retrieves components the patch affects.
Retrieves the patch creation date and time.
Indicates true if the patch is an online patch. Otherwise, the option is false.
Indicates true if the patch is a rolling patch. Otherwise, the option is false.
Specifies the Oracle home directory to use instead of the default directory. This takes precedence over the
Indicates the path to the patch location. If you do not specify the location, OPatch assumes the current directory is the patch location.
Where's the Official OPatch Documentation?
A well written User Guide and FAQ are shipped with every OPatch version and are available under the OPatch/doc directory of the ORACLE_HOME. These documents list all the arguments and options available with OPatch. I strongly recommend the administrators who are in charge of applying the patches to carefully read the above documents as well as the ORACLE_HOME version-specific OPatch documentation on Metalink. Latest OPatch versions for 10.1, 10.2 and 11.1 are available for download via Patch 6880880
A New Option For Critical Patch Updates (CPU)
Oracle introduced the napply option in July 2007 with Critical Patch Updates for its DB tier patches on Unix platforms for 10gR2 version 10.2.0.3 and higher. This provides conflict resolution and the ability to merge patches for CPU fixes. This eliminates the CPU merge patch. It also reduces downtime by eliminating the need to rollback and reinstall patches that are already installed. Customers can continue to partial apply and get other security fixes in place while waiting for a merge conflict resolution from Oracle's Database Support team.
Common OPatch Issues
Conflicts Between Patches
Conflicts occur when you try to apply a patch whose fix already been applied through another patch. DBAs are advised NOT to use the -force option with apply as this removes the conflicting fix from the system. All conflicts need to be resolved by contacting Customer Support.
Errors due to Java locations
Make sure that the Java JDK and JRE prerequisites are available in the PATH or provided in command line option. The -jre and -jdk options allow you to specify these explicitly instead of using the ones from ORACLE_HOME. EBS customers generally do not need to specify -jre or -jdk options because sourcing the respective ORACLE_HOME .env file will include the correct jre/jdk locations in the PATH.References
- Oracle Universal Installer and OPatch User's Guide - 11g Release 1 (11.1) for Windows and Unix (Part Number B31207-07)
- OPatch documentation list (Note ID 293369.1)
- Where can I find the latest version of OPatch (Note ID 224346.1)
- Rolling Patch - OPatch support for RAC (Note ID 244241.1)
- Critical Patch Update - Introduction to Database n-apply CPUs (Note ID 438314.1)
- Oracle E-Business Suite Releases 11i and 12 Critical Patch Update Knowledge Document (July 2009) (Note ID 836258.1)