Review these topics if your Oracle Database installations are on Oracle Grid Infrastructure, so that your upgrade plan must include an Oracle Grid Infrastructure upgrade.
Oracle Database installations on Oracle Grid Infrastructure (Oracle Clusterware and Oracle Automatic Storage Management) cannot be a later version than Oracle Grid Infrastructure. Upgrade Oracle Grid Infrastructure first before upgrading Oracle Databases installed on Oracle Grid Infrastructure. This requirement applies both to single-instance and to Oracle Real Application Clusters (Oracle RAC) Oracle Database installations.
Oracle Grid Infrastructure and Oracle Clusterware Upgrade Recommendations
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 220.127.116.11 to release 12.1, you must perform an interim upgrade to 18.104.22.168 for Oracle Clusterware. After upgrading Oracle Clusterware to release 22.214.171.124, you must move the Oracle Cluster Registry (OCR) and voting files (VDSK) to Oracle ASM. You can then upgrade Oracle Clusterware release 126.96.36.199 to release 12.1.
If you are upgrading an Oracle Database release 10.2.0.5 or release 188.8.131.52 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
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 184.108.40.206 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
localconfigcommand with the
deleteoption. For example:
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
Oracle Grid Infrastructure Installation Guide for your operating system and go to the appendix for complete information on how to perform Oracle Clusterware and Oracle Automatic Storage Management upgrades
Oracle Clusterware Must Be Running on Local Node When Upgrading
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
Run the OUI installer on the node where the Oracle Clusterware stack is running or open a terminal.
Log in as root or Administrator.
Change directory (cd) to the Oracle Clusterware home (Grid home), and start Oracle Clusterware by entering the following command:
# crsctl start crs
About Upgrading an Oracle Real Application Clusters (Oracle RAC) Database with DBUA
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.
Oracle Grid Infrastructure Installation Guide for your operating system
Upgrading Inaccessible Nodes
Use this procedure to upgrade inaccessible nodes if you are using the
force cluster upgrade command.
Starting with Oracle Database 12c, you can join inaccessible nodes, as an alternative to deleting the nodes, which was the required method in earlier releases for inaccessible nodes. Before you join nodes, the new Oracle Database 12c software must already be installed on the nodes.
Run the following command on the inaccessible or unreachable nodes to upgrade and join them into the cluster.
$ rootupgrade.sh -join -existingnode upgraded_node
In this command, the
upgraded_node variable refers to one node in the cluster that has already been upgraded. The
-existingNode argument must specify the upgraded node.
Oracle Grid Infrastructure Installation Guide for your platform for information about the
force cluster upgrade procedure
About Requirements for Time Synchronization on Oracle RAC
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)
Oracle Cluster Time Synchronization Service
Oracle Grid Infrastructure Installation Guide for your operating system for information on configuring NTP and Oracle Cluster Time Synchronization Service
Recommendations for Upgrading Oracle RAC and Oracle Databases That Use ASM
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.
About Upgrading System Authentication for Oracle ASM Instances
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
Oracle Automatic Storage Management Administrator's Guide for more information about managing a shared password file in a disk group
Oracle Automatic Storage Management Administrator's Guide for more information about system authentication for Oracle ASM