1.

Unzip into grid location

As the grid user, unzip the patch to /u01/app/11.2.0/grid on hosts host01, host02.

[grid@host01 share]$ unzip p6880880_112000_LINUX.zip -d /u01/app/11.2.0/grid

[grid@host01 share]$ ssh host02
Last login: Thu Apr 26 12:28:13 2012 from host01.example.com
[grid@host02 ~]$ cd /share
[grid@host02 share]$ unzip p6880880_112000_LINUX.zip -d /u01/app/11.2.0/grid

2. Unzip into $ORACLE_HOME location

============================= =======================================================
As the oracle user, unzip the patch to /u01/app/oracle/product/11.2.0/dbhome_1 on hosts host01,
host02.

[oracle@host01 share]$ unzip p6880880_112000_LINUX.zip -d

/u01/app/oracle/product/11.2.0/dbhome_1

[oracle@host01 share]$ ssh host02 unzip /share/p6880880_112000_LINUX.zip -d

/u01/app/oracle/product/11.2.0/dbhome_1

3. Opatch Upgradation
=====================================================================================

a) Take a backup of ORACLE_HOME/OPatch into a dedicated backup

location.
tar –cvf opatch.tar ./OPatch

b) Please make sure no directory ORACLE_HOME/OPatch exist

c) Please unzip the OPatch downloaded zip into ORACLE_HOME directory

d) Check Opatch version

OCM Configuration

The OPatch utility will prompt for your OCM (Oracle Configuration Manager) response file when it is run.
Because this file has not yet been created, you will need to execute the emocmrsp command as the
oracle user on each node. Do not provide an email address. Because emocmrsp command creates the
response file in the current directory, navigate to
/u01/app/oracle/product/11.2.0/dbhome_1/OPatch/OPatch/ocm before executing.
Validation of Oracle Inventory

Before beginning patch application, check the consistency of inventory information for GI home and each
database home to be patched. Run the following command as respective Oracle home owner to check
the consistency.

$ <ORACLE_HOME>/OPatch/opatch lsinventory -detail -oh <ORACLE_HOME>

If this command succeeds, it lists the Oracle components that are installed in the home. Save the output
so you have the status prior to the patch apply.

If this command fails, contact Oracle Support Services for assistance .

Stop EM Agent Processes Prior to Patching and Prior to Rolling Back the Patch

You must stop the EM agent processes running from the database home, prior to patching the Oracle
RAC database or GI Home and prior to rolling back the patch from Oracle RAC database or GI Home.
Execute the following command on the node to be patched or the node where the patch is to be rolled
back.

As the Oracle RAC database home owner execute:

$ <ORACLE_HOME>/bin/emctl stop dbconsole

Patch Installation

The patch instructions will differ based on the configuration of the Grid infrastructure and the Oracle
RAC database homes. Patching instructions for Oracle RAC Database Homes and GI together are listed
below.

The most common configurations are listed as follows:

 Case 1: GI Home and the Database Homes that are not shared and ACFS file system is not
configured.
 Case 2: GI Home is not shared, Database Home is shared, ACFS may be used .

For other configurations listed below, see My Oracle Support Document 1494646.1:

 GI Home is not shared, the Database Home is not shared, ACFS may be used.
 Patching Oracle RAC Database Homes.

 Patching GI Home alone.

 Patching Oracle Restart Home.

 Patching a software only GI Home installation or before the GI Home is configured.

Patching Oracle RAC Database Homes and GI Together

 Case 1: GI Home and the Database Homes that are not shared and ACFS file system is not
configured.
 As root user, execute the following command on each node of the cluster:

# opatch auto <UNZIPPED_PATCH_LOCATION> -ocmrf <ocm response file>

Ex:

 Case 2: GI Home is not shared, Database Home is shared, ACFS may be used.

Patching instructions:

1. From the Oracle database home, make sure to stop the Oracle RAC databases running
on all nodes. As the database home owner execute:
2. $ <ORACLE_HOME>/bin/srvctl stop database –d <db-unique-name>
3. On the 1st node, unmount the ACFS file systems. See My Oracle Support
Document 1494652.1 for unmounting ACFS file systems.

4. On the 1st node, apply the patch to the GI Home using the opatch auto command. As
root user, execute the following command:

5. # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <GI_HOME> -ocmrf <ocm response

file>
6. If the message, "A system reboot is recommended before using ACFS” is shown, then a
reboot must be issued before continuing. Failure to do so will result in running with an
unpatched ACFS\ADVM\OKS driver.

7. On the 1st node, remount ACFS file systems. See My Oracle Support
Document 1494652.1 for mounting ACFS file systems.

8. On the 1st node, apply the patch to the Database home using the opatch
auto command. Since the Database home is shared, this operation will patch the
Database home across the cluster. Note that a USM only patch cannot be applied to a
database home. As root user, execute the following command:

9. # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <DATABASE_HOME> -ocmrf <ocm

response file>
10. On the 1st node only, restart the Oracle instance, which you have previously stopped in
Step 1. As the database home owner execute:

11. $ <ORACLE_HOME>/bin/srvctl start instance –d <db-unique-name> -n <nodename>

12. On the 2nd (next) node, unmount the ACFS file systems. See My Oracle Support
Document 1494652.1 for unmounting ACFS file systems.

13. On the 2nd node, apply the patch to GI Home using the opatch auto command. As root
user, execute the following command:
 14. # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <GI_HOME> -ocmrf <ocm response
file>
15. If the message, "A system reboot is recommended before using ACFS” is shown, then a
reboot must be issued before continuing. Failure to do so will result in running with an
unpatched ACFS\ADVM\OKS driver.

16. On the 2nd node, running the opatch auto command in Step 9 will restart the stack.

17. On the 2nd node, remount ACFS file systems. See My Oracle Support
Document 1494652.1 for mounting ACFS file systems.

18. On the 2nd node only, restart the Oracle instance, which you have previously stopped in
Step 1. As the database home owner execute:

19. $ <ORACLE_HOME>/bin/srvctl start instance –d <db-unique-name> -n <nodename>

20. Repeat Steps 8 through 13 for all remaining nodes of the cluster.

Patch Post-Installation Instructions

After installing the patch, perform the following actions:

1. Apply conflict resolution patches as explained in Section 2.5.1.

2. If applying a PSU, load modified SQL files into the database, as explained in Section 2.5.2.

3. Upgrade Oracle Recovery Manager catalog, as explained in Section 2.5.3.

2.5.1 Applying Conflict Resolution Patches

Apply the patch conflict resolution one-off patches that were determined to be needed when you
performed the steps in Section 2.2, "One-off Patch Conflict Detection and Resolution".

2.5.2 Loading Modified SQL Files into the Database

The following steps load modified SQL files into the database. For an Oracle RAC environment, perform
these steps on only one node.

1. For each database instance running on the Oracle home being patched, connect to the database
using SQL*Plus. Connect as SYSDBA and run the catbundle.sql script as follows:
2. cd $ORACLE_HOME/rdbms/admin
3. sqlplus /nolog
4. SQL> CONNECT / AS SYSDBA
5. SQL> STARTUP
6. SQL> @catbundle.sql psu apply
7. SQL> QUIT

The catbundle.sql execution is reflected in the dba_registry_history view by a row associated

with bundle series PSU.
 For information about the catbundle.sql script, see My Oracle Support
Document 605795.1 Introduction to Oracle Database catbundle.sql.

8. If the OJVM PSU was applied for a previous GI PSU patch, you may see invalid Java classes after
execution of the catbundle.sql script in the previous step. If this is the case, run utlrp.sql to re-
validate these Java classes.
9. cd $ORACLE_HOME/rdbms/admin
10. sqlplus /nolog
11. SQL> CONNECT / AS SYSDBA
12. SQL> @utlrp.sql
13. Check the following log files in $ORACLE_BASE/cfgtoollogs/catbundle for any errors:

14. catbundle_PSU_<database SID>_APPLY_<TIMESTAMP>.log

15. catbundle_PSU_<database SID>_GENERATE_<TIMESTAMP>.log

where TIMESTAMP is of the form YYYYMMMDD_HH_MM_SS. If there are errors, see Section 3,
"Known Issues".

2.5.3 Upgrade Oracle Recovery Manager Catalog

If you are using the Oracle Recovery Manager, the catalog needs to be upgraded. Enter the following
command to upgrade it:

$ rman catalog username/password@alias

RMAN> UPGRADE CATALOG;

2.6 Patch Post-Installation Instructions for Databases Created or Upgraded after Installation of Patch in
the Oracle Home

These instructions are for a database that is created or upgraded after the installation of the patch.

You must execute the steps in Section 2.5.2, "Loading Modified SQL Files into the Database" for
any new database only if it was created by any of the following methods:

 Using DBCA (Database Configuration Assistant) to select a sample database (General, Data
Warehouse, Transaction Processing)
 Using a script that was created by DBCA that creates a database from a sample database

There are no actions required for databases that have been upgraded.