Oracle数据库升级GI/CRS到11.2.0.2/3之前注意事项及patch需求，详见metelink doc:

Things to Consider Before Upgrading to 11.2.0.3 Grid Infrastructure/ASM [ID 1363369.1]

Applies to:
Oracle Server - Enterprise Edition - Version: 10.2.0.4 to 11.2.0.3 - Release: 10.2 to 11.2
Information in this document applies to any platform.

Purpose
This document lists things to check, known issues to avoid, and areas to consider to have smooth upgrade to 11.2.0.3 Grid Infrastructure.

It includes instruction to run CVU pre-upgrade check and list of mandatory/recommended patches that should be applied for Oracle Grid Infrastructure and Oracle ASM upgrade.

Scope and Application
This document is intended for Oracle Clusterware Administrators and Oracle Support engineers.

For Exadata, refer to the following note for details:

note 1373255.1 - 11.2.0.1/11.2.0.2 to 11.2.0.3 Database Upgrade on Exadata Database Machine

Things to Consider Before Upgrading to 11.2.0.3 Grid Infrastructure/ASM
11.2.0.3 is a full release, any pre-11.2 Oracle Clusterware (CRS) can be upgraded to 11.2.0.3 directly; also started from 11gR2, in-place patch set upgrade is not supported, any patch set must be installed into a new HOME (out-of-place upgrade).

A. Run CVU pre-upgrade check tool
Execute runcluvfy.sh in unzipped 11.2.0.3 GI software location as grid user to confirm whether the environment is suitable for upgrading:

USAGE: runcluvfy.sh stage -pre crsinst -upgrade [-n ] [-rolling]
-src_crshome -dest_crshome -dest_version
[-fixup [-fixupdir ]] [-verbose]

For example, to upgrade a 3-node Oracle Clusterware in /u01/app/11.1 to 11.2.0.3 in /u01/app/grid in rolling fashion, execute the following:

$ runcluvfy.sh stage -pre crsinst -upgrade -n ,, -rolling -src_crshome /u01/app/11.1 -dest_crshome /u01/app/grid -dest_version 11.2.0.3.0 -fixup -fixupdir /tmp -verbose

Any error from CVU should be fixed before upgrade is attempted. Use CVU option "-fixup" to generate runnable script. for fixable issues, other errors that can not be be fixed by CVU should be fixed manually.

If pre-req patch is not installed, the following will be reported when running rootupgrade.sh:

The cluvfy tool found some mandatory patches are not installed.
These patches need to be installed before the upgrade can proceed.
The pre-upgrade checks failed, aborting the upgrade

B. Ensure consistent network setting
Refer to note 1386709.1 to ensure network information in Oracle Clusterware is consistent with the setting on OS level on all nodes

C. Mandatory/Recommended patches for upgrade
The following table lists the required/recommended patches which should be applied to pre-upgrade clusterware home prior to the upgrade. The table is categorized by Exadata and non-Exadata environment.

The "Minimum source version" indicates prerequisite patches, which must be patched before mandatory upgrading patches being applied, or else patching or installation may fail.

The "Required PSU or one off patch" indicates mandatory patches that must be applied.

[table=98%]
Source Oracle Clusterware version
Minimum source version
Required PSU or one off patch

10.2.0.4
NULL
PATCH 8705958 - 10.2.0.4.2 CRS PSU

10.2.0.5
NULL
PATCH 9952245 - 10.2.0.5.2 CRS PSU

11.1.0.7
NULL
PATCH 11724953 - 11.1.0.7.7 CRS PSU

11.2.0.1
NULL
PATCH 9413827

Or PATCH 9706490 if on AIX, Solaris or HP

11.2.0.2
11.2.0.2 GI PSU1(which includes database PSU1)
PATCH 12539000

D. ASM memory_max_target and memory_target
In 11.2.0.3, init.ora parameter "processes" will be default to "available CPU cores * 80 + 40". As the default value for "memory_target" is based on "processes", it can be insufficient if there's large number of CPU cores or large number of diskgroups which could cause issues (i.e. GI stack fails to stop with ORA-04031 etc), it's recommended to increase the value of memory_max_target and memory_target before upgrading to 11.2.0.3(does not apply to 10g ASM):

Log in to ASM:

SQL> show parameter memory_target

If the value is smaller than 1536m, issue the following:

SQL> alter system set memory_max_target=4096m scope=spfile;
SQL> alter system set memory_target=1536m scope=spfile;

The number 1536m has proven to be sufficient for most environment, the change will not be effective until next restart.