Review these user, path, group, and memory requirements and recommendations for Oracle Grid Infrastructure, Oracle ASM, and Oracle Real Application Clusters upgrades.

You must install Oracle Clusterware and Oracle Real Application Clusters (Oracle RAC) into separate, new homes from the existing installation homes. Separate Grid homes and Oracle homes for Oracle Grid Infrastructure and Oracle RAC reduces the downtime required to upgrade a node in the cluster, and facilitates the provisioning of clusters within an enterprise. Reducing planned outage time required for cluster upgrades helps to meet availability service levels, and also enables you to provide a standard installation across the enterprise.

• To upgrade Oracle Database, you must install the Oracle Grid Infrastructure software into a new Grid home, and install Oracle Database 12c software into the new Oracle home. This also applies to Oracle Grid Infrastructure for a standalone server (Oracle Restart). You can upgrade from supported releases only.

• On Windows x64 platforms, to upgrade Oracle Clusterware from releases 10.2.0.5 or 11.1.0.7 to release 12.1, you must perform an interim upgrade to 11.2.0.4 for Oracle Clusterware. After upgrading Oracle Clusterware to release 11.2.0.4, you must move the Oracle Cluster Registry (OCR) and voting files (VDSK) to Oracle ASM. You can then upgrade Oracle Clusterware release 11.2.0.4 to release 12.1.

• If you are upgrading an Oracle Database release 10.2.0.5 or release 11.1.0.7 environment that stores Oracle Clusterware files on OCFS on Windows or RAW devices, then you cannot directly upgrade to Oracle Database 12c.

• For Oracle Database release 10.2.0.5, either all Oracle software installations were owned by the Oracle user, typically oracle, or Oracle Database software was owned by the user oracle, and Oracle Clusterware software was owned by a separate user, typically crsuser.

• Starting with Oracle Database release 11.1, the user account that owns the release 10.2.0.5 Oracle Clusterware software must perform the Oracle Clusterware release 11.1.0.7 upgrade. The user account that is performing this upgrade must also be the user that owns the ASM home of the earlier release. If the earlier ASM home has a different owner, then you must change the installation owner user account for the Oracle ASM software to be the same user account that owns the Oracle Clusterware Oracle home (CRS home). You must complete this change before you perform the upgrade.

• For Oracle Database releases 11.1.07 and 10.2.0.5, if your configuration does not include Oracle ASM, then you must shut down the cluster synchronization services (CSS) daemon and delete the CSS service from the system by running the localconfig command with the delete option. For example:

  ORACLE_HOME/bin/localconfig delete
  

• When upgrading Oracle Clusterware, OUI automatically calls Oracle ASM Configuration Assistant (ASMCA) to perform the upgrade of the Oracle Automatic Storage Management component in the Oracle Grid Infrastructure home. The Grid Infrastructure home can be local to each node.

• On Linux platform installations, Oracle recommends that you use HugePages to obtain the best performance for Oracle Databases. When you upgrade Oracle Grid Infrastructure and Oracle Databases on servers that have HugePages enabled, Oracle recommends that you review your HugePages memory allocation requirements.

  Oracle Grid Infrastructure installations include the Grid Infrastructure Management Repository (GIMR). When HugePages is configured on cluster member nodes, the GIMR system global area (SGA) is installed into HugePages memory. The GIMR SGA occupies up to 1 GB of HugePages memory. Oracle Grid Infrastructure starts up before Oracle Databases installed on the cluster.

  If your cluster member node operating system memory allocations to HugePages are insufficient for the size of the SGAs for all of the Oracle Database instances on the cluster, then you may find that one or more of your Oracle Database SGAs are mapped to regular pages, instead of Huge Pages, which reduces expected performance. To avoid this issue, when you plan your upgrade, ensure that the memory you reserve for HugePages is large enough to accommodate your memory requirements.

• For a single-instance configuration, Oracle ASM and Oracle Restart run from the Oracle Grid Infrastructure home. Oracle ASM and Oracle Restart are upgraded to Oracle Grid Infrastructure 12c at the same time.

• You must ensure that the database compatibility attribute for Oracle ASM disk groups matches the compatibility parameter that is set in init.ora.

Understand Oracle Clusterware upgrade changes for rolling upgrades, and use this procedure to ensure that Oracle Clusterware is started on the local node.

Starting with Oracle Database 12c, non-rolling upgrades for Oracle Real Application Clusters require Oracle Clusterware on the local node to be up and running. The Oracle Clusterware stack on the local node must be running.

With earlier releases of Oracle Database, selecting the non-rolling option for the cluster meant that OUI set ISROLLING to false for all stack shutdowns before the upgrade process started. With this option, if any of the cluster nodes was up, then ISROLLING was set to true. However, in Oracle Database 12c, rolling means that the local stack is up before upgrade, and that the other stacks must be shut down. Only in this circumstance OUI sets ISROLLING to false.

1. Run the OUI installer on the node where the Oracle Clusterware stack is running or open a terminal.

2. Log in as root or Administrator.

3. Change directory (cd) to the Oracle Clusterware home (Grid home), and start Oracle Clusterware by entering the following command:

   # crsctl start crs

Oracle recommends that you use Database Upgrade Assistant (DBUA) to upgrade an existing Oracle RAC database to the current release of Oracle Database.

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.

If you are manually upgrading an Oracle RAC database, then you perform most upgrade actions on only one node of the system. Note that in some steps you must perform actions on multiple cluster member nodes.

Use this procedure to upgrade inaccessible nodes if you are using the force cluster upgrade command.

$ rootupgrade.sh -join -existingnode upgraded_node

Oracle Clusterware for Oracle Database 12c requires time synchronization across all nodes within a cluster when Oracle RAC is deployed.

There are two options for time synchronization:

• Your operating system-configured network time protocol (NTP)

  or

• Oracle Cluster Time Synchronization Service

Oracle ASM upgrade procedures are changed in current Oracle ASM releases.

Oracle ASM is installed when you install the Oracle Grid Infrastructure components. Oracle ASM shares an Oracle home with Oracle Clusterware when installed in a cluster with Oracle RAC or with Oracle Restart on a standalone server. Before the new Oracle Database software can be installed on the system, the root script for upgrading Oracle Grid Infrastructure starts Oracle ASM Configuration Assistant (ASMCA) to upgrade Oracle ASM to the new release.

If you have an existing Oracle ASM instance, then you can either upgrade it when you install Oracle Grid Infrastructure, or you can upgrade it after the installation, using ASMCA. When you install the new software for Oracle Database 12c, Oracle Universal Installer (OUI) runs the root script root.sh when it detects a cluster. OUI provides an option to automate the root script execution tasks on the nodes of the cluster. You are prompted to provide information and passwords to enable OUI to run the root.sh script automatically. You now have an option to automate the root.sh script execution tasks on the nodes of the cluster.

For Oracle Automatic Storage Management (Oracle ASM) environments, you can create shared ASM password files.

The password file is created by the ORAPWD utility. Oracle recommends that you use the SYSASM privilege to separate database management and storage management responsibilities. Also, you have the option to create separate operating system credentials for Oracle ASM and each database. This separation allows for an even greater division of database management and storage management responsibilities. For instance, if there are n databases using Oracle ASM on a given node, then you can configure n + 1 sets of operating system credentials groups whose members have SYS privileges: one OSDBA group for each database with SYSDBA privileges, and one OSASM group for the Oracle ASM instance with SYSASM privileges.