OPatch User's Guide 11g Release 1 (11.1) for Windows and UNIX
What is 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.
OPatch is a Java-based utility that requires installation
of the Oracle Universal Installer. It is platform-independent and runs on all
supported operating systems. Another version of OPatch, called standalone
OPatch, is also available. It runs on Oracle homes without 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
·
Scalability — OPatch is scalable to support a large
number of patches.
·
Reliability — OPatch is reliable and protects the
Oracle home and inventory. It can bring back the Oracle home to a stable state
from patch application failures. It can also easily detect patch conflicts.
·
Availability — Opatch's online patching improves
system availability by allowing database patches to be applied without needing
to shut down databases.
·
Portability — OPatch is compatible with all
operating systems for which Oracle releases software.
·
Robust — OPatch is very robust. It is very easy
to apply a patch as well as remove it.
·
Easy to maintain — OPatch is easy to maintain and is also
extensible.
·
Support for Silent Operation — OPatch supports silent operation. This
mode allows you to run the software without any user interaction.
·
Support for Real Application Clusters — OPatch supports Real Application
Clusters and works well in that setup. It is easy to extend it to Enterprise
Manager Grid Control.
·
Easy to debug — OPatch has various levels of logging
and tracing mechanisms. It also has a debug option that helps to easily
diagnose software problems.
OPatch supports
the following tasks:
·
Applying
an interim patch.
·
Rolling
back the application of an interim patch.
·
Detecting
a conflict when applying an interim patch after previous interim patches have
been applied. It also suggests the best options to resolve a conflict.
·
Reporting
on installed products and interim patches.
Getting Interim Patches
Oracle releases interim patches frequently to fix a bug
or a set of bugs. You can get the interim patches by specifying the patch ID in
My Oracle Support (formerly MetaLink) from the following location:
http://www.oracle.com/support/metalink/index.html
Environment Variables OPatch Uses
OPatch uses the following environment variables:
ORACLE_HOME — Oracle home location.
PATH — Path information.
OPATCH_DEBUG — Log level that specifies the amount
of logging OPatch should perform.
Requirements for OPatch
The OPatch utility requires the following environment:
·
The
Oracle home environment variable (
ORACLE_HOME) must point to a valid Oracle home directory and match the
value used during installation of the Oracle home directory.
·
JRE
version 1.4 or higher, Java commands for Windows, and
ar, cp, fuser, and make commands for UNIX must be made available.
·
The
library path must be set correctly for Oracle Real Application Clusters
environments. OPatch uses some APIs to detect if the system is a Real
Application Clusters system. Ensure that the library path is set correctly as
follows:
· For Solaris:
· LD_LIBRARY_PATH = $ORACLE_HOME/lib32:$ORACLE_HOME/lib
·
· For HP-UX:
SHLIB_PATH=$ORACLE_HOME/lib32:/usr/lib
Prerequisite Checks for OPatch
Before you invoke OPatch, perform the prerequisite checks
described in the following sections.
Checks for Single Instances and Real Application Clusters
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.
OPatch requires JRE version 1.4 or higher to work
properly.
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.
OPatch 11.1 requires Oracle Universal Installer 11.1 or
higher to work properly. If the Oracle Universal Installer version is less than
what OPatch requires, OPatch errors out.
OPatch detects if a particular patch is applicable for an
operating system. If it is not applicable, OPatch displays an error message.
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:
fuser=/sbin:/usr/sbin
ar=/usr/ccs/bin/
make=/usr/bin
You can specify
OPatch properties in the following ways:
·
By
using the default OPatch properties.
·
By
specifying the location of the user-defined properties file.
·
By
using the command line. The syntax is as follows:
· PROPERTY_NAME=VALUE
Example:
fuser=/sbin:/usr/sbinAdditional Checks for Real Application Clusters
For 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/ 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:
$ rsh <nodename> date
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,
The following example shows the command output for 118
installed products and SQL, PL/SQL, and online patches:
Invoking OPatch 11.1.0.6.6
Oracle Interim Patch Installer version 11.1.0.6.6
Copyright (c) 2009, Oracle Corporation. All rights reserved.
Oracle Home : /scratch/userid/oracle/product/11.1.0/db_1
Central Inventory : /home/userid/newDB/oraInventory
from : /etc/oraInst.loc
OPatch version : 11.1.0.6.6
OUI version : 11.1.0.6.6
OUI location : /scratch/userid/oracle/product/11.1.0/db_1/oui
Log file location : /scratch/userid/oracle/product/11.1.0/ db_1/cfgtoollogs/opatch/opatch2008-07-17_23-08-20PM.log
Lsinventory Output file location : /scratch/userid/oracle/product/11.1.0/ db_1/cfgtoollogs/opatch/lsinv/lsinventory2008-07-17_23-08-20PM.txt
--------------------------------------------------------------------------------
Installed Top-level Products (1):
Oracle Database 11g 11.1.0.4.0
There are 1 products installed in this Oracle Home.
Installed Products (118):
Agent Required Support Files 10.2.1.3.1
Assistant Common Files 11.1.0.4.0
Bali Share 1.1.18.0.0
Buildtools Common Files 11.1.0.4.0
Character Set Migration Utility 11.1.0.4.0
Database Configuration and Upgrade Assistants 11.1.0.4.0
Database SQL Scripts 11.1.0.4.0
Database Workspace Manager 11.1.0.4.0
Enterprise Edition Options 11.1.0.4.0
Enterprise Manager Agent 10.2.1.3.1
Enterprise Manager Agent Core Files 10.2.1.3.1
Enterprise Manager Common Core Files 10.2.1.3.1
Enterprise Manager Common Files 10.2.1.3.1
Enterprise Manager Database Plugin -- Agent Support 11.1.0.4.0
Enterprise Manager Database Plugin -- Management Service Support 11.1.0.4.0
Enterprise Manager Database Plugin -- Repository Support 11.1.0.4.0
Enterprise Manager Grid Control Core Files 10.2.1.3.1
Enterprise Manager plugin Common Files 11.1.0.4.0
Enterprise Manager Repository Core Files 10.2.1.3.1
Generic Connectivity 11.1.0.4.0
Generic Connectivity Common Files 11.1.0.4.0
HAS Common Files 11.1.0.4.0
HAS Files for DB 11.1.0.4.0
Installation Common Files 11.1.0.4.0
Installer SDK Component 11.1.0.6.6
JAccelerator (COMPANION) 11.1.0.4.0
LDAP Required Support Files 11.1.0.4.0
OLAP SQL Scripts 11.1.0.4.0
Oracle 11g Warehouse Builder Server 11.1.0.4.0
Oracle Advanced Security 11.1.0.4.0
Oracle Application Express 11.1.0.4.0
Oracle Call Interface (OCI) 11.1.0.4.0
Oracle Clusterware RDBMS Files 11.1.0.4.0
Oracle Code Editor 1.2.1.0.0I
Oracle Configuration Manager 10.2.5.0.0
Oracle Containers for Java 11.1.0.4.0
Oracle Core Required Support Files 11.1.0.4.0
Oracle Data Mining RDBMS Files 11.1.0.4.0
Oracle Database 11g 11.1.0.4.0
Oracle Database 11g 11.1.0.4.0
Oracle Database 11g interMedia Files 11.1.0.4.0
Oracle Database User Interface 2.2.13.0.0
Oracle Database Utilities 11.1.0.4.0
Oracle Display Fonts 9.0.2.0.0
Oracle Enterprise Manager Console DB 11.1.0.4.0
Oracle Extended Windowing Toolkit 3.4.42.0.0
Oracle Globalization Support 11.1.0.4.0
Oracle Globalization Support 11.1.0.4.0
Oracle Help For Java 4.2.9.0.0
Oracle Help for the Web 2.0.11.0.0
Oracle Ice Browser 5.2.3.6.0
Oracle interMedia 11.1.0.4.0
Oracle interMedia Annotator 11.1.0.4.0
Oracle interMedia Client Option 11.1.0.4.0
Oracle interMedia Java Advanced Imaging 11.1.0.4.0
Oracle interMedia Locator 11.1.0.4.0
Oracle interMedia Locator RDBMS Files 11.1.0.4.0
Oracle Internet Directory Client 11.1.0.4.0
Oracle Java Client 11.1.0.4.0
Oracle JDBC Server Support Package 11.1.0.4.0
Oracle JDBC/OCI Instant Client 11.1.0.4.0
Oracle JDBC/THIN Interfaces 11.1.0.4.0
Oracle JFC Extended Windowing Toolkit 4.2.36.0.0
Oracle JVM 11.1.0.4.0
Oracle LDAP administration 11.1.0.4.0
Oracle Locale Builder 11.1.0.4.0
Oracle Message Gateway Common Files 11.1.0.4.0
Oracle Net 11.1.0.4.0
Oracle Net Listener 11.1.0.4.0
Oracle Net Required Support Files 11.1.0.4.0
Oracle Net Services 11.1.0.4.0
Oracle Notification Service 10.1.0.3.0
Oracle ODBC Driver 11.1.0.4.0
Oracle ODBC Driverfor Instant Client 11.1.0.4.0
Oracle OLAP 11.1.0.4.0
Oracle OLAP API 11.1.0.4.0
Oracle OLAP RDBMS Files 11.1.0.4.0
Oracle One-Off Patch Installer 11.1.0.6.6
Oracle Partitioning 11.1.0.4.0
Oracle Programmer 11.1.0.4.0
Oracle RAC Required Support Files-HAS 11.1.0.4.0
Oracle Recovery Manager 11.1.0.4.0
Oracle Security Developer Tools 11.1.0.4.0
Oracle Spatial 11.1.0.4.0
Oracle SQL Developer 11.1.0.4.0
Oracle Starter Database 11.1.0.4.0
Oracle Text 11.1.0.4.0
Oracle UIX 2.2.20.0.0
Oracle Ultra Search Common Files 11.1.0.4.0
Oracle Ultra Search Middle-Tier 11.1.0.4.0
Oracle Ultra Search Server 11.1.0.4.0
Oracle Ultra Search Server Rdbms 11.1.0.4.0
Oracle Universal Installer 11.1.0.6.6
Oracle Wallet Manager 11.1.0.4.0
Oracle XML Development Kit 11.1.0.4.0
Parser Generator Required Support Files 11.1.0.4.0
Perl Interpreter 5.8.3.0.6
PL/SQL 11.1.0.4.0
PL/SQL Embedded Gateway 11.1.0.4.0
Platform Required Support Files 11.1.0.4.0
Precompiler Common Files 11.1.0.4.0
Precompiler Required Support Files 11.1.0.4.0
Provisioning Advisor Framework 10.2.1.3.1
RDBMS Required Support Files 11.1.0.4.0
RDBMS Required Support Files for Instant Client 11.1.0.4.0
regexp 2.1.9.0.0
Required Support Files 11.1.0.4.0
Sample Schema Data 11.1.0.4.0
Secure Socket Layer 11.1.0.4.0
Secure Socket Layer 11.1.0.4.0
SQL*Plus 11.1.0.4.0
SQL*Plus Required Support Files 11.1.0.4.0
SQLJ Runtime 11.1.0.4.0
SSL Required Support Files for InstantClient 11.1.0.4.0
Sun JDK 1.5.0.0.6
XDK Required Support Files 11.1.0.4.0
XML Parser for Java 11.1.0.4.0
XML Parser for Oracle JVM 11.1.0.4.0
There are 118 products installed in this Oracle Home.
Interim patches (3) :
Patch 300100 : applied on Tue Jul 10 02:21:40 PDT 2008
Created on 01 Jan 2007, 04:57:12 hrs US/Eastern
Bugs fixed:
300101
Files Touched:
test.pch --> ORACLE_HOME/hpatch/test.pch
Instances Patched:
online, venkat
Patch Location in Inventory:
/scratch/userid/oracle/product/11.1.0/db_1/inventory/oneoffs/300100
Patch Location in Storage area:
/scratch/userid/oracle/product/11.1.0/db_1/.patch_storage/ 300100_Jan_01_2007_04_57_12
Patch 100100 : applied on Thu Jun 21 21:01:35 PDT 2008
Created on 22 Apr 2008, 23:57:54 hrs PST8PDT
Bugs fixed:
100100, 100101
Files Touched:
/shof.o --> ORACLE_HOME/lib/libagent10.a
/oracle/help/AppletWindowManager.class --> ORACLE_HOME/jlib/help4.jar
dbui2.jar --> ORACLE_HOME/jlib/dbui2.jar
DummaDummy.class --> ORACLE_HOME/plsql/DummaDummy.class
Sql scripts Executed:
/scratch/userid/oracle/product/11.1.0/db_1/scripts/2.sql
Sql Procedures Touched:
JAN_300500_1, JAN_300500_2
Patch Location in Inventory:
/scratch/userid/oracle/product/11.1.0/db_1/inventory/oneoffs/100100
Patch Location in Storage area:
/scratch/userid/oracle/product/11.1.0/db_1/.patch_storage/100100_Apr_22_2008_23_57_54
Patch 300500 : applied on Tue Jun 05 03:06:55 PDT 2008
Created on 07 Nov 2007, 04:57:14 hrs US/Eastern
Bugs fixed:
300500, 300501, 300502
Files Touched:
abc1.sql --> ORACLE_HOME/jlib/abc1.sql
abc.sql --> ORACLE_HOME/jlib/abc.sql
Patch Location in Inventory:
/scratch/userid/oracle/product/11.1.0/db_1/inventory/oneoffs/300500
Patch Location in Storage area:
/scratch/userid/oracle/product/11.1.0/db_1/.patch_storage/ 300500_Nov_07_2007_04_57_14
--------------------------------------------------------------------------------
OPatch succeeded.
Backup and Recovery Considerations for Patching
Note:
It is highly recommended that you back
up the
ORACLE_HOME before any patch operation. You can
back up the ORACLE_HOMEusing 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
Note:
OPatch also provides a standalone
method of patching that does not require the Oracle Universal Installer (OUI).
The options for these commands are a subset of those offered here for the
standard method of patching using OUI. For information on standalone patching
and the available options for commands,
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:<Path_to_OPatch>/opatch [-help] [-r[eport]] [command] [-option]
where:
·
help — Displays the help message for the
command.
·
report — Prints the actions without
executing.
·
command — One of the OPatch commands, described
in Table 7-1.
·
option — One of the OPatch command options,
described starting with Table 7-2.
|
Command
|
Description
|
|
apply
|
Installs an interim patch.
|
|
napply
|
Installs n number of patches (hence napply)
|
|
auto
|
Applies Oracle Clusterware
patches. Refer to "Auto Command for OUI-based Oracle Homes" for
more information.
|
|
lsinventory
|
Lists what is currently installed
on the system.
|
|
query
|
Queries a given patch for
specific details.
|
|
rollback
|
Removes an interim patch.
|
|
nrollback
|
Removes n number of patches (hence nrollback).
|
|
version
|
Prints the current version of the
patch tool.
|
To view additional information for any command, use the
following command:
<Path_to_OPatch>/opatch command -help
For Perl, use the following command:
perl opatch.pl command -help
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.
Use the following syntax for this command:
opatch apply [-delay <value> ] [ -force ] [-invPtrLoc <Path to oraInst.loc> ] [-jre <LOC> ] [-local ] [-minimize_downtime ] [-no_bug_superset ] [-no_inventory ] [-oh <ORACLE_HOME> ] [-retry <value> ] [-silent ] [-verbose ] [-no_relink] [-pre <parameters for the pre script in escaped double quotes> [-opatch_pre_end] ] [-post <parameters for the post script in escaped quotes> [-opatch_post_end] ] [-no_sysmod] [-property_file <Path to property file>] [-local_node <Local node name>] [-remote_nodes <List of remote nodes (node1,node2)>] [-connectString <List of connect strings>] [-runSql] [-sqlScript <path of the sql file>] [-ptlSchema <portal schema>] [-ptlPassword <portal password>] [-ptlConnect <portal connect string>] [-init <parameters for the init script in escaped double quotes> [-opatch_init_end] ] [-report]
[<Patch Location>]
Table 7-2 lists
the options available for this command.
|
Option
|
Description
|
|
connectString
|
Specifies the list of database
instances on which the patch needs to be applied. Specify the value for this
option using the following syntax:
SID:User:Passwd:Node
Example:
oracle:dba:dba:mymachine,oracle1:::
The SID is required, but you can
disregard the other parameters if desired, because OPatch provides default
values for them.
Note: If the system is not part of a RAC
setup and you want to patch just the local node, provide the node name as an
empty string.
|
|
delay
|
Specifies how many seconds to
wait before attempting to lock the inventory again for a previous failure.
You can use this option only if you specify the
retry option. |
|
force
|
Removes conflicting patches from
the system. If a conflict exists that prevents the patch from being applied,
you can use this option to apply the patch. OPatch removes all the
conflicting patches before applying the current patch.
|
|
init
|
Passes parameters to the
init script, which executes before
prerequisite checks are run. The values for this option must be enclosed in
double-quotes. |
|
invPtrLoc
|
Specifies the location of the
oraInst.loc file. The invPtrLoc option is needed when this option is
used during installation. Oracle recommends the use of the default Central
Inventory for a platform. |
|
jre
|
Instructs OPatch to use JRE
(Java) from the specified location instead of the default location under the
Oracle home directory.
|
|
local
|
Specifies that OPatch should
patch the local node and update the inventory of the local node. It does not
propagate the patch or inventory update to other nodes.
You can use this option on Oracle
Real Application Clusters environments and non-clustered environments. If an
entire cluster is shut down before patching, you can use this option for
non-rolling patches.
|
|
local_node
|
Tells OPatch the local node for
this cluster. You can use this option on Oracle Real Application Clusters
environments.
|
|
minimize_downtime
|
Specifies the order of nodes that
OPatch should patch.
This option only applies to
Oracle Real Application Clusters environments. You cannot use it with the
-localoption
with a rolling patch. |
|
no_bug_superset
|
Specifies to error out if the
current patch's bugs-to-fix is a superset (or same set) of an installed
patch's bugs-fixed in the Oracle home directory.
|
|
no_inventory
|
Bypasses the inventory for
reading and updates. You cannot use this option with the
local option. This option places the
installation into an unsupported state. |
|
no_relink
|
This option does not perform any
make operations. You can use it during
multiple patch applications and to perform the linking step only once. OPatch
does not keep track of the make operations
it did not perform. You need to make sure to execute OPatch without this
option at the end for compilation. |
|
no_sysmod
|
Specifies that OPatch does not
need to update the files in the system. It only updates the inventory. It
also does not execute the pre and post scripts.
|
|
oh
|
Specifies the Oracle home
directory to use instead of the default. This takes precedence over the
environment variable
ORACLE_HOME. |
|
opatch_init_end
|
Marks the end of the init
options. You use this option with the
init option.
If you do not use this option, everything after init until the end of the command is
passed into init. |
|
opatch_post_end
|
Marks the end of the
post option. You use this option with the post option. If you do not use this
option, everything after post until
the end of the command is passed into post. |
|
opatch_pre_end
|
Marks the end of the
pre options. You use this option with
the pre option.
If you do not use this option, everything after pre until the end of the command is
passed into pre. |
|
Patch
Location
|
Indicates the path to the patch
location. If you do not specify the location, OPatch assumes the current
directory is the patch location.
|
|
post
|
Specifies the parameters to be
passed to the
post script.
This script is executed after the patch is applied. You need to enclose the
values for this option in double-quotes. |
|
pre
|
Specifies the parameters to be
passed to the
pre script.
This script is executed before the patch is applied. You need to enclose the
values for this option in double-quotes. |
|
property_file
|
Specifies the user-defined
property file for OPatch to use. The path to the property file should be
absolute. This property file takes precedence over the one that OPatch
supplies.
|
|
ptlConnect
|
Specifies the connection string
credentials of the portal schema.
|
|
ptlPassword
|
Specifies the password of the
portal schema.
|
|
ptlSchema
|
Specifies the schema of the
portal repository.
|
|
remote_nodes
|
Tells OPatch the list of remote
nodes. You can use this option on Oracle Real Application Clusters
environments. The node names must be separated with commas, but without
spaces.
|
|
report
|
Prints the action to the screen
without executing it.
|
|
retry
|
Tells OPatch how many times it
should retry when there is an inventory lock failure.
|
|
runSql
|
Tells OPatch to run the SQL
script and SQL procedures if they exist in the given patch. For information
on SQL and PL/SQL patching,
|
|
silent
|
Suppresses user interaction, and
defaults any answers to "yes."
|
|
sqlScript
|
Specifies the custom SQL script
that OPatch should run after patching completes. For information on SQL and
PL/SQL patching,
|
|
verbose
|
Prints additional OPatch output
to the screen as well as to the log file.
|
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.
Use the following syntax for this command:
opatch napply [patch_location] [-id comma-separated list of patch IDs] [-delay <value> ] [ -force ] [-invPtrLoc <Path to oraInst.loc> ] [-jdk <LOC> ] [-jre <LOC> ] [ -local ] [-minimize_downtime ] [-no_bug_superset ] [-no_inventory ] [-oh <ORACLE_HOME> ] [-retry <value> ] [-silent ] [-verbose ] [-no_relink] [-pre <parameters for the pre script in escaped double quotes> [-opatch_pre_end] ] [-post <parameters for the post script in escaped double quotes> [-opatch_post_end] ] [-no_sysmod] [ -property_file <Path to property file> ] [ -local_node <Local node name> ] [ -remote_nodes <List of remote nodes (node1,node2)> ] [ -all_nodes ] [ -phBaseFile <Path to the file containing the location of the patches to be applied> ] [-skip_subset] [-skip_duplicate] [-report]
·
The
following example applies all patches under the
<patch_location> directory:· opatch napply <patch_location>
·
The
following example applies patches 1, 2, and 3 that are under the
<patch_location> directory:· opatch napply <patch_location> -id 1,2,3
·
The
following example 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).· opatch napply <patch_location> -skip_subset -skip_duplicate
See the description for the
skip_subset option in Table 7-3 for
more information.
·
The
following example 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).· opatch napply <patch_location> -id 1,2,3 -skip_subset -skip_duplicate
See the description for the
skip_subset option in Table 7-3 for
more information.
Table 7-3 lists
the options available for this command.
|
Option
|
Description
|
|
all_nodes
|
Applies the patch using the
all-node mode.
|
|
delay
|
Specifies how many seconds to
wait before attempting to lock the inventory again for a previous failure.
You can use this option only if you specify the
retry option. |
|
force
|
Removes conflicting patches from
the system. If a conflict exists that prevents the patch from being applied,
you can use this option to apply the patch. OPatch removes all the
conflicting patches before applying the current patch.
|
|
invPtrLoc
|
Specifies the location of the
oraInst.loc file. The invPtrLoc option is needed when this option is
used during installation. Oracle recommends the use of the default Central
Inventory for a platform. |
|
jdk
|
Instructs OPatch to use JDK (jar)
from the specified location instead of the default location under the Oracle
home directory. If you do not specify the
jre option,
JVM is executed from the jdk location. |
|
jre
|
Instructs OPatch to use JRE
(Java) from the specified location instead of the default location under the
Oracle home directory. You cannot specify the
jdk and jre options together. |
|
local
|
Specifies that OPatch should
patch the local node and update the inventory of the local node. It does not
propagate the patch or inventory update to other nodes.
You can use this option on Oracle
Real Application Clusters environments and non-clustered environments. If an
entire cluster is shut down before patching, you can use this option for
non-rolling patches.
|
|
local_node
|
Tells OPatch the local node for
this cluster. You can use this option on Oracle Real Application Clusters
environments.
|
|
minimize_downtime
|
Specifies the order of nodes that
OPatch should patch.
This option only applies to
Oracle Real Application Clusters environments. You cannot use it with the
-localoption
with a rolling patch. |
|
no_bug_superset
|
Specifies to error out if the
current patch's bugs-to-fix is a superset (or same set) of an installed
patch's bugs-fixed in the Oracle home directory.
|
|
no_inventory
|
Bypasses the inventory for
reading and updates. You cannot use this option with the
local option. This option places the
installation into an unsupported state. |
|
no_relink
|
This option does not perform any
make operations. You can use it during
multiple patch applications and to perform the linking step only once. OPatch
does not keep track of the make operations
it did not perform. You need to make sure to execute OPatch without this
option at the end for compilation. |
|
no_sysmod
|
Specifies that OPatch does not
need to update the files in the system. It only updates the inventory. It
also does not execute the pre and post scripts.
|
|
oh
|
Specifies the Oracle home directory
to use instead of the default. This takes precedence over the environment
variable
ORACLE_HOME. |
|
opatch_post_end
|
Marks the end of the
post option. You use this option with the post option. If you do not use this
option, everything after post until
the end of the command is passed into post. |
|
opatch_pre_end
|
Marks the end of the
pre options. You use this option with
the pre option.
If you do not use this option, everything after pre until the end of the command is
passed into pre. |
|
Patch
Location
|
Indicates the path to the patch
location. If you do not specify the location, OPatch assumes the current
directory is the patch location.
|
|
phBaseFile
|
If you do not specify
<patch_location>,
use this option to point OPatch to a file containing a list of patches to be
n-applied. Each line in the file points to a location of a patch. |
|
post
|
Specifies the parameters to be
passed to the
post script.
This script is executed after the patch is applied. You need to enclose the
values for this option in double-quotes. |
|
pre
|
Specifies the parameters to be
passed to the
pre script.
This script is executed before the patch is applied. You need to enclose the
values for this option in double-quotes. |
|
property_file
|
Specifies the user-defined
property file for OPatch to use. The path to the property file should be
absolute. This property file takes precedence over the one that OPatch
supplies.
|
|
remote_nodes
|
Tells OPatch the list of remote
nodes. You can use this option on Oracle Real Application Clusters
environments. The node names must be separated with commas, but without
spaces.
|
|
report
|
Prints the action to the screen
without executing it.
|
|
retry
|
Tells OPatch how many times it
should retry when there is an inventory lock failure.
|
|
silent
|
Suppresses user interaction, and
defaults any answers to "yes."
|
|
skip_duplicate
|
Skips patches to be applied that
are duplicates of other patches installed in the Oracle home. Two patches are
duplicates if they fix the same set of bugs.
|
|
skip_subset
|
Skips patches to be applied that
are subsets of other patches installed in the Oracle home. One patch is a
subset of another patch if the former fixes a subset of bugs fixed by the
latter.
For example, if you used
napply yesterday for patch A that fixed
bugs 1 and 2, then you use napply today with this 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. |
|
verbose
|
Prints additional OPatch output
to the screen as well as to the log file.
|
Auto Command for OUI-based Oracle Homes
Ordinarily, a Clusterware patch requires several manual
steps before and after you apply the patch, such as:
·
Stopping
all dependent databases
·
Stopping
Clusterware resources
·
Running
pre-patch scripts
·
Shutting
down Clusterware
·
Running
post-patch scripts
·
Starting
Clusterware and dependent databases
The opatch auto command automates all of these tasks for
patching the CRS home and all other applicable RDBMS homes.
Use the following syntax for this command:
<path_to_Opatch>/opatch auto [-rollback [patch_location]] [[patch_location]-oh <path_to_oracle_home1>,<path_to_oracle_home2>...] | [[patch_location]-och <path_to_crs_home>]
... 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.
Table 7–4 lists the options available for this
command.
|
Option
|
Description
|
|
rollback
|
Rolls back the patch rather than
applying it.
|
|
oh
|
Comma-separated Oracle homes to
patch. The default is all applicable Oracle homes. Use this option to patch
RDBMS homes where no database is registered.
|
|
och
|
Path of the Oracle Clusterware
home. Use this option to patch only Oracle Clusterware homes where Oracle
Clusterware has been stopped already. Do not use this option for Oracle
Clusterware with a CRS stack that is up.
|
·
The
following example applies a patch with an unzipped patch location to all
applicable Oracle homes on the system:
· opatch auto <patch_location>
·
The
following example rolls back the patch from all the applicable Oracle homes on
the system:
· opatch auto -rollback <patch_location>
·
The
following example patches a selective list of Oracle homes:
· opatch auto <patch_location> -oh /tmp/oh1,/tmp/oh2,/tmp/oh3
·
The
following example only patches the CRS home when the Oracle Clusterware stack
is down.
· opatch auto <patch_location> -och /tmp/ora_crs_home
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.
Use the following syntax for this command:
opatch lsinventory [-all ][-all_nodes]
[-bugs_fixed asc|desc]
[-delay <value> ][-detail]
[-group_by_date]
[-invPtrLoc <Path to oraInst.loc> ][-jre <LOC> ]
[-oh <ORACLE_HOME> ]
[-patch asc|desc]
[-property_file <path to property file>]
[-retry <value> ]
See Table 7–5 for descriptions of the command
options.
The following example shows the output of
opatch lsinventory -detail:Oracle interim Patch Installer version 11.1.0.6.6
Copyright (c) 2009, Oracle Corporation. All rights reserved..
Oracle Home : /home/oracle_TEST/product/11.1.0/db_1
Central Inventory : /home/OUIHome_Opatch
from : /home/oracle_TEST/product/11.1.0/db_1/oraInst.loc
OPatch version : 11.1.0.6.6
OUI version : 11.1.0.6.6
OUI location : /home/oracle_TEST/product/11.1.0/db_1/oui
Log file location : /home/oracle_
TEST/product/11.1.0/db1/cfgtoollogs/opatch/opatch-2008_May_25_11-09-34-IST_Wed.log
Patch history file: /scratch/userid/newDB/cfgtoollogs/opatch/opatch_history.txt
Lsinventory Output file location : /home/oracle_TEST/product/11.1.0/db_
1/cfgtoollogs/opatch/lsinv/lsinventory-2008_May_25_11-09-34-IST_Wed.txt
--------------------------------------------------------------------------------
Installed Top-level Products (1):
Oracle Database 11g 11.1.0.6.6
There are 1 products installed in this Oracle Home.
Installed Products (10):
Agent Required Support Files 11.1.0.6.6
Assistant Common Files 11.1.0.6.6
Bali Share 1.1.18.0.0
Buildtools Common Files 11.1.0.6.6
Character Set Migration Utility 11.1.0.6.6
Database Configuration and Upgrade Assistants 11.1.0.6.6
Database SQL Scripts 11.1.0.6.6
Database Workspace Manager 11.1.0.6.6
DBJAVA Required Support Files 11.1.0.6.6
Enterprise Edition Options 11.1.0.6.6
There are 10 products installed in this Oracle Home.
Intermin patches (1) :
Patch 111000 : applied on Mon May 23 19:44:08 IST 2008
Created on 27 Jul 2007, 05:43:46 hrs PST8PDT
Bugs fixed: 111000
Files Touched:
/qmtest.o --> ORACLE_HOME/lib/libserver11.a
libmapsym.so --> ORACLE_HOME/lib/libmapsym.so
ins_rdbms.mk --> ORACLE_HOME/rdbms/lib/ioracle
/oracle/xml/jaxb/orajaxb.class --> ORACLE_HOME/lib/xml.jar
Patch Location in Inventory:
/home/oracle_TEST/product/11.1.0/db_1/inventory/oneoffs/111000
Patch Location in Storage area:
/home/oracle_TEST/product/11.1.0/db_1/.patch_storage/111000_Jul_27_2007_05_43_46
--------------------------------------------------------------------------------
OPatch succeeded.
The following example shows the output of
opatch lsinventory -bugs_fixed asc:Oracle interim Patch Installer version 11.1.0.6.6
Copyright (c) 2009, Oracle Corporation. All rights reserved..
Oracle Home : /home/oracle_TEST/product/11.1.0/db_1
Central Inventory : /home/OUIHome_Opatch
from : /home/oracle_TEST/product/11.1.0/db_1/oraInst.loc
OPatch version : 11.1.0.6.6
OUI version : 11.1.0.6.6
OUI location : /home/oracle_TEST/product/11.1.0/db_1/oui
Log file location : /home/oracle_
TEST/product/11.1.0/db1/cfgtoollogs/opatch/opatch-2008_May_25_11-09-34-IST_Wed.log
Patch history file: /scratch/userid/newDB/cfgtoollogs/opatch/opatch_history.txt
Lsinventory Output file location : /home/oracle_TEST/product/11.1.0/db_
1/cfgtoollogs/opatch/lsinv/lsinventory-2008_May_25_11-09-34-IST_Wed.txt
--------------------------------------------------------------------------------
Installed Top-level Products (2):
Oracle Database 11g 11.1.0.6.6
Oracle Database 11g Release 2 Patch Set 2 11.1.0.6.6
There are 2 products installed in this Oracle Home.
List of Bugs fixed by Installed Patches:
Bug Fixed by Installed at Description
Patch
--- -------- ------------ -----------
1000000 6079591 Mon Oct 13 02:03:42 PDT 2008 test bug
6079591 6079591 Mon Oct 13 02:03:42 PDT 2008 MLR BUG FOR 10.2.0:.3 FOR CPU:JUL2:007
300500 300500 Fri Sep 05 02:25:34 PDT 2008 Demo bug for patching files
300501 300500 Fri Sep 05 02:25:34 PDT 2008 Demo bug for patching files
300502 300500 Fri Sep 05 02:25:34 PDT 2008 Demo bug for patching files
6121268 6121268 Tue Aug 19 23:32:33 PDT 2008 DB-10.2.0.3-MOLECULE-007-CPUJUL2007
6121266 6121266 Tue Aug 19 23:32:27 PDT 2008 DB-10.2.0.3-MOLECULE-018-CPUJUL2007
6121264 6121264 Tue Aug 19 23:32:22 PDT 2008 DB-10.2.0.3-MOLECULE-017-CPUJUL2007
6121263 6121263 Tue Aug 19 23:32:14 PDT 2008 DB-10.2.0.3-MOLECULE-016-CPUJUL2007
.....
.....
(Middle section of report is intentionally excluded.)
.....
.....
6121248 6650096 Tue Feb 12 05:50:48 PST 2008 DB-10.2.0.3-MOLECULE-015-CPUJUL2007
6650096 6650096 Tue Feb 12 05:50:48 PST 2008 DB-10.2.0.3-MOLECULE-036-CPUJAN2008
6121247 6650095 Tue Feb 12 05:50:41 PST 2008 DB-10.2.0.3-MOLECULE-006-CPUAPR2007
6397946 6650095 Tue Feb 12 05:50:41 PST 2008 DB-10.2.0.3-MOLECULE-031-CPUOCT2007
6650095 6650095 Tue Feb 12 05:50:41 PST 2008 DB-10.2.0.3-MOLECULE-035-CPUJAN2008
6650081 6650081 Tue Feb 12 05:50:35 PST 2008 DB-10.2.0.3-MOLECULE-034-CPUJAN2008
6646853 6646853 Tue Feb 12 05:50:28 PST 2008 MLR BUG FOR 10.2.0.3 FOR CPUJAN2008
6452863 6452863 Tue Feb 12 05:50:12 PST 2008 TRACKING BUG FOR CPUJUL2007
--------------------------------------------------------------------------------
OPatch succeeded.
The following example shows the output of
opatch lsinventory -patch desc:Oracle interim Patch Installer version 11.1.0.6.6
Copyright (c) 2009, Oracle Corporation. All rights reserved..
Oracle Home : /home/oracle_TEST/product/11.1.0/db_1
Central Inventory : /home/OUIHome_Opatch
from : /home/oracle_TEST/product/11.1.0/db_1/oraInst.loc
OPatch version : 11.1.0.6.6
OUI version : 11.1.0.6.6
OUI location : /home/oracle_TEST/product/11.1.0/db_1/oui
Log file location : /home/oracle_
TEST/product/11.1.0/db1/cfgtoollogs/opatch/opatch-2008_May_25_11-09-34-IST_Wed.log
Patch history file: /scratch/userid/newDB/cfgtoollogs/opatch/opatch_history.txt
Lsinventory Output file location : /home/oracle_TEST/product/11.1.0/db_
1/cfgtoollogs/opatch/lsinv/lsinventory-2008_May_25_11-09-34-IST_Wed.txt
--------------------------------------------------------------------------------
Interim patches (39) :
Patch 6079591 : applied on Mon Oct 13 02:03:42 PDT 2008
Created on 21 Jun 2008, 03:42:18 hrs PST8PDT
Bugs fixed:
6079591, 1000000
Patch 300500 : applied on Fri Sep 05 02:25:34 PDT 2008
Created on 07 Nov 2007, 04:57:14 hrs US/Eastern
Bugs fixed:
300500, 300501, 300502
--------------------------------------------------------------------------------
OPatch succeeded.
Table 7-5 lists
the options available for this command.
|
Option
|
Description
|
|
all
|
Reports the name and installation
directory for each Oracle home directory found.
|
|
all_nodes
|
Reports the patches installed on
the given Oracle home in all nodes of the RAC system. It also prints the
Oracle binary's size and checksum on all nodes. You cannot use this option
with the
all, detail, or patchoptions. |
|
bugs_fixed
|
Reports bugs fixed by installed
patches in a tabular format. Besides the bugs fixed, the report also displays
the installed patches, installed times, and bug descriptions. The fixed bugs
are sorted per installed patch. Default display is patches in descending
order based on installed time and ascending order of bugs within each patch.
You can use 'asc' (or) 'desc' with this option to enforce sort order on bugs
within each patch.
You can use this option with the
patch or patch_id option to obtain sort orders with installed patches.
|
|
delay
|
If you specify retry, this option
tells OPatch how many seconds it should wait before attempting to lock the
inventory again in case of a previous failure.
|
|
detail
|
Reports the installed products
and other details. You cannot use this option with the
all option. |
|
group_by_date
|
Instructs OPatch to group all
installed patches by the date they were installed in the Oracle home.
|
|
invPtrLoc
|
Locates the
oraInst.loc file. You need this option if you
used the invPtrLoc option during installation. Oracle
recommends the use of the default Central Inventory for a platform. |
|
jre
|
Specifies the location of a
particular JRE (Java) for OPatch to use instead of the default location under
the Oracle home directory.
|
|
oh
|
Specifies the Oracle home
directory to use instead of the default directory. This takes precedence over
the
ORACLE_HOME environment variable. |
|
patch
|
Lists the patch IDs installed in
the Oracle home in ascending (asc) or descending (desc) order, which is the
default, based on installed time.
|
|
property_file
|
Indicates the user-defined
property file that OPatch should use. The path to the property should be
absolute. This property file takes precedence over the property file that
OPatch supplies.
|
|
retry
|
Specifies how many times OPatch
should retry when there is an inventory lock failure.
|
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.
Use the following syntax for this command:
opatch query [-all] [-jre <LOC> ] [-oh <LOC> ] [-get_component] [-get_os] [-get_date] [-get_base_bug] [-is_portal_patch] [-is_rolling_patch] [-is_online_patch] [-has_sql] [ <Patch Location> ]
Table 7-6 lists
the options available for the Query command.
|
Option
|
Description
|
|
all
|
Retrieves all information about a
patch. This is equivalent to setting all available options.
|
|
get_base_bug
|
Retrieves bugs fixed by the
patch.
|
|
get_component
|
Retrieves components the patch
affects.
|
|
get_date
|
Retrieves the patch creation date
and time.
|
|
has_sql
|
Indicates true if the patch has
SQL-related actions. Otherwise, the option is false. For information on SQL
and PL/SQL patching,
|
|
is_online_patch
|
Indicates true if the patch is an
online patch. Otherwise, the option is false.
|
|
is_portal_patch
|
Indicates true if the patch has
portal actions. Otherwise, the option is false.
|
|
is_rolling_patch
|
Indicates true if the patch is a
rolling patch. Otherwise, the option is false.
|
|
oh
|
Specifies the Oracle home
directory to use instead of the default directory. This takes precedence over
the
ORACLE_HOME environment variable. |
|
Patch
Location
|
Indicates the path to the patch
location. If you do not specify the location, OPatch assumes the current
directory is the patch location.
|
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.
Use the following syntax for this command:
opatch rollback -id <ID> [-ph <Patch Location>] [-delay <value>]
[-invPtrLoc <Path to oraInst.loc> ]
[-jre <LOC> ] [-local] [-oh <ORACLE_HOME>]
[-retry <value>] [-silent] [-verbose]
[-no_relink] [-pre <parameters for the pre
script in escaped double quotes> [-opatch_pre_end] ]
[-post <parameters for the post script in escaped
double quotes>[ -opatch_post_end] ] [-no_sysmod]
[-property_file <path to property file>]
[-local_node <Local node name>]
[-remote_nodes <List of remote nodes (node1,node2)>]
[-connectString <List of connect strings>]
[-ptlSchema <portal schema>] [-ptlPassword <portal password>]
[-ptlConnect <portal connect string>]
[-runSql] [-sqlScript <path of the sql file>]
[-init <parameters for the init script in escaped double
quotes> [-opatch_init_end] ] [-report]
Table 7-7 lists
the options available for the Rollback command.
|
Option
|
Description
|
|
all_nodes
|
Rolls back the patch using the
all-nodes mode.
|
|
connectString
|
Specifies the list of database
instances on which the patch needs to be applied. Specify the value for this
option using the following syntax:
SID:User:Passwd:Node
Example:
oracle:dba:dba:mymachine,oracle1:::
The SID is required, but you can
disregard the other parameters if desired, because OPatch provides default
values for them.
Note: If the system is not part of a RAC
setup and you want to patch just the local node, provide the node name as an
empty string.
|
|
delay
|
If you use the
retry option with the rollback command, specifies how many seconds
OPatch should wait before attempting to lock the inventory again if a
previous failure occurs. |
|
id
|
Indicates the patch to be rolled
back. Use the
lsinventory option to display all patch
identifiers. Each one-off patch is indicated by its ID. To successfully roll
back a patch, you must provide the patch identifier. |
|
init
|
Passes parameters to the init
script, which executes before prerequisite checks are run. The values for
this option must be enclosed in double-quotes.
|
|
invPtrLoc
|
Specifies the location of the
oraInst.loc file. You need to use this option if
you used the invPtrLoc option during installation. Oracle
recommends the use of the default Central Inventory for a platform. |
|
jre
|
Specifies the location of a
particular JRE (Java) for OPatch to use instead of the default location under
the Oracle home directory.
|
|
local
|
Specifies that OPatch roll back
the local node, then update the inventory of the local node. It does not
propagate the patch or inventory update to other nodes.
You can use this option on Oracle
Real Application Clusters environments and non-clustered environments. If an
entire cluster is shut down before patching, you can use this option for
non-rolling patches.
|
|
local_node
|
Specifies to OPatch that this is
the local node for the cluster to be used for rollback.
You can use this option for
Oracle Real Application Clusters environments.
|
|
no_sysmod
|
Specifies that OPatch need not
update the files in the system, only the inventory. It also does not execute
the pre and post scripts.
|
|
no_relink
|
This option does not perform any
make operation in the patch. You can use
this option during multiple patch removals and to perform the compilation
step only once. |
|
oh
|
Specifies the Oracle home
directory to use instead of the default directory. This takes precedence over
the
ORACLE_HOME environment variable. |
|
opatch_init_end
|
Marks the end of the
init options. Use this option with the init option. If you do not use this option,
everything after init until
the end of the command is passed into init. |
|
opatch_post_end
|
Marks the end of the
post options. Use this option with the post option. If you do not use this
option, everything after post until
the end of the command is passed into post. |
|
opatch_pre_end
|
Marks the end of the
pre options. Use this option with the pre option. If you do not use this
option, everything after pre until
the end of the command is passed into pre. |
|
Patch
Location
|
Indicates the path to the patch
location. If you do not specify the location, OPatch assumes the current
directory is the patch location.
|
|
ph
|
Specifies the valid patch
directory area. Rollback uses the command types found in the patch directory
to identify which commands are used for the current operating system.
|
|
post
|
Specifies the parameters to be
passed inside the
post script.
This script executes after the patch is removed. You must enclose the value
of this option in double-quotes. |
|
pre
|
Specifies the parameters to be
passed inside the
pre script.
This script executes before the patch is removed. You must enclose the value
of this option in double-quotes. |
|
property_file
|
Specifies the user-defined
property file for OPatch to use. The path to the property file should be
absolute. This property file takes precedence over the one that OPatch
supplies.
|
|
ptlConnect
|
Specifies the connection string
credentials of the portal schema.
|
|
ptlSchema
|
Specifies the schema of the
portal repository.
|
|
ptlPassword
|
Specifies the password of the
portal schema.
|
|
remote_nodes
|
Specifies to OPatch the list of
remote nodes to be used for rollback of the patch. The node names must be
separated with commas, but without spaces.
You can use this option on Oracle
Real Application Clusters environments.
|
|
report
|
Prints the actions to the screen
without executing them.
|
|
retry
|
Instructs OPatch how many times
it should retry when there is an inventory lock failure.
|
|
runSql
|
Instructs OPatch to run the SQL
script and SQL procedures if they exist in the given patch. For information
on SQL and PL/SQL patching,
|
|
sqlScript
|
Specifies the custom SQL script
that OPatch should run after patching completes. For information on SQL and
PL/SQL patching,
|
|
silent
|
Suppresses user interaction, and
defaults any yes|no questions to "yes". A Real Application Clusters
setup does not support this option.
|
|
verbose
|
Prints additional OPatch output
to the screen as well as to the log file.
|
Nrollback Command for OUI-based Oracle Homes
This command rolls back interim patches from several
Oracle homes at the same time.
Use the following syntax for this command:
opatch nrollback -id <comma-separated list of patch IDs> [-delay <value>] [-invPtrLoc <Path to oraInst.loc> ] [-jdk <LOC> ] [-jre <LOC> ] [-local] [-minimize_downtime] [-no_relink] [-oh <ORACLE_HOME> ] [-retry <value>] [-silent] [-verbose] [-pre <parameters for the pre script in escaped double quotes> [-opatch_pre_end] ] [-post <parameters for the post script in escaped double quotes>[ -opatch_post_end] ] [-no_sysmod] [-property_file <Path to property file>] [-local_node <Local node name>] [-remote_nodes <List of remote nodes (node1,node2)>] [ -all_nodes ] [-report]
The following example rolls back patches 1, 2, and 3 that
have been installed in the Oracle home:
opatch nrollback -id 1,2,3
Table 7-8 lists
the options available for this command.
|
Option
|
Description
|
|
all_nodes
|
Rolls back the patch using the
all-nodes mode.
|
|
delay
|
If you use the
retry option with the rollback command, specifies how many seconds
OPatch should wait before attempting to lock the inventory again if a
previous failure occurs. |
|
id
|
Indicates the patch to be rolled
back. Use the
lsinventory option to display all patch
identifiers. Each one-off patch is indicated by its ID. To successfully roll
back a patch, you must provide the patch identifier. |
|
invPtrLoc
|
Specifies the location of the
oraInst.loc file. You need to use this option if
you used the invPtrLoc option during installation. Oracle
recommends the use of the default Central Inventory for a platform. |
|
jdk
|
Instructs OPatch to use JDK (jar)
from the specified location instead of the default location under the Oracle
home directory. If you do not specify the
jre option,
JVM is executed from the jdk location. |
|
jre
|
Specifies the location of a
particular JRE (Java) for OPatch to use instead of the default location under
the Oracle home directory.
|
|
local
|
Specifies that OPatch roll back
the local node, then update the inventory of the local node. It does not
propagate the patch or inventory update to other nodes.
You can use this option on Oracle
Real Application Clusters environments and non-clustered environments. If an
entire cluster is shut down before patching, you can use this option for
non-rolling patches.
|
|
local_node
|
Specifies to OPatch that this is
the local node for the cluster to be used for rollback.
You can use this option for
Oracle Real Application Clusters environments.
|
|
minimize_downtime
|
Specifies the order of nodes that
OPatch should patch.
This option only applies to
Oracle Real Application Clusters environments. You cannot use it with the
-localoption
with a rolling patch. |
|
no_sysmod
|
Specifies that OPatch need not
update the files in the system, only the inventory. It also does not execute
the pre and post scripts.
|
|
no_relink
|
This option does not perform any
make operation in the patch. You can use
this option during multiple patch removals and to perform the compilation
step only once. |
|
oh
|
Specifies the Oracle home
directory to use instead of the default directory. This takes precedence over
the
ORACLE_HOME environment variable. |
|
opatch_post_end
|
Marks the end of the
post options. Use this option with the post option. If you do not use this
option, everything after post until
the end of the command is passed into post. |
|
opatch_pre_end
|
Marks the end of the
pre options. Use this option with the pre option. If you do not use this
option, everything after pre until
the end of the command is passed into pre. |
|
Patch
Location
|
Indicates the path to the patch
location. If you do not specify the location, OPatch assumes the current
directory is the patch location.
|
|
property_file
|
Specifies the user-defined
property file for OPatch to use. The path to the property file should be
absolute. This property file takes precedence over the one that OPatch
supplies.
|
|
remote_nodes
|
Specifies to OPatch the list of
remote nodes to be used for rollback of the patch. The node names must be
separated with commas, but without spaces.
You can use this option on Oracle
Real Application Clusters environments.
|
|
report
|
Prints the actions to the screen
without executing them.
|
|
retry
|
Instructs OPatch how many times
it should retry when there is an inventory lock failure.
|
|
silent
|
Suppresses user interaction, and
defaults any yes|no questions to "yes". A Real Application Clusters
setup does not support this option.
|
|
verbose
|
Prints additional OPatch output
to the screen as well as to the log file.
|
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:
<Path_to_OPatch>/opatch version
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 requirements
·
OPatch
commands for standalone patching
·
Use
cases
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.
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.
You cannot run
opatch lsinventory –all to list all Oracle homes registered on
the host (through the Central Inventory repository).
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.
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.
If you clone a standalone Oracle home S1 to another
Oracle home OH2, Opatch will not function properly on the new cloned OH2.
OPatch relies on OUI to detect 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).
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:
·
JRE
version 1.4 or later
·
Oracle
home without OUI
·
OPatch
that supports standalone patching
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:<Path_to_OPatch>/opatch [-help] [-r[eport]] [command] [-option]
where:
·
help — Displays the help message for the
command.
·
report — Prints the actions without
executing.
·
command — One of the OPatch commands.
·
option — One of the OPatch command options.
Table 7-9 lists
the commands available for standalone patching.
|
Command
|
Description
|
|
apply
|
Installs
an interim patch.
|
|
lsinventory
|
Lists
what is currently installed on the system.
|
|
query
|
Queries
a given patch for specific details.
|
|
rollback
|
Removes
an interim patch..
|
|
version
|
Prints
the current version of the patch tool.
|
The following sections provide the syntax and options for
each of these commands.
Apply Command for Standalone OPatch
Use the following syntax for this command:
opatch apply [ -force ] [-jre <LOC> ] [-no_bug_superset ] [-no_inventory ] [-oh <ORACLE_HOME> ][-silent ][-verbose ] [-no_relink] [-pre <parameters for the pre script in escaped double quotes> [-opatch_pre_end] ] [-post <parameters for the post script in escaped quotes> [-opatch_post_end] ] [-no_sysmod] [-property_file <Path to property file>] [-init <parameters for the init script in escaped double quotes> [-opatch_init_end] ] [-report] [<Patch Location>]
Table 7-10 lists
the options available for the Apply command.
|
Option
|
Description
|
|
force
|
Removes conflicting patches from
the system by enabling you to change the product and version number of the
standalone Oracle home. OPatch removes all the conflicting patches before
applying the current patch.
|
|
init
|
Passes parameters to the
init script, which executes before
prerequisite checks are run. The values for this option must be enclosed in
double-quotes. |
|
jre
|
Instructs OPatch to use JRE
(Java) from the specified location instead of the default location under the
Oracle home directory.
|
|
no_bug_superset
|
Specifies to error out if the
current patch's bugs-to-fix is a superset (or same set) of an installed
patch's bugs-fixed in the Oracle home directory.
|
|
no_inventory
|
Bypasses the inventory for
reading and updates. You cannot use this option with the
local option. This option places the
installation into an unsupported state. |
|
no_relink
|
This option does not perform any
make operations. You can use it during
multiple patch applications and to perform the linking step only once. OPatch
does not keep track of the make operations
it did not perform. You need to make sure to execute OPatch without this
option at the end for compilation. |
|
no_sysmod
|
Specifies that OPatch does not
need to update the files in the system. It only updates the inventory. It
also does not execute the pre and post scripts.
|
|
oh
|
Specifies the Oracle home
directory to use instead of the default. This takes precedence over the
environment variable
ORACLE_HOME. |
|
opatch_init_end
|
Marks the end of the init
options. You use this option with the
init option.
If you do not use this option, everything after init until the end of the command is
passed into init. |
|
opatch_post_end
|
Marks the end of the
post option. You use this option with the post option. If you do not use this
option, everything after post until
the end of the command is passed into post. |
|
opatch_pre_end
|
Marks the end of the
pre options. You use this option with
the pre option.
If you do not use this option, everything after pre until the end of the command is
passed into pre. |
|
Patch
Location
|
Indicates the path to the patch
location. If you do not specify the location, OPatch assumes the current
directory is the patch location.
|
|
post
|
Specifies the parameters to be
passed to the
post script.
This script is executed after the patch is applied. You need to enclose the
values for this option in double-quotes. |
|
pre
|
Specifies the parameters to be
passed to the
pre script.
This script is executed before the patch is applied. You need to enclose the
values for this option in double-quotes. |
|
property_file
|
Specifies the user-defined
property file for OPatch to use. The path to the property file should be
absolute. This property file takes precedence over the one that OPatch
supplies.
|
|
silent
|
Suppresses user interaction, and
defaults any answers to "yes."
|
|
verbose
|
Prints additional OPatch output
to the screen as well as to the log file.
|
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.
Use the following syntax for this command:
opatch lsinventory [-all ] [-detail ] [-jre <LOC> ] [-oh <ORACLE_HOME> ] [-patch] [-oh] [-property_file <path to property file>]
Table 7-12 lists
the options available for the Lsinventory command.
|
Option
|
Description
|
|
all
|
Reports the name and installation
directory for each Oracle home directory found.
|
|
detail
|
Reports the installed products
and other details. You cannot use this option with the
all option. |
|
jre
|
Specifies the location of a
particular JRE (Java) for OPatch to use instead of the default location under
the Oracle home directory.
|
|
oh
|
Specifies the Oracle home
directory to use instead of the default directory. This takes precedence over
the
ORACLE_HOME environment variable. |
|
patch
|
Specifies the patches installed
in the Oracle home.
|
|
property_file
|
Indicates the user-defined
property file that OPatch should use. The path to the property should be
absolute. This property file takes precedence over the property file that
OPatch supplies.
|
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.
Use the following syntax for this command:
opatch query [-all] [-jre <LOC> ] [-oh <LOC> ] [-get_component] [-get_os] [-get_date] [-get_base_bug] [-is_portal_patch] [-is_rolling_patch] [-is_online_patch] [-has_sql] [ <Patch Location> ]
Table 7-12 lists
the options available for the Query command.
|
Option
|
Description
|
|
all
|
Retrieves all information about a
patch. This is equivalent to setting all available options.
|
|
get_base_bug
|
Retrieves bugs fixed by the
patch.
|
|
get_component
|
Retrieves components the patch
affects.
|
|
get_date
|
Retrieves the patch creation date
and time.
|
|
has_sql
|
Indicates true if the patch has
SQL-related actions. Otherwise, the option is false. For information on SQL
and PL/SQL patching,
|
|
is_online_patch
|
Indicates true if the patch is an
online patch. Otherwise, the option is false.
|
|
is_portal_patch
|
Indicates true if the patch has
portal actions. Otherwise, the option is false.
|
|
is_rolling_patch
|
Indicates true if the patch is a
rolling patch. Otherwise, the option is false.
|
|
oh
|
Specifies the Oracle home
directory to use instead of the default directory. This takes precedence over
the
ORACLE_HOME environment variable. |
|
Patch
Location
|
Indicates the path to the patch
location. If you do not specify the location, OPatch assumes the current
directory is the patch location.
|
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.
Use the following syntax for this command:
opatch rollback -id <ID> [-ph <Patch Location>]
[-jre <LOC> ] [-oh <ORACLE_HOME>]
[-silent] [-verbose] [-no_relink]
[-pre <parameters for the pre
script in escaped double quotes> [-opatch_pre_end] ]
[-post <parameters for the post script in escaped
double quotes>[ -opatch_post_end] ] [-no_sysmod]
[-property_file <path to property file>]
[-init <parameters for the init script in escaped double
quotes> [-opatch_init_end] ] [-report]
Table 7-13 lists
the options available for the Rollback command.
|
Option
|
Description
|
|
id
|
Indicates the patch to be rolled
back. Use the
lsinventory option to display all patch
identifiers. Each one-off patch is indicated by its ID. To successfully roll
back a patch, you must provide the patch identifier. |
|
init
|
Passes parameters to the init
script, which executes before prerequisite checks are run. The values for
this option must be enclosed in double-quotes.
|
|
jre
|
Specifies the location of a
particular JRE (Java) for OPatch to use instead of the default location under
the Oracle home directory.
|
|
no_sysmod
|
Specifies that OPatch need not
update the files in the system, only the inventory. It also does not execute
the pre and post scripts.
|
|
no_relink
|
This option does not perform any
make operation in the patch. You can use
this option during multiple patch removals and to perform the compilation
step only once. |
|
oh
|
Specifies the Oracle home
directory to use instead of the default directory. This takes precedence over
the
ORACLE_HOME environment variable. |
|
opatch_init_end
|
Marks the end of the
init options. Use this option with the init option. If you do not use this
option, everything after init until
the end of the command is passed into init. |
|
opatch_post_end
|
Marks the end of the
post options. Use this option with the post option. If you do not use this
option, everything after post until
the end of the command is passed into post. |
|
opatch_pre_end
|
Marks the end of the
pre options. Use this option with the pre option. If you do not use this
option, everything after pre until
the end of the command is passed into pre. |
|
Patch
Location
|
Indicates the path to the patch
location. If you do not specify the location, OPatch assumes the current
directory is the patch location.
|
|
ph
|
Specifies the valid patch
directory area. Rollback uses the command types found in the patch directory
to identify which commands are used for the current operating system.
|
|
post
|
Specifies the parameters to be
passed inside the
post script.
This script executes after the patch is removed. You must enclose the value
of this option in double-quotes. |
|
pre
|
Specifies the parameters to be
passed inside the
pre script.
This script executes before the patch is removed. You must enclose the value
of this option in double-quotes. |
|
property_file
|
Specifies the user-defined
property file for OPatch to use. The path to the property file should be
absolute. This property file takes precedence over the one that OPatch
supplies.
|
|
report
|
Prints the actions to the screen
without executing them.
|
|
silent
|
Suppresses user interaction, and
defaults any yes|no questions to "yes". A Real Application Clusters
setup does not support this option.
|
|
verbose
|
Prints additional OPatch output
to the screen as well as to the log file.
|
Version Command for Standalone OPatch
This command
shows the current version number of the OPatch utility. Use the following
syntax for this command:
<Path_to_OPatch>/opatch version
Use Cases
The following sections provide scenarios that
administrators can encounter when implementing standalone patching for the
following types of operations:
·
Inventory
·
Patching
·
Utility
Inventory Operations
The following tables explain the purpose of the use case
along with preconditions and the process that occurs during the patching
process.
|
Use Case Category
|
Description
|
|
Purpose
|
Show a list of interim patches
installed on a standalone Oracle home.
|
|
Preconditions
|
$ORACLE_HOME is
set and the Oracle home has been patched using the standalone OPatch. |
|
User Input
|
Enter the following command:
opatch lsinventory |
|
OPatch
Response
|
1. OPatch
detects that this is a standalone Oracle home.
2. OPatch
looks for the standalone inventory file.
3. OPatch
prints out a list of installed interim patches.
|
|
Use Case Category
|
Description
|
|
Purpose
|
Show a detailed list of interim
patches installed on a standalone Oracle home.
|
|
Preconditions
|
$ORACLE_HOME is
set and the Oracle home has been patched using the standalone OPatch. |
|
User Input
|
Enter the following command:
opatch lsinventory -detail |
|
OPatch
Response
|
1. OPatch
detects that this is a standalone Oracle home.
2. OPatch
looks for the standalone inventory file.
3. OPatch
prints out a list of installed interim patches as well as files affected by
each interim patch.
|
Patching Operations
The following tables explain the purpose of the use case
along with preconditions and the process that occurs during the patching
process.
|
Use Case Category
|
Description
|
|
Purpose
|
Apply an interim patch on a
standalone Oracle home.
|
|
Preconditions
|
$ORACLE_HOME is
set and the Oracle home has been patched using the standalone OPatch. The
patch has been downloaded. |
|
User Input
|
Enter the following command:
opatch apply/patch_loc/123451 |
|
OPatch
Response
|
1. OPatch
detects that this is a standalone Oracle home.
2. OPatch
looks for the standalone inventory file and checks for conflicts.
3. OPatch
performs an automatic rollback if there are conflicting patches.
4. OPatch
applies a new patch to the home.
5. OPatch
updates its standalone inventory.
|
|
Use Case Category
|
Description
|
|
Purpose
|
Apply an interim patch on a
standalone Oracle home that exists within another OUI-based Oracle home.
|
|
Preconditions
|
$ORACLE_HOME is
set and the Oracle home has been patched using a new OPatch. The patch has
been downloaded.
The standalone Oracle home has a
different directory patch than the OUI-based Oracle home. For example, the
OUI-based Oracle home path is
/path, whereas the standalone Oracle
home is /path/dev. |
|
User Input
|
Enter the following command:
opatch apply/patch_loc/123451 |
|
OPatch
Response
|
1. OPatch
detects that this is a standalone Oracle home.
2. OPatch
looks for the standalone inventory file and checks for conflicts.
3. OPatch
performs an automatic rollback if there are conflicting patches.
4. OPatch
applies a new patch to the home.
5. OPatch
updates its standalone inventory.
|
|
Use Case Category
|
Description
|
|
Purpose
|
Apply an interim patch on a
standalone Oracle. It seems to be a standalone Oracle home, but OPatch
detects it as OUI-based.
|
|
Preconditions
|
$ORACLE_HOME is
set and the Oracle home has been patched using a new OPatch. The patch has
been downloaded. |
|
User Input
|
Enter the following command:
opatch apply/patch_loc/123451 |
|
OPatch
Response
|
1. OPatch
detects
ORACLE_HOME/oui and believes it is an OUI-based
Oracle home.
2. OPatch
attempts to apply the patch as OUI-based Oracle home patching (if the patch
is compatible with the home).
|
|
Use Case Category
|
Description
|
|
Purpose
|
Roll back an interim patch
applied earlier on a standalone Oracle home.
|
|
Preconditions
|
$ORACLE_HOME is
set and the Oracle home has been patched using a standalone OPatch. |
|
User Input
|
Enter the following command:
opatch rollback -id 123451 |
|
OPatch
Response
|
1. OPatch
detects this is a standalone Oracle home.
2. OPatch
examines the standalone inventory file to determine if patch 123451 was
applied.
3. OPatch
rolls back patch 123451.
4. OPatch
updates its standalone directory.
|
Utility Operations
The following tables explain the purpose of the use case
along with preconditions and the process that occurs during the patching
process.
|
Use Case Category
|
Description
|
|
Purpose
|
Load an XML file, making sure it
is XML-parsable.
|
|
Preconditions
|
$ORACLE_HOME is
set. |
|
User Input
|
Enter the following command:
opatch util loadXML
Note that the loadXML utility is
often used as a debugging and troubleshooting tool.
|
|
OPatch
Response
|
1. OPatch
detects this is a standalone Oracle home.
2. OPatch
prompts for the complete path to the XML file that you want to load.
3. OPatch
opens the file and uses the XML parser to parse it.
4. OPatch
reports that the file is XML-parsable.
|
|
Use Case Category
|
Description
|
|
Purpose
|
Ensure that the patch was applied
to the Oracle home.
|
|
Preconditions
|
$ORACLE_HOME is
set, and the Oracle home has been patched using the standalone OPatch. |
|
User Input
|
Enter the following command:
opatch util verify -ph/patch_loc/123451
Note that patch verification is
automatically invoked when OPatch applies a patch to an Oracle home. You do
not need to rerun
verify after applying a patch. |
|
OPatch
Response
|
1. OPatch
detects this is a standalone Oracle home.
2. OPatch
examines
/patch_loc/123451 to make sure it is a valid patch
area.
3. OPatch
examines the files in
/patch_loc/123451 to make sure the Oracle home was
patched with the same bits.
4. OPatch
reports that both the patch inventory and patch binary are in the Oracle
home.
|
Schema Patching
There are two types of schema patches:
·
SQL patch — This patches the Oracle database
with updated procedures and schema changes.
·
PL/SQL patch — This also patches the Oracle
database with updated procedures and schema changes, as for the SQL patch.
However, a PL/SQL patch also mentions the procedure names in its patch metadata
so that these procedures can be backed up for rollback.
The following sections discuss these topics:
·
Schema
patching options
·
Standalone
SQL execution
Schema Patching Options
Table 7-22 shows
the schema patching options that OPatch supports for Apply and Rollback:
|
Option
|
Description
|
|
-runSql
|
Instructs OPatch to read the SQL
script from the patch and run it on the specified SIDs. You must specify this
option for the
patchmd.xml SQL script specification and custom
SQL script. |
|
-sqlScript
|
Specifies OPatch to run this
custom SQL script. This is an optional parameter.
|
|
-connectString
|
Provides a list of database
instance SIDs, user, and password to be patched. Each entry is separated by a
comma ( , ). The value for this option has the following format:
SID1:USER1:PASSWORD1:NODE1, SID2:USER2:PASSWORD2:NODE2 |
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:
opatch util applySql –id <patchIDs> -connectString <SID1:USER1:PASSWORD1:NODE1>
The syntax for Rollback is as follows:
opatch util rollbackSql –ph <patchLocation> (or) –phBaseFile <filename> (or) –phBaseDir
<dirname> -connectString <SID1:USER1:PASSWORD1:NODE1>
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 not supported in Windows,
and only supported on the following UNIX platforms for version 11.1.0.7.0 and
later:
·
Linux
x86
·
Linux
x86_64
·
HP-UX
Itanium (HP-UX 11.31 and later)
·
Solaris
SPARC 64-bit (Solaris 10 and later)
Real Application Clusters Patching
A Real Application Clusters environment enables active
instances to concurrently execute transactions on a shared database. Patching
in a 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
-updateNodeListflag of Oracle Universal Installer.
You can bypass remote actions using the -local flag, as shown below:$ORACLE_HOME/oui/bin/<runInstaller or setup.exe> -updateNodeList ORACLE_ HOME=<oracle home location>
"CLUSTER_NODES={node1,node2,node3}"
-noClusterEnabled
-local
If you want to specify the local node or remote nodes of
a 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:$ORACLE_HOME/oui/bin/<runInstaller or setup.exe> ORACLE_HOME=<oracle home location>
"REMOTE_NODES={node1,node2,node3}" LOCAL_NODE=<nodelist
for example:node1>
If OPatch does not automatically detect Real Application
Clusters or its nodes, you need to investigate the contents of the inventory
and ensure that it is complete.
You can patch Real Application Clusters in three
different ways:
The following sections provide detailed information for
these types of Real Application Clusters patching.
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 a 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 the Real Application
Clusters when both sets are brought down. This mode is executed by using
-minimize_downtimecommand 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
A, installed in the Oracle home, fixed bugs 1, 2, and 3.
·
Patch
B, installed in the Oracle home, fixed bugs 10, 11, and 12.
·
Patch
C, to be installed, fixes bugs 1, 2, 3, and 4.
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:Oracle interim Patch Installer version 11.1.0.6.6
Copyright (c) 2009, Oracle Corporation. All rights reserved..
Oracle Home : /home/oracle_TEST/product/11.1.0/db_1
Central Inventory : /home/OUIHome_Opatch
from : /home/oracle_TEST/product/11.1.0/db_1/oraInst.loc
OPatch version : 11.1.0.6.6
OUI version : 11.1.0.6.6
OUI location : /home/oracle_TEST/product/11.1.0/db_1/oui
Log file location : /home/oracle_TEST/product/11.1.0/db
_1/cfgtoollogs/opatch/opatch-2008_May_25_14-03-33-IST_Wed.log
ApplySession applying interim patch '111000' to OH '/home/oracle
_TEST/product/11.1.0/db_1'
Apply Session failed: ApplySession failed to prepare the system. Interim patch
111000 is a superset of the patch(es) [ 111000 ] in OH /home/oracle
_TEST/product/11.1.0/db_1
System intact, OPatch will not attempt to restore the system
OPatch failed with error code 73
Subset
Patches to be applied can be subsets of other patches
installed in the Oracle home.
Example
Consider the following scenario:
·
Patch
A, installed in the Oracle home, fixed bugs 1, 2, and 3.
·
Patch
B, installed in the Oracle home, fixed bugs 10, 11, and 12.
·
Patch
D, to be installed, fixes bugs 1 and 2.
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 theskip_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).opatch napply <patch_location> -skip_subset -skip_duplicate
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).opatch napply <patch_location> -id 1,2,3 -skip_subset -skip_duplicate
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
A, installed in the Oracle home, fixed bugs 1, 2, and 3.
·
Patch
B, installed in the Oracle home, fixed bugs 10, 11, and 12.
·
Patch
E, to be installed, fixes bugs 3 and 4.
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
A, installed in the Oracle home, fixed bugs 1, 2, and 3, which modified files
a, b, and c.
·
Patch
F, to be installed, fixes bugs 1, 2, 3 and 4, and modifies files a, d, and f.
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.
|
Command
|
Superset
|
Subset
|
Duplicate
|
File Conflict or Bug Conflict Patch
|
|
Apply
|
OPatch performs an automatic
rollback, then an apply.
|
After the merge request, OPatch
performs an automatic rollback, then performs an apply.
|
OPatch performs an automatic
rollback, then performs a reapply.
|
OPatch reports the conflict.
After the merge request, OPatch performs an automatic rollback, then an
apply.
|
|
Napply
|
OPatch performs an automatic
rollback, then an apply.
|
OPatch reports the subset and
skips the subset patch. It then continues and applies the other patches.
|
OPatch performs an automatic
rollback, then a reapply.
|
OPatch reports the conflict, then
asks you to run again without applying a bug conflict patch.
You can use the -force option to
instruct OPatch to automatically roll back the conflicting patch, then apply
the new patch.
|
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:
·
Using
logs and traces
·
Recovering
from a failed patching session
·
Resolving
OPatch application errors
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:
opatch_05-17-2008_23-55-00.log
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:Date & Time : Tue Apr 26 23:00:55 PDT 2008
Oracle Home : /private/oracle/product/11.1.0/db_1/
OPatch Ver. : 11.1.0.6.6
Current Dir : /scratch/oui/OPatch
Command : lsinventory
Log File :
/private/oracle/product/11.1.0/db_1/cfgtoollogs/opatch/opatch-2008_Apr_26_23-00-55-PDT_Tue.log
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:
·
SEVERE
·
WARNING
·
INFO
·
CONFIG
·
FINE
·
FINER
·
FINEST
Recovering from a Failed Patching Session
·
System Update — In this phase, the files are
replaced in the Oracle home.
·
Inventory Update — In this phase, the details of the
patch applied is recorded in the inventory.
The following scenarios for single instance setups and
Real Application Clusters setups explain how you can recover from a failed
patching session.
Single Instance Setup
Cause: This occurs when the files on the
system are patched, but the inventory update has failed. A corrupted inventory
may cause this problem.
Action: Perform the following steps:
1.
Ensure
that the environment variable
ORACLE_HOME is set properly.
2.
Navigate
to the
$ORACLE_HOME/.patch_storage/<patch-id_timestamp> directory and execute the Restore
command.For UNIX:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.sh
For Windows:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.bat
3.
On
UNIX, source
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/make.txt file (if available) as follows:/bin/sh make.txt
When you apply or roll back a patch, an
OiiOneoffException occurs.
Cause: This occurs when the files on the
system are patched, but the inventory update has failed. This may occur because
the base component of the interim patch may not be present in the inventory.
Action: OPatch tries to restore the Oracle
home automatically and displays a message for the same. If OPatch does not
display a message stating that it has restored the Oracle home, perform the
following steps:
1.
Ensure
that the environment variable
ORACLE_HOME is set properly.
2.
Navigate
to the
$ORACLE_HOME/.patch_storage/<patch-id_timestamp> directory and execute the Restore
command.For UNIX:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.sh
For Windows:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.bat
3.
On
UNIX, source
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/make.txt file (if available) as follows:/bin/sh make.txt
Cause: This may occur because all the patches
applied before the application of the current patch are lost, or the patches
might not have been updated in the inventory.
Action: Perform the following steps:
1.
Navigate
to the
$ORACLE_HOME/.patch_storage/<patch-id_timestamp> directory and execute the Restore
command:For UNIX:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.sh
For Windows:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.bat
2.
On
UNIX, source
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/make.txt file (if available) as follows:/bin/sh make.txt
3.
If
the files are properly patched, but the information is not updated in the
inventory, execute the following command:
$ORACLE_HOME/OPatch/opatch apply -no_sysmod <Path_To_Patch>
Ensure that the patch has been applied
and recorded properly in the inventory by executing the following command:
$ORACLE_HOME/OPatch/opatch lsinventory -detail
4.
If
the files are still not patched properly, but you are able to see the patch in
the
lsinventory flag, you need to reapply the patch
using theno_inventory flag:$ORACLE_HOME/OPatch/opatch apply -no_inventory <Path_To_Patch>
When you apply a patch
and execute opatch lsinventory, it does not return the details of the patch
applied.
Cause: OPatch may not have recorded the
details of this patch in the inventory.
Action: Perform the following steps:
1.
Navigate
to the
$ORACLE_HOME/.patch_storage/<patch-id_timestamp> directory and execute the Restore
command:For UNIX:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.sh
For Windows:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.bat
2.
On
UNIX, source
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/make.txt file (if available) as follows:/bin/sh make.txt
3.
If
the files are properly patched, but the information is not updated in the
inventory, execute the following command:
$ORACLE_HOME/OPatch/opatch apply -no_sysmod <Path_To_Patch>
Ensure that the patch has been applied
and recorded properly in the inventory by executing the following command:
$ORACLE_HOME/OPatch/opatch lsinventory -detail
When you press Ctrl + C during the application or roll
back of a patch and execute opatch lsinventory, it does not return the details
of the patch applied or rolled back.
Cause: This may be because OPatch might have
stopped the application or rollback of the patch on pressing Ctrl+c.
Action: Perform the following steps:
1.
Ensure
that the environment variable
ORACLE_HOME is set properly.
2.
Navigate
to the
$ORACLE_HOME/.patch_storage/<patch-id_timestamp> directory and execute the Restore
command if it is available.For UNIX:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.sh
For Windows:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.bat
3.
On
UNIX, source
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/make.txt file (if available) as follows:/bin/sh make.txt
When you apply a patch, you quit when OPatch failed to
relink and prompted to continue.
Cause: This may occur because of a relink
failure.
Action: Perform the following steps:
1.
Ensure
that the environment variable
ORACLE_HOME is set properly.
2.
Navigate
to the
$ORACLE_HOME/.patch_storage/<patch-id_timestamp> directory and execute the Restore
command.For UNIX:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.sh
For Windows:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.bat
3.
Resolve
the relink failure issue by ensuring that you are able to invoke
make manually on a UNIX shell. After this,
apply the patch again.Real Application Clusters Setup
When I apply a patch on a
Real Application Clusters setup and execute 'opatch lsinventory' on the local
node, the patch is not listed.
Cause: This may occur if OPatch failed to
update the inventory.
Action: Perform the following steps:
1.
Ensure
that the environment variable
ORACLE_HOME is set properly in all the nodes of
the cluster.
2.
Navigate
to the
$ORACLE_HOME/.patch_storage/<patch-id_timestamp> directory of each node in the cluster
and execute the Restore command as follows:For UNIX:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.sh
For Windows:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.bat
3.
On
UNIX, source
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/make.txt file (if available) in each node of
the cluster as follows:/bin/sh make.txt
4.
Apply
the patch in each node in the cluster using the local flag:
$ORACLE_HOME/OPatch/opatch apply -local <Path_To_Patch>
Note:
Ensure that all the nodes use the same
OPatch version.
When I apply a patch on a
Real Application Clusters setup and execute 'opatch lsinventory' on the local
node, it returns nothing.
Cause: You might have lost all the patches
applied earlier.
Action: Perform the following steps:
1.
Ensure
that the environment variable
ORACLE_HOME is set properly in each node in the
cluster.
2.
Navigate
to the
$ORACLE_HOME/.patch_storage/<patch-id_timestamp> directory and execute the Restore
command in each node in the cluster.For UNIX:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.sh
For Windows:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.bat
3.
On
UNIX, source
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/make.txt file (if available) in each node as
follows:/bin/sh make.txt
4.
Apply
the patch in each node using the local flag:
$ORACLE_HOME/OPatch/opatch apply -local <Path_To_Patch>
Note:
Ensure that all the nodes use the same
OPatch version.
When I roll back a patch
on a Real Application Clusters setup, and execute 'opatch lsinventory' on the
local node, it shows that the patch was not removed.
Cause: This may occur if OPatch failed to
update the inventory.
Action: Perform the following steps:
1.
Ensure
that the environment variable
ORACLE_HOME is set properly in each node in the
cluster.
2.
Navigate
to the
$ORACLE_HOME/.patch_storage/<patch-id_timestamp> directory in each node in the cluster
and execute the restore command as follows:For UNIX:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.sh
For Windows:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.bat
3.
On
UNIX, source
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/make.txt file (if available) in each node in
the cluster as follows:/bin/sh make.txt
4.
Roll
back the patch in all the nodes in the cluster using the local flag:
$ORACLE_HOME/OPatch/opatch rollback -local -id <Patch_ID>
Note:
Ensure that all the nodes use the same
OPatch version.
When I roll back a patch
on a Real Application Clusters setup and execute 'opatch lsinventory' on the
local node, it returns nothing.
Cause: You might have lost all the patches
applied earlier.
Action: Perform the following steps:
1.
Ensure
that the environment variable
ORACLE_HOME is set properly in each node in the
cluster.
2.
Navigate
to the
$ORACLE_HOME/.patch_storage/<patch-id_timestamp> directory and execute the Restore
command in each node in the cluster:For UNIX:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.sh
For Windows:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.bat
3.
On
UNIX, source
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/make.txt file (if available) as follows:/bin/sh make.txt
4.
Roll
back the patch in the local node using the
local flag:$ORACLE_HOME/OPatch/opatch rollback -local -id <Patch_ID>
5.
Roll
back the patch on the other nodes also using the
local flag.
Note:
Ensure that all the nodes use the same
OPatch version.
When I apply a patch on a
Real Application Clusters setup, the patching in one node is fine (both the
files and the inventory are fine), but I am not sure about the other nodes.
Cause: This may occur because of a failed
system or inventory update.
Action: Perform the following steps:
1.
Copy
the Oracle home from the node that is fine to the other nodes.
2.
After
copying the Oracle home, make sure that the
ORACLE_HOME/inventory/ContentsXML/comps.xml file has the latest timestamp.
Note:
On Unix, use
touch to change the timestamp.
3.
Update
the nodes of the cluster. For more information on updating the nodes of the
cluster,
4.
Ensure
that all the prerequisite checks pass that are listed in the section
When I apply a patch on a
Real Application Clusters setup, the patching in one node is fine, but when I
execute 'opatch lsinventory' on the other nodes, the patch is not listed.
Cause: This may occur because of a failed
system or inventory update.
Action: Perform the following steps:
1.
Copy
the
ORACLE_HOME /inventory directory from the node that is fine
to the other nodes.
2.
After
copying the
ORACLE_HOME /inventory directory, make sure that the ORACLE_HOME/inventory/ContentsXML/comps.xml file has the latest timestamp.
Note:
On Unix, use
touch to change the timestamp.
3.
Update
the nodes of the cluster.
4.
Ensure
that all the prerequisite checks pass that are listed in the section.
When I apply or roll back
a patch on a Real Application Clusters setup, I am not able to apply or roll
back the patch on all nodes.
Cause: This may occur if the nodes are not
properly updated.
Action: Perform any one or more of the
following:
·
Ensure
that all the nodes in the cluster are up-to-date. If they are not, update the
nodes of the cluster.
·
Execute
the appropriate command on all nodes of the cluster as follows:
· opatch apply -local [patch_location]
·
· opatch rollback -local [patch_location]
Execute the appropriate command on the
local node of the cluster as follows:
· opatch apply [-local_node (node_name)] [-remote_nodes (comma separated node_names)]
·
· opatch rollback [-local_node (node_name)] [-remote_nodes (comma separated node_names)]
Resolving OPatch Application Errors
·
Not
a valid patch area
·
Opatch
cannot find system commands like
fuser, make
·
Unable
to remove a partially-installed interim patch
Not a valid patch area
Cause: The directory that the OPatch utility
is using to do the patch does not match the template for what it is checking.
This can also occur when you run the utility from an invalid shiphome
directory.
Action: When starting the OPatch utility, the
directory needs the following:
·
/etc directory that has the metadata files.
·
/files directory that has the payload files.
·
/etc/config/inventory file and the actions file under the
same directory.
If you did not start the OPatch
utility from the
patch_id directory, you can use the following
command:opatch apply /<Patch_Shiphome>
OPatch cannot find system commands like
fuser, make
Cause: The OPatch utility uses
fuser on UNIX systems to check for active
Oracle instances. On certain hp-ux systems, only a super-user can runfuser.
Action: Perform these steps to resolve this
problem:
1.
Set
/tmp in your PATH.
2.
Create
an empty file named
fuser.
3.
Shut
down the Oracle instances.
4.
Run
the OPatch utility.
Caution:
Another way to resolve this problem is
to give executable permission to other users for
fuser. However, this exposes a potential security issue in the
system, and is not recommended.
Cause: Interruption in the patching process
potentially causes this problem. This may occur if you press Ctrl+c during the
patching process. If the error is the one that OPatch detects, it automatically
resolves it.
Action: Perform the following steps:
1.
Ensure
that the environment variable
ORACLE_HOME is set properly.
2.
Navigate
to the
$ORACLE_HOME/.patch_storage/<patch-id_timestamp> directory and execute the Restore
command as follows:For UNIX:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.sh
For Windows:
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/restore.bat
3.
On
UNIX, source
$ORACLE_HOME/.patch_storage/<patch-id_timestamp>/make.txt
File (if
available) as follows:
/bin/sh make.txt
No comments:
Post a Comment