F How to Upgrade to Oracle Grid Infrastructure 11g Release 2

This appendix describes how to perform Oracle Clusterware and Oracle Automatic Storage Management upgrades.

Oracle Clusterware upgrades can be rolling upgrades, in which a subset of nodes are brought down and upgraded while other nodes remain active. Oracle Automatic Storage Management 11g release 2 (11.2) upgrades can be rolling upgrades. If you upgrade a subset of nodes, then a software-only installation is performed on the existing cluster nodes that you do not select for upgrade.

This appendix contains the following topics:

Back Up the Oracle Software Before Upgrades
Restrictions for Clusterware and ASM Upgrades to Grid Infrastructure
Verify System Readiness for Upgrades
Upgrading an Existing Oracle Clusterware Installation
Performing Rolling Upgrades From an Earlier Release
Updating DB Control and Grid Control Target Parameters
Downgrading Oracle Clusterware After an Upgrade

F.1 Back Up the Oracle Software Before Upgrades

Before you make any changes to the Oracle software, Oracle recommends that you create a backup of the Oracle software and databases.

F.2 Restrictions for Clusterware and ASM Upgrades to Grid Infrastructure

Be aware of the following restrictions and changes for upgrades to Oracle grid infrastructure installations, which consists of Oracle Clusterware and Automatic Storage Management (Oracle ASM):

To upgrade existing Oracle Clusterware installations to Oracle grid infrastructure 11g, your release must be greater than or equal to 10.1.0.3, 10.2.0.3, or 11.1.0.6.
To upgrade existing Oracle ASM installations to Oracle grid infrastructure 11g release 2 (11.2) in a rolling fashion, your release must be at least 11.1.0.6.

See Also:
Oracle Upgrade Companion" Note 785351.1 on My Oracle Support:
https://metalink.oracle.com
Oracle Clusterware and Oracle ASM upgrades are always out-of-place upgrades. With 11g release 2 (11.2), you cannot perform an in-place upgrade of Oracle Clusterware and Oracle ASM to existing homes.
If the existing Oracle Clusterware home is a shared home, note that you can use a non-shared home for the grid infrastructure for a cluster home for Oracle Clusterware and Oracle ASM 11g release 2 (11.2).
Before Oracle Database 11g, either all Oracle software installations were owned by the Oracle user, typically oracle, or Oracle Database software was owned by oracle, and Oracle Clusterware software was owned by a separate user, typically crs. Starting with Oracle Database 11g, the same user that owned the Oracle Clusterware 10g software must perform the Oracle Clusterware 11g upgrade.
Oracle ASM and Oracle Clusterware both run in the Oracle grid infrastructure home.
During a major version upgrade to 11g release 2 (11.2), the software in the 11g release 2 (11.2) grid infrastructure home is not fully functional until the upgrade is completed. Running srvctl, crsctl, and other commands from the 11g release 2 (11.2) home is not supported until the final rootupgrade.sh script is run and the upgrade is complete across all nodes.

To manage databases in the existing earlier version (release 10.x or 11.1) database homes during the grid infrastructure upgrade, use the srvctl from the existing database homes.
During Oracle Clusterware installation, if there is a standalone Oracle ASM version on the local node, then it is converted to a clustered Oracle ASM 11g release 2 (11.2) installation, and Oracle ASM runs in the Oracle grid infrastructure home on all nodes.
If a standalone (non-clustered) Oracle ASM installation is on a remote node, which is a node other than the local node (the node on which the Oracle grid infrastructure installation is being performed), then it will remain a standalone Oracle ASM installation. However, during installation, if you select to place the Oracle Cluster Registry (OCR) and voting disk files on Oracle ASM, then a clustered Oracle ASM installation is created on all nodes in the cluster, and the standalone Oracle ASM installation on the remote node will become nonfunctional.

F.3 Verify System Readiness for Upgrades

Use the Cluster Verification Utility to assist you with system checks in preparation for starting a database upgrade.

F.4 Upgrading an Existing Oracle Clusterware Installation

If you have an existing Oracle Clusterware installation, then you upgrade your existing cluster by performing an out-of-place upgrade. You cannot perform an in-place upgrade.

F.4.1 Preparing to Upgrade an Existing Oracle Clusterware Installation

Complete the following tasks before starting an upgrade:

For each node, use Cluster Verification Utility to ensure that you have completed preinstallation steps. It can generate Fixup scripts to help you to prepare servers. In addition, the installer will help you to ensure all required prerequisites are met.

Ensure that you have information you will need during installation, including the following:
- An Oracle base location for Oracle Clusterware.
- An Oracle grid infrastructure home location that is different from your existing Oracle Clusterware location
- A SCAN address
- Privileged user operating system groups to grant access to Oracle ASM data files (the OSDBA for ASM group), to grant administrative privileges to the Oracle ASM instance (OSASM group), and to grant a subset of administrative privileges to the Oracle ASM instance (OSOPER for ASM group)
- root user access, to run scripts as root during installation
For the installation owner running the installation, if you have environment variables set for the existing installation, then unset the environment variables $ORACLE_HOME and $ORACLE_SID, as these environment variables are used during upgrade. For example:
```
$ unset ORACLE_BASE
$ unset ORACLE_HOME
$ unset ORACLE_SID
```

F.5 Performing Rolling Upgrades From an Earlier Release

Use the following procedures to upgrade Oracle Clusterware or Automatic Storage Management:

Verify System Readiness for Upgrades
Performing a Rolling Upgrade of Oracle Clusterware
Performing a Rolling Upgrade of Automatic Storage Management

Note:

When you upgrade to Oracle Clusterware 11g release 2 (11.2), Automatic Storage Management (Oracle ASM) is installed in the same home as Oracle Clusterware. In Oracle documentation, this home is called the "grid infrastructure home," or Grid home. Also note that Oracle does not support attempting to add additional nodes to a cluster during a rolling upgrade.

F.5.1 Verify System Readiness for Upgrades

Use Cluster Verification Utility to assist you with system checks in preparation for starting a database upgrade. The installer runs the appropriate CVU checks automatically, and either prompts you to fix problems, or provides a fixup script to be run on all nodes in the cluster before proceeding with the upgrade.

With Oracle Clusterware 11g release 2 (11.2), you can perform upgrades on a shared Oracle Clusterware home.

F.5.2 Performing a Rolling Upgrade of Oracle Clusterware

Use the following procedure to upgrade Oracle Clusterware from an earlier release to a later release:

Note:

Oracle recommends that you leave Oracle RAC instances running. When you start the root script on each node, that node's instances are shut down and then started up again by the rootupgrade.sh script.

For standalone Oracle Databases on the cluster, only those that use Oracle ASM need to be shut down. Listeners do not need to be shut down.

Start the installer, and select the option to upgrade an existing Oracle Clusterware and Oracle ASM installation.
On the node selection page, select all nodes.

Note:
In contrast with releases prior to Oracle Clusterware 11g release 2, all upgrades are rolling upgrades, even if you select all nodes for the upgrade.
Oracle recommends that you select all cluster member nodes for the upgrade, and then shut down database instances on each node before you run the upgrade root script, starting the database instance up again on each node after the upgrade is complete. You can also use this procedure to upgrade a subset of nodes in the cluster.
Select installation options as prompted.

When prompted, run the rootupgrade.sh script on each node in the cluster that you want to upgrade. The script shuts down the earlier release installation, replaces it with the new Oracle Clusterware release, and starts the new Oracle Clusterware installation.

After the rootupgrade.sh script is run on a node, the upgraded Oracle Clusterware stack and AUTOSTART resources are started on the node.
Run the rootupgrade.sh script on each node on which you are performing the rolling upgrade. Run the script on the local node first. After the script completes successfully, you can run the script in parallel on all nodes except for one, which you select as the last node. When the script is run successfully on all the nodes except the last node, run the script on the last node.
After running the rootupgrade.sh script on the last node in the cluster, ASM Configuration Assistant runs automatically, and the Oracle Clusterware upgrade is complete.

If an earlier version of Automatic Storage Management is installed, then the installer starts ASM Configuration Assistant to upgrade Oracle ASM to 11g release 2 (11.2). You can choose to upgrade Oracle ASM at this time, or upgrade it later.

Oracle recommends that you upgrade Oracle ASM at the same time that you upgrade the Oracle Clusterware binaries. Until ASM is upgraded, Oracle databases that use ASM can't be created. Until ASM is upgraded, the 11g release 2 (11.2) ASM management tools in the Grid home (for example, srvctl) will not work.

Note:
At the end of the upgrade, if you set the OCR backup location manually to the older release Oracle Clusterware home (CRS home), then you must change the OCR backup location to the Oracle grid infrastructure home (Grid home). If you did not set the OCR backup location manually, then this issue does not concern you.
Because upgrades of Oracle Clusterware are out-of-place upgrades, the previous release Oracle Clusterware home cannot be the location of the OCR backups. Backups in the old Oracle Clusterware home could be deleted.

F.5.3 Performing a Rolling Upgrade of Automatic Storage Management

After you have completed the Oracle Clusterware 11g release 2 (11.2) upgrade, if you did not choose to upgrade Oracle ASM when you upgraded Oracle Clusterware, then you can do it separately using the Automatic Storage Management Configuration Assistant (asmca) to perform rolling upgrades.

You can use asmca to complete the upgrade separately, but you should do it soon after you upgrade Oracle Clusterware, as Oracle ASM management tools such as srvctl will not work until Oracle ASM is upgraded.

Note:

ASMCA performs a rolling upgrade only if the earlier version of Oracle ASM is either 11.1.0.6 or 11.1.0.7. Otherwise, ASMCA performs a normal upgrade, in which ASMCA brings down all Oracle ASM instances on all nodes of the cluster, and then brings them all up in the new Grid home.

F.5.3.1 Preparing to Upgrade Oracle ASM

Note the following if you intend to perform rolling upgrades of Oracle ASM:

The active version of Oracle Clusterware must be 11g release 2 (11.2). To determine the active version, enter the following command:
```
$ crsctl query crs activeversion
```
You can upgrade a standalone Oracle ASM installation to a clustered Oracle ASM installation. However, you can only upgrade an existing standalone Oracle ASM installation if you run the installation from the node on which the Oracle ASM installation is installed. You cannot upgrade a single instance Oracle ASM installation on a remote node.
You must ensure that any rebalance operations on your existing Oracle ASM installation are completed before starting the upgrade process.
During the upgrade process, you alter the Oracle ASM instances to an upgrade state. Because this upgrade state limits Oracle ASM operations, you should complete the upgrade process soon after you begin. The following are the operations allowed when an Oracle ASM instance is in the upgrade state:
- Diskgroup mounts and dismounts
- Opening, closing, resizing, or deleting database files
- Recovering instances
- Queries of fixed views and packages: Users are allowed to query fixed views and run anonymous PL/SQL blocks using fixed packages, such as dbms_diskgroup)

F.5.3.2 Upgrading Oracle ASM

Complete the following procedure to upgrade Oracle ASM:

On the node you plan to start the upgrade, set the environment variable ASMCA_ROLLING_UPGRADE as true. For example:
```
$ export ASMCA_ROLLING_UPGRADE=true
```
From the Oracle grid infrastructure 11g release 2 (11.2) home, start ASMCA. For example:
```
$ cd /u01/11.2/grid/bin
$ ./asmca
```
Select Upgrade.

ASM Configuration Assistant upgrades Oracle ASM in succession for all nodes in the cluster.

F.6 Updating DB Control and Grid Control Target Parameters

Because Oracle Clusterware release 2 (11.2) is an out-of-place upgrade of the Oracle Clusterware home in a new location (the grid infrastructure for a cluster home, or Grid home), the path for the CRS_HOME parameter in some parameter files must be changed. If you do not change the parameter, then you encounter errors such as "cluster target broken on dbcontrol or Grid control.

Use the following procedure to resolve this issue:

Log in to dbconsole or gridconsole.
Navigate to the Cluster tab.
Click Monitoring Configuration
Update the value for Oracle Home with the new Grid home path.

F.7 Downgrading Oracle Clusterware After an Upgrade

After a successful or a failed upgrade to Oracle Clusterware 11g release 2 (11.2), you can restore Oracle Clusterware to the previous version.

The restoration procedure in this section restores the Clusterware configuration to the state it was in before the Oracle Clusterware 11g release 2 (11.2) upgrade. Any configuration changes you performed during or after the 11g release 2 (11.2) upgrade are removed and cannot be recovered.

To restore Oracle Clusterware to the previous release:

On all remote nodes, use the command syntax Grid_home/crs/install/rootcrs.pl -downgrade [-force] to stop the 11g release 2 (11.2) resources, shut down the 11g release 2 (11.2) stack.

Note:
This command does not reset the OCR, or delete ocr.loc.

For example:
```
# /u01/app/grid/11.2.0/crs/install/rootcrs.pl -downgrade
```
If you want to stop a partial or failed 11g release 2 (11.2) installation and restore the previous release Oracle Clusterware, then use the -force flag with this command.
After the rootcrs.pl -downgrade script has completed on all remote nodes, on the local node use the command syntax Grid_home/crs/install/rootcrs.pl -downgrade -lastnode -oldcrshome pre11.2_crs_home -version pre11.2_crs_version [-force], where pre11.2_crs_home is the home of the earlier Oracle Clusterware installation, and pre11.2_crs_version is the release number of the earlier Oracle Clusterware installation.

For example:
```
# /u01/app/grid/11.2.0/crs/install/rootcrs.pl -downgrade  -lastnode -oldcrshome 
/u01/app/crs -version 11.1.0.6.0
```
This script downgrades the OCR, and removes binaries from the Grid home. If you want to stop a partial or failed 11g release 2 (11.2) installation and restore the previous release Oracle Clusterware, then use the -force flag with this command.
After the local node script completes, you are prompted to run root.sh from the earlier release Oracle Clusterware installation home in sequence on each member node of the cluster. After you complete this task, downgrade is completed.

Running root.sh from the earlier release Oracle Clusterware installation home restarts the Oracle Clusterware stack, starts up all the resources previously registered with Oracle Clusterware in the older version, and configures the old initialization scripts to run the earlier release Oracle Clusterware stack.