Skip Headers
Oracle® Database 2 Day + Real Application Clusters Guide
11g Release 2 (11.2)

Part Number E17264-07
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

10 Managing Oracle Software and Applying Patches

Oracle issues product fixes for its software called patches. When you apply the patch to your Oracle software installation, it updates the executable files, libraries, and object files in the software home directory. The patch application can also update configuration files and Oracle-supplied SQL schemas. Patches are applied by using OPatch, a utility supplied by Oracle, or Enterprise Manager Grid Control.

A group of patches form a patch set. When you apply a patch set, many different files and utilities are modified. This results in a version change for your Oracle software, for example, from Oracle Database 10.2.0.4.0 to Oracle Database 10.2.0.5.0. You use Oracle Universal Installer (OUI) to apply a patch set.

This chapter describes how to manage Oracle software and apply patches in Oracle Real Application Clusters (Oracle RAC) environments using the OPatch utility.

This chapter includes the following sections:

See Also:

Obtaining the Patch

You obtain patches and patch sets from My Oracle Support, which is the Oracle Support Services Web site, at

https://support.oracle.com

To locate patches on the My Oracle Support Web site:

  1. Log in to your account on My Oracle Support.

  2. At the top of the page, on the left side, select Patches & Updates.

  3. If you know the patch number, you can enter it into the field to the right of the Patch Name or Number drop-down list. Next to the Platform drop-down list, use the Select up to 5 drop-down list to choose the operating systems on which you plan to apply the patch.

    If you want to search for all available patches for your system, select Product or Family (Advanced Search) at the top of the page. Then supply the following information:

    • Choose the products you want to patch (for example, Oracle Clusterware, RDMBS Server, or an individual product such as Universal Installer)

    • Specify the software release for the products you selected

    • Specify the platform on which the software is installed

    Click Search to look for available patches. The Patch Search Results page is displayed.

  4. On the Patch Search Results page, select the number of the patch you want to download. A details page for that patch appears on your screen.

  5. View the ReadMe file for the patch, or click Download to download the patch to your local computer. If you download the patch to a computer that is not a node in the cluster, then you must transfer the file using a binary protocol to a cluster node.

    You can also choose to add the patch to your current patch plan or create a new patch plan. A patch plan is a collection of patches that you want to apply as a group. To learn more about using patch plans, in the Add to Plan drop-down list select Why use a Plan?

Preparing to Use OPatch

Before you apply the patch to your Oracle RAC database, your Oracle ASM installation, or to your Oracle Clusterware installation, you must prepare the operating system environment and stage the patch locally.

The following section describe the steps to perform in preparation for using OPatch:

Checking the ORACLE_HOME Environment Variable

OPatch verifies if the Oracle home is present. You must ensure that the ORACLE_HOME environment variable is set to the Oracle home of the product you are trying to patch.

Check the respective vendor documentation for the details to set the environment variable.

To check the current setting of the ORACLE_HOME variable on Linux:

  1. In a command window, log in to the operating system as the oracle user.

  2. Use the echo command to display the current setting of the ORACLE_HOME environment variable.

    echo $ORACLE_HOME
    

See Also:

Performing a Backup Before Patching Software

It is highly recommended to back up the software directory you are patching before performing any patch operation. This applies to Oracle RAC, Oracle ASM, or Oracle Clusterware software installation directories.

To back up the software installation:

  1. Back up the software installed in the specified Oracle home using:

    1. An operating system utility, such as zip, cp -r, tar, or cpio, to back up the software in the Oracle home directory to disk.

    2. The Oracle Secure Backup utility to back up the software in the Oracle home directory to tape.

Staging the Patch on Each Node

After you down the patch from My Oracle Support, you must copy the patch to each node that runs the software being patched.

Updating the PATH Environment Variable

The opatch binary file is located in the Oracle_home/OPatch directory. You can either specify this path when executing OPatch, or you can update the PATH environment variable to include the OPatch directory.

To update the PATH environment variable on Oracle Enterprise Linux systems:

  1. In a command window, log in to the operating system.

  2. Use a shell command similar to the following to update the value of the PATH environment variable, where /u01/app/oracle/product/11.2.0/dbhome_1 is the location of your Oracle home directory:

    $ export PATH=$PATH:/u01/app/oracle/product/11.2.0/dbhome_1/OPatch
    

    You could also modify the shell profile script for the current user to have this variable configured every time you log in.

Configuring SSH User Equivalency

Before you patch a system, make sure the user equivalency is working. User equivalency exists when the operating system user on each node is considered to be identical. For information on configuring user equivalency, see "Configuring Operating System Users and Groups".

To test SSH user equivalency:

  1. On the system where you want to run OPatch, log in as the oracle user.

  2. Use the following command to test user equivalency:

    [oracle@racnode1] $ ssh racnode2 date
    

    If the date is returned, then user equivalency between the source and destination node has been configured.

  3. If you see output similar to the following, then SSH user equivalency is not enabled:

    Enter passphrase for key '/home/oracle/.ssh/id_rsa': 
    

    Enable SSH user equivalency before continuing with the patching operation.

To enable SSH user equivalency:

  1. On the system where you want to run OPatch, open a command window and log in as the oracle user.

  2. Start the SSH agent and load the SSH keys into memory using the following commands:

    $ /usr/bin/ssh-agent $SHELL
    $ /usr/bin/ssh-add
    

    These commands start the ssh-agent on the local node, and load the RSA and DSA keys into the current session's memory so that you are not prompted to use pass phrases when issuing SSH commands.

  3. At the prompt, enter the pass phrase for each key that you generated when configuring Secure Shell, for example:

    [oracle@racnode1 .ssh]$ exec /usr/bin/ssh-agent $SHELL
    [oracle@racnode1 .ssh]$ /usr/bin/ssh-add
    Enter passphrase for /home/oracle/.ssh/id_rsa
    Identity added: /home/oracle/.ssh/id_rsa (/home/oracle/.ssh/id_rsa)
    Identity added: /home/oracle/.ssh/id_dsa (/home/oracle/.ssh/id_dsa)
    
  4. To test if you have configured SSH correctly, run the following command. If you have configured SSH correctly, then you are not prompted for a password or a pass phrase.

    [oracle@racnode1] $ ssh racnode2 date
    

Note:

Do not close this command window until you have completed the patch installation. If you must close the command window in which you enabled SSH user equivalency before the patch installation is complete, repeat Step 1 to Step 4 before starting the patch installation.

See Also:

Applying Patches

Patching in an Oracle RAC environment is slightly different compared to patching a single node. If OPatch detects a cluster, it uses OUI to query the software inventory to find the local node name and node list.

Before you install a patch, you must stop all the applications running from the software directory that is being patched. In a cluster, you may have to shut down additional applications, depending upon which software is being patched. Table 10-1 lists the applications to stop when patching Oracle software.

Table 10-1 Patching Oracle Home Directories

Oracle Home Directory Applications to Stop

Oracle RAC Database

Oracle RAC database, Enterprise Manager Database Control, listener, and any other applications that are running from the Oracle RAC home directory

Oracle Clusterware or Oracle ASM

Oracle RAC database, any single-instance databases that use the same Oracle ASM instance as the cluster database, the Oracle ASM instance, all node applications, Oracle Clusterware, and any other applications that are running from the Grid home directory


This section describes the following tasks:

Patching the Grid Home

There are two parts to patching the Oracle Grid Infrastructure for a cluster software:

  • Unlock the Grid home

  • Apply patches to the Grid home

Before you can apply a patch or make other modifications to the software files in the Grid home, you must first unlock the Grid home.

To unlock the Grid home, perform the following steps:

  1. Change directory to the path Grid_home/crs/install, where Grid_home is the path to the Grid home, and at the root user unlock the Grid home using commands similar to the following:

    cd /u01/app/11.2.0/grid/crs/install 
    perl rootcrs.pl -unlock -crshome /u01/app/11.2.0/grid
    

    When you run the rootcrs.pl script with the -unlock flag, it stops the Oracle Clusterware stack and unlocks the files in the Grid home so they can be modified.

  2. Change user to the Oracle Grid Infrastructure for a cluster software owner and apply the patch to the Grid home, using one of the patching methods described in this section.

  3. After you have finished modifying the Grid home, lock it again as the root user using commands similar to the following:

    cd /u01/app/11.2.0/grid/crs/install 
    perl rootcrs.pl -patch
    

    The rootcrs.pl script with the -patch flag locks the Grid home again and restarts the Oracle Clusterware stack.

All Node Patching

In all node patching, all the nodes in the cluster are initially shut down and the patch is applied on all the nodes. After all the nodes have been patched, then all the nodeapps on the nodes are restarted. This method is typically used for very critical patches and it leads to maximum downtime. OPatch uses this method if the patch cannot be applied in a rolling fashion, and you did not specify the minimize_downtime option.

To implement all node patching:

  1. Stop all user applications that use the Oracle home directory.

  2. If you are patching only the Oracle RAC home directory, shut down all Oracle RAC instances on all nodes in the cluster. To shut down all Oracle RAC instances for a cluster database, enter the following command in a command window, where CRS_home is the location of the CRS home directory and sales is the name of the database:

    $ CRS_home/bin/srvctl stop database -d sales
    
  3. If you are patching the ASM home or CRS home directory, stop all single-instance databases that are running on the group of nodes being patched if they use the ASM installation that you are patching.

  4. If you are patching the ASM home directory, stop all user applications that use the ASM home directory on the group of nodes being patched.

  5. If you are patching the ASM home or CRS home directory, you can use a single command to stop all the node applications on each node in the group. This command shuts down the Oracle RAC instances, the listener, the ASM instances, and the Oracle Clusterware node applications for the specified node. Use a command similar to the following, where CRS_home is the home directory of your Oracle Clusterware installation and node_name is the name of the node:

    $ CRS_home/crs/bin/srvctl stop nodeapps -n node_name
    

    Repeat the preceding command for each node in the cluster.

    After you have stopped the nodeapps on each node in the cluster, use the crs_stat utility to verify that all the nodeapps were stopped on each node.

    $ CRS_home/bin/crs_stat -t
    
  6. If you are patching the CRS home directory, shut down the CRS daemons for all the nodes in the cluster by issuing the following command as the root user on each node, where CRS_home is the home directory of your Oracle Clusterware installation:

    # CRS_home/bin/crsctl stop crs
    

    Repeat this command on each node in the cluster.

  7. Set your current directory to the directory where the patch is located, for example:

    $ cd Oracle_home/EMStagedPatches/4519934/4519934
    
  8. Make sure the ORACLE_HOME environment variable points to the software directory you want to patch, for example:

    $ echo $ORACLE_HOME
    /opt/oracle/11gR1/db_1
    
  9. Run OPatch by entering the following command:

    opatch apply
     
    
  10. If you applied the patch to the CRS home directory, restart the CRS daemons on all nodes by issuing the following command as the root user on each node, where CRS_home is the home directory of your Oracle Clusterware installation:

    # CRS_home/bin/crsctl start crs
    

    Repeat this command on each node in the cluster.

  11. If you stopped the nodeapps on each node, after the patch has been applied, restart the nodeapps on all nodes. To start the nodeapps, enter a command similar to the following where CRS_home is the home directory of your Oracle Clusterware installation and docrac1 is one of the nodes in your cluster:

    $ CRS_home/bin/srvctl start nodeapps -n docrac1
     
    

    Repeat the preceding command for each node in the cluster.

    After you have restarted the nodeapps on all nodes, use the crs_stat utility to verify that the nodeapps were restarted on each node.

    $ CRS_home/bin/crs_stat -t
    

    If any of the node applications did not restart, use the SRVCTL utility to restart them. For example, you can use commands similar the following to restart various node applications, where CRS_home is the home directory of your Oracle Clusterware installation:

    $ CRS_home/bin/srvctl start instance -d sales -i "sales1"
    $ CRS_home/bin/srvctl start listener -n docrac1
    $ CRS_home/bin/srvctl start asm -n docrac1
     
    
  12. Run any post-patch scripts that are mentioned in the patch instructions, for example:

    $ sqlplus /nolog 
    SQL> connect sys/password@sales1 AS SYSDBA
    SQL> @Oracle_home/cpu/CPUOct2007/catcpu.sql
    SQL> @Oracle_home/rdbms/admin/utlrp.sql
    SQL> exit
    

Rolling Patching

In rolling patching, one group of nodes is shut down, the patch is applied to those nodes, and the nodes are brought back up. This is performed group by group, separately, until all the nodes in the cluster are patched. This is the most efficient means of applying an interim patch to an Oracle RAC, ASM, or Oracle Clusterware installation. By patching groups of nodes individually, there is zero downtime for the cluster database because at least one instance is available at all times on a different node.

While most patches can be applied in a rolling fashion, some patches cannot be applied in this fashion. The README file for the patch indicates whether or not you can apply the patch using the rolling patch method. If the patch cannot be applied using the rolling patch method, then you must use either "Minimum Downtime Patching" or "All Node Patching" to apply the patch.

To apply a patch using the rolling patch method:

  1. In a command window, change to the directory where the unzipped patch is staged on disk, for example:

    $ cd Oracle_home/EMStagedPatches/4519934/4519934
    
  2. Stop all user applications that use the Oracle RAC home directory for the group of nodes being patched. For example, to stop Enterprise Manager Database Control on the local node, use the following command, where Oracle_home is the home directory for your Oracle RAC installation:

    $ Oracle_home/bin/emctl stop dbconsole
    
  3. If you are patching the ASM home or CRS home directory, stop all single-instance databases that are running on the group of nodes being patched if they use the ASM software you are patching.

  4. If you are patching the ASM home directory, stop all user applications that use the ASM home directory on the group of nodes being patched.

  5. If you are patching only the Oracle RAC home directory, shut down all Oracle RAC instances in the group of nodes being patched. To shut down an instance for an Oracle RAC database, enter a command similar to the following example, where CRS_home is the home directory for your Oracle Clusterware installation, sales is the name of the database, and sales1 is the name of the instance:

    $ CRS_home/bin/srvctl stop instance -d sales -i "sales1" -f
    

    Repeat the preceding command for each node in the group of nodes being patched.

  6. If you are patching the ASM home or CRS home directory, you can use a single command to stop all the node applications on each node in the group. This command shuts down the Oracle RAC instances, the listener, the ASM instances, and the Oracle Clusterware node applications for the specified node. Use a command similar to the following, where CRS_home is the home directory of your Oracle Clusterware installation and docrac1 is one of the nodes in the group:

    $ CRS_home/crs/bin/srvctl stop nodeapps -n docrac1
    

    Repeat the preceding command for each node in the group of nodes being patched.

    After you have stopped the nodeapps on each node in the group, use the crs_stat utility to verify that all the nodeapps were stopped on the group of nodes being patched.

    $ CRS_home/bin/crs_stat -t
    
  7. If you are patching the CRS home directory, shut down the CRS daemons for the nodes in the group by issuing the following command as the root user on each node in the group, where CRS_home is the home directory of your Oracle Clusterware installation:

    # CRS_home/bin/crsctl stop crs
    

    Repeat this command on each node in the group of nodes being patched.

  8. Make sure the ORACLE_HOME environment variable points to the software directory you want to patch, for example:

    $ echo $ORACLE_HOME
    /opt/oracle/11gR1/db_1
    
  9. If you are patching nodes individually, use the following command to instruct OPatch to apply the patch to only the local node. If you run this command from the directory where the patch is located, you do not need to specify the patch ID.

    $ opatch apply -local
    

    If you are using a group of nodes, use a command similar to the following to instruct OPatch to apply the patch to the group of nodes being patched:

    $ opatch apply -local_node docrac1 -remote_nodes docrac2,docrac3
    
  10. If you applied the patch to the CRS home directory, restart the CRS daemons for the nodes in the first group by issuing the following command as the root user on each node in the group, where CRS_home is the home directory of your Oracle Clusterware installation:

    # CRS_home/bin/crsctl start crs
    

    Repeat this command on each node in the group.

  11. If you stopped the nodeapps for the group of nodes, after the patch has been applied, restart the nodeapps on those nodes. To start the nodeapps, enter a command similar to the following where CRS_home is the home directory of your Oracle Clusterware installation and docrac1 is one of the nodes in the group of nodes you recently patched:

    $ CRS_home/bin/srvctl start nodeapps -n docrac1
     
    

    Repeat the preceding command for each node in the group.

  12. After you have restarted the nodeapps on each node in the group, use the crs_stat utility to verify that the nodeapps were restarted on each node in the group.

    $ CRS_home/bin/crs_stat -t
    

    If any of the node applications did not restart, use the SRVCTL utility to restart them. For example, you can use the following command to restart the sales1 instance for the sales cluster database:

    $ CRS_home/bin/srvctl start instance -d sales -i "sales1"
     
    
  13. Restart all single-instance databases that use the ASM software and all user applications that use the Oracle home or ASM home on each node in the group of nodes you recently patched.

  14. Repeat Step 2 through Step 8 for the next group of nodes.

  15. If you are patching nodes individually, use a command similar to the following to instruct OPatch to apply the patch to only the next node to be patched. If you run this command from the directory where the patch is located, you do not need to specify the patch ID.

    $ opatch apply -remote_nodes docrac2
    

    If you are patching a group of nodes, use a command similar to the following to instruct OPatch to apply the patch to the group of nodes being patched:

    $ opatch apply -remote_nodes docrac4,docrac5,docrac6
    
  16. If you applied the patch to the CRS home directory, restart the CRS daemons for the nodes in the group you recently patched by issuing the following command as the root user on each node in the group, where CRS_home is the home directory of your Oracle Clusterware installation:

    # CRS_home/bin/crsctl start crs
    

    Repeat this command on each node in the group.

  17. If you stopped the nodeapps for the group of nodes, after the patch has been applied, restart the nodeapps on those nodes. To start the nodeapps, enter a command similar to the following where CRS_home is the home directory of your Oracle Clusterware installation and docrac1 is one of the nodes in the group of nodes you recently patched:

    $ CRS_home/bin/srvctl start nodeapps -n docrac1
     
    

    Repeat the preceding command for each node in the group.

  18. After you have restarted the nodeapps on each node in the group, use the crs_stat utility to verify that the nodeapps were restarted on each node in the group.

    $ CRS_home/bin/crs_stat -t
    

    If any of the node applications did not restart, use the SRVCTL utility to restart them. For example, you can use the following command to restart the sales2 instance for the sales cluster database:

    $ CRS_home/bin/srvctl start instance -d sales -i "sales2"
     
    
  19. Restart all single-instance databases that use the ASM software and all user applications that use the Oracle home or ASM home on each node in the group of nodes you recently patched.

  20. If you have more than two groups of nodes to be patched, repeat Step 14 through Step 19 for each group of nodes until all the nodes in the cluster have been patched.

  21. Run any post-patch scripts that are mentioned in the patch instructions, for example:

    $ sqlplus /nolog 
    SQL> connect sys/password@sales1 AS SYSDBA
    SQL> @Oracle_home/cpu/CPUOct2007/catcpu.sql
    SQL> @Oracle_home/rdbms/admin/utlrp.sql
    SQL> exit
    

Minimum Downtime Patching

In minimum downtime patching, one set of nodes is shut down and the patch is applied to those nodes. After the first set of nodes has been patched, the second set of nodes is shut down. The first set of nodes is then restarted and the patch is applied to the second set of nodes. After the patch has been applied to the second set of nodes, those nodes are restarted. This method leads to less downtime for Oracle RAC, compared to having all the nodes shut down at the same time.

When you use the minimum downtime patching method, the following actions occur:

  • The local node is always patched first.

  • The local node is used as a base to patch the other nodes.

  • The user is prompted for the set of nodes to patch first from the remaining nodes.

  • For each node in this first set, the user is asked to stop the instance and then the patch is propagated to that node before continuing to the next node. When the initial set of nodes has been patched, the user is asked to shut down the remaining nodes.

  • After the local node is patched, the patch is propagated to the last set of nodes and the inventory is updated. The last instances are stopped on the remote nodes. You can then start up the patched nodes (the first set of nodes) before patching the remaining nodes.

To apply a patch to your cluster database using the minimum downtime method:

  1. Change to the directory where the unzipped patch is staged on disk, for example:

    $ cd Oracle_home/EMStagedPatches/4519934/4519934
    
  2. Stop all user applications that use the Oracle RAC home directory for the group of nodes being patched. For example, to stop Enterprise Manager Database Control on the local node, use the following command, where Oracle_home is the home directory for your Oracle RAC installation:

    $ Oracle_home/bin/emctl stop dbconsole
    
  3. Shut down all Oracle RAC instances on the local node. To shut down an instance for an Oracle RAC database, enter a command similar to the following example, where CRS_home is the home directory for your Oracle Clusterware installation, sales is the name of the database, and sales1 is the name of the instance:

    $ CRS_home/bin/srvctl stop instance -d sales -i "sales1" -f
    
  4. Make sure the ORACLE_HOME environment variable points to the software directory you want to patch, for example:

    $ echo $ORACLE_HOME
    /u01/app/oracle/product/11.2.0/dbhome_1
    
  5. Use the following command from within the patch directory:

    $ opatch apply -minimize_downtime
    

    If you run the OPatch command from the directory where the patch is staged on disk, you do not need to specify the patch ID.

    OPatch asks if you are ready to patch the local node. After you confirm that the Oracle RAC instances on the local node have been shut down, OPatch applies the patch to the Oracle home directory on the local node. You are then asked to select the next nodes to be patched.

  6. After you shut down the Oracle RAC instances on the other nodes in the cluster, you can restart the Oracle RAC instance on the local node. Then, instruct OPatch that you are ready to patch the remaining nodes.

  7. After all the nodes have been patched, restart the Oracle RAC instances on the other nodes in the cluster. The following command shows how to start the orcl2 instance for the Oracle RAC database named orcl:

    $ Grid_home/bin/srvctl start instance -d orcl -i "orcl2"
     
    
  8. Verify that all the nodeapps were restarted on all the nodes in the cluster.

    $ crsctl check crs
    

    If any of the node applications did not restart, use the SRVCTL utility to restart them. For example, you can use commands similar the following to restart the listener on the racnode1 node, where Grid_home is the home directory of your Oracle Grid Infrastructure for a cluster installation:

    $ Grid_home/bin/srvctl start listener -n racnode1
     
    
  9. Run any post-patch scripts that are mentioned in the patch instructions, for example:

    $ sqlplus /nolog 
    SQL> connect sys/password@orcl1 AS SYSDBA
    SQL> @Oracle_home/cpu/CPUOct2009/catcpu.sql
    SQL> @Oracle_home/rdbms/admin/utlrp.sql
    SQL> exit
    

Applying Patch Sets

Patch sets are a mechanism for delivering fully tested and integrated product fixes. All the fixes in a patch set have been tested and are certified to work with each other. Because a patch set includes only low impact patches, it does not require you to certify applications or tools against the server.

For instructions on applying the latest patch set to your Oracle RAC database and Oracle Clusterware installations on Oracle Enterprise Linux, search for "Oracle 11g release 2(11.2) Support Status and Alerts" documentation on the My Oracle Support (formerly OracleMetaLink) Web site.

This document provides a summary of the patch sets available for Oracle 11g Release 2. Using this document, you can easily locate and view the Patch Set Notes for your platform. The Oracle Database Patch Set Notes document contains the following information:

To locate the Patch Set notes on My Oracle Support:

  1. Log in to My Oracle Support.

  2. Select the Patches & Updates tab.

  3. Select Quick Links to the Latest Patchsets, Mini Packs, and Maintenance Packs.

  4. Under the heading Latest Oracle Server/Tools Patchsets, select Oracle Database.

    A list of operating systems appears.

  5. Place your cursor over the entry that matches your operating system, or use the triangular arrows to search for your operating system.

    When you place the cursor over the entry for your operating system, for example, Linux x86, a list of database versions appears.

  6. Select 11.2.0

    The Advanced Search page appears.

  7. Scroll to the bottom of this page to see the list of available patch sets.

  8. Select the number in the Patch column for the patch set you want to view or download.

    The Patchset description and download page appears.

  9. Click View Readme to see the patch set notes.

    On this page you can also click Download to download the patch to your computer.

  10. If you choose to download the patch, then follow the instructions in the ReadMe file of the patch set to apply the patch set to your software.

Troubleshooting Patch Deployment

Applying patches to your Oracle RAC environment can be complicated at times. This section covers some common topics regarding troubleshooting patch deployment:

If you have problems applying a patch to your Oracle RAC database, review these solutions to common problems. If the problem you encountered is not listed, review the log and trace files.

Updating the Node List for OPatch

If OPatch does not automatically detect Oracle RAC or its nodes, investigate the contents of the inventory and ensure they are complete.

To update the node list for OPatch:

If the list of nodes for your cluster is not complete, you can update it by using Oracle Universal Installer and the -updateNodeList flag, as demonstrated in the following example:

Oracle_home/oui/bin/runInstaller -updateNodeList 
ORACLE_ HOME=/u01/app/oracle/product/11.2.0/dbhome_1 
CLUSTER_NODES=racnode1,racnode2,racnode3 -noClusterEnabled

See Also:

About OPatch Log and Trace Files

Logging and tracing is a common aid for debugging. OPatch maintains logs for all apply, rollback, and lsinventory operations. The log files are located in the Oracle_home/cfgtoollogs/opatch directory. Each log file is tagged with the time stamp of the operation. Log files are named as opatch_mm-dd-yyyy_hh-mm-ss.log, where mm-dd-yyyy is the current date and hh-mm-ss is the current time. Each time you run OPatch, a new log file is created.

For example, if a log file is created on May 17, 2007 at 11:55 PM, then it is named as follows:

opatch_05-17-2007_23-55-00.log

OPatch also maintains an index of the commands processed by OPatch and the log files associated with it in the opatch_history.txt file located in the Oracle_home/cfgtoollogs/opatch directory. A sample of the opatch_history.txt file is as follows:

Date & Time : Tue Apr 26 23:00:55 PDT 2007
Oracle Home : /u01/app/oracle/product/11.2.0/dbhome_1/
OPatch Ver. : 11.2.0.0.0
Current Dir : /scratch/oui/OPatch
Command     : lsinventory
Log File    : 
/u01/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/opatch-2007_Apr_26_23-00-55-PDT_Tue.log

Resolving the "Not a valid patch area" Error

You might get this error if the directory that the OPatch utility is using to do the patch does not match the template for what it is checking, or if the OPatch utility is run from an invalid directory.

The Patch_Shiphome directory should have the following structure:

  • An etc directory that has the metadata files

  • A files directory that has the patch files

  • The etc/config/inventory.xml file and the actions.xml file under the same directory

To resolve the "Not a valid patch area" error:

  • Perform one of the following actions:

    1. Remove the patch shiphome directory and re-create it with the proper structure (by extracting the files again).

    2. Start the OPatch utility from the directory where the patch to be installed has been unzipped and staged on disk.

    3. Use the following command when starting OPatch:

      opatch apply /Patch_Shiphome
      

      where Patch_Shiphome is the location where the patch has been staged on disk.

Resolving the "Unable to remove a partially installed interim patch" Error

If the patching process is interrupted, you might get the error "Unable to remove a partially installed interim patch" when you try to install the patch a second time.

To resolve the partially installed patch error:

  1. Ensure that the environment variable ORACLE_HOME is set to the Oracle home directory you are attempting to patch.

  2. Go to the Oracle_home/.patch_storage/patch-id_timestamp directory and run the restore.sh script (or restore.bat on Windows platforms) as follows:

    Oracle_home/.patch_storage/patch-id_timestamp/restore.sh
    
  3. On Linux and UNIX systems, use the Oracle_home/.patch_storage/patch-id_timestamp/make.txt file (if available) to modify your operating system environment, as follows:

    /bin/sh make.txt
    
  4. Attempt to apply the patch again.

Upgrading the Oracle Software

An upgrade modifies most, if not all, of the installed Oracle software files, whereas a patch typically modifies only a few files. Upgrades are performed when you install a new software version, or apply a patch set. You can perform rolling upgrades, or you can shut down the Oracle Database and Oracle Clusterware software to perform the upgrade.

With Oracle Clusterware 11g release 2, you perform out-of-place upgrades. To perform an out-of-place upgrade, you install the Oracle Grid Infrastructure for a cluster into a new Grid home. When performing the upgrade, you specify the location of the new Grid home instead of selecting the existing software location.

When performing an out-of-place upgrade, the old and new version of the software are present on the nodes at the same time, each in a different home location, but only one version of the software is active at any given time.

Oracle Database release 11.2.0.2 is a full patch set release. To upgrade to Oracle Database release 11.2.0.2, you install the Oracle Grid Infrastructure for a cluster and Oracle Database software into new Oracle home directories instead of applying the patch set to the existing Oracle home directories. This is different from patch set releases for previous Oracle Database releases, where the patch set was always installed in place.

You can use Database Upgrade Assistant (DBUA) to upgrade an existing database to the current release of Oracle Database. Database Upgrade Assistant (DBUA) guides you through the upgrade process and configures your database for the new release. DBUA automates the upgrade process and makes appropriate recommendations for configuration options such as tablespaces and online redo log files.

See Also: