# Fung's DBA World

## Rolling Upgrade RAC From 11g to 12c

April 21, 2016

What I mean rolling is Grid Infrastructure upgrade by rolling, but RDBMS still need outage. To minimize the downtime, and I think upgrade with rolling is more easier than non-rolling, so use rolling upgrade GI is advisable. At the end of this post, I will try to reverse the whole process, that is downgrade RDBMS and GI to before version.

I already have a two-node 11gr2 RAC installed in my VM machine, and I’ll perform a out-of-place upgrade for GI and RDBMS. Out-of-place upgrade can let you rollback or downgrade more easier.

New directories have been created as below.

Whenever upgrade a system, remember that upgrade is a high risk operation, backup is always essential, backup the whole database, the GI and RDBMS home, the configuration files, and so on. Below backup actions is recommended.

• GI and RDBMS home

• A manually physical OCR/OLR backup

• Full database backup

### 1. Some restrictions of rolling upgrade GI

• Not support for block devices or RAW devices

If the OCR and voting disks is located on raw or block devices, need to migrate them to ASM before upgrade.

Below table is the compatibility matrix of clusterware which can be upgrade to 12c directly.

Table 1-1
Oracle version Compatibility
oracle 11.2.0.2 Direct upgrade possible: patch set 11.2.0.2.3 (PSU 3) or later must be applied

Verify node readiness by running pre-upgrade check script under the source code directory:

Fix violations until the verify script pass.

### 3. Performing rolling upgrade GI by response file

Before perform upgrade, the GI environment parameters need to unset or set to new one, I have copied a old profile as .bash_profile_11g, and create a new profile .bash_profile, changed the new parameters direct to 12c.

#### 3.2 Execute the runInstaller to upgrade the GI

GI tools or commands cannot be run until the post root script is executed.

#### 3.3 Execute the post-script

During the post script execution, the database services still remain online, but only one node can serve as normal, another node is out of service at that time. The details will show in the output logs.

You can find “2016/04/19 20:07:19 CLSRSC-482: Running command: ‘/u02/app/grid/12.1.0/bin/crsctl set crs activeversion’” in log file at last node to specify the script will set the activeversion in the last node.

Following script is executed by GRID user, only in the upgrade node:

The ASM diskgroup status:

### 4. Upgrade GI force when some nodes were inactive

When some of the nodes in the cluster are inaccessible, perform a forced upgrade is available. Execute rootupgrade script by root user with force option.

When the inaccessible nodes become active after a forced upgrade, execute the following command in the first node to let the inaccessible node join the cluster.

Although RDBMS can upgrade directly, but it’s recommended install a new RDBMS binary code and then perform a upgrade command.

#### 5.1 RDBMS software installation

RDBMS installation response file :

Install RDBMS with above response file in silent mode:

Execute root script as root user.