Saturday, September 24, 2011

Upgrade Grid Infrastructure for cluster (11.2.0.2 to 11.2.0.3)

Oracle 11.2.0.3 patchset(10404530) is available, So I just upgraded Grid Infrastructure for cluster (11.2.0.2 to 11.2.0.3)
- Check software version
[root@db01 ~]# /u01/app/11.2.0/grid/bin/crsctl query crs activeversion
Oracle Clusterware active version on the cluster is [11.2.0.2.0]
[root@db01 ~]# /u01/app/11.2.0/grid/bin/crsctl query crs releaseversion
Oracle High Availability Services release version on the local node is [11.2.0.2.0]
[root@db01 ~]# /u01/app/11.2.0/grid/bin/crsctl query crs softwareversion db01
Oracle Clusterware version on node [db01] is [11.2.0.2.0]
[root@db01 ~]# /u01/app/11.2.0/grid/bin/crsctl query crs softwareversion db02
Oracle Clusterware version on node [db02] is [11.2.0.2.0]
- Downloaded software: patchset(10404530)
[oracle@db01 11.2.0.3]$ ls p10404530_112030_Linux-x86-64_3of7.zip
p10404530_112030_Linux-x86-64_3of7.zip
[oracle@db01 11.2.0.3]$unzip p10404530_112030_Linux-x86-64_3of7.zip
- Installation (I chose "silent" mode) *** while crs was starting ***
[oracle@db01 11.2.0.3]$ cd grid
[oracle@db01 grid] ./runInstaller -silent -ignoreSysPrereqs -ignorePrereq -responseFile /home/oracle/11.2.0.3/grid/response/grid_install.rsp ORACLE_HOME="/u01/app/11.2.0/grid_1" oracle.install.option="UPGRADE" oracle.install.crs.upgrade.clusterNodes=db01,db02 oracle.install.asm.OSDBA=asmadmin oracle.install.asm.OSOPER=asmoper oracle.install.asm.OSASM=asmadmin
Starting Oracle Universal Installer...

Checking Temp space: must be greater than 120 MB. Actual 43557 MB Passed
Checking swap space: must be greater than 150 MB. Actual 16386 MB Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2011-09-24_05-54-05PM. Please wait ...

You can find the log of this install session at:
/u01/app/oraInventory/logs/installActions2011-09-24_05-54-05PM.log

Please check '/u01/app/oraInventory/logs/silentInstall2011-09-24_05-54-05PM.log' for more details.

As a root user, execute the following script(s):
1. /u01/app/11.2.0/grid_1/rootupgrade.sh

Execute /u01/app/11.2.0/grid_1/rootupgrade.sh on the following nodes:
[db01, db02]

As install user, execute the following script to complete the configuration.
1. /u01/app/11.2.0/grid_1/cfgtoollogs/configToolAllCommands

Note:
1. This script must be run on the same system from where installer was run.
2. This script needs a small password properties file for configuration assistants that require passwords (refer to install guide documentation).

Successfully Setup Software.
*** review log files ***

- Run "rootupgrade.sh" script
Go TO root@db01:
[root@db01 ~]# /u01/app/11.2.0/grid_1/rootupgrade.sh
Check /u01/app/11.2.0/grid_1/install/root_db01_2011-09-24_18-03-54.log for the output of root script
If instance stills online, you should shutdown before. because you will see message("Shutting down instance (abort)") in alert log file.

- Just check ...
[root@db01 ~]# /u01/app/11.2.0/grid_1/bin/crsctl query crs activeversion
Oracle Clusterware active version on the cluster is [11.2.0.2.0]
[root@db01 ~]# /u01/app/11.2.0/grid_1/bin/crsctl query crs releaseversion
Oracle High Availability Services release version on the local node is [11.2.0.3.0]
[root@db01 ~]# /u01/app/11.2.0/grid_1/bin/crsctl query crs softwareversion
Oracle Clusterware version on node [db01] is [11.2.0.3.0]
[root@db01 ~]# /u01/app/11.2.0/grid_1/bin/crsctl query crs softwareversion db02
Oracle Clusterware version on node [db02] is [11.2.0.2.0]
*** activeversion is 11.2.0.2.0 ***

Go TO root@db02:
[root@db02 ~]# /u01/app/11.2.0/grid_1/rootupgrade.sh
Check /u01/app/11.2.0/grid_1/install/root_db02_2011-09-24_18-12-17.log for the output of root script
If instance stills online, you should shutdown before. because you will see message("Shutting down instance (abort)") in alert log file..

- Check again ...
After used "/u01/app/11.2.0/grid_1/rootupgrade.sh" on db02.
[root@db01 ~]# /u01/app/11.2.0/grid_1/bin/crsctl query crs activeversion
Oracle Clusterware active version on the cluster is [11.2.0.3.0]
[root@db01 ~]# /u01/app/11.2.0/grid_1/bin/crsctl query crs releaseversion
Oracle High Availability Services release version on the local node is [11.2.0.3.0]
[root@db01 ~]# /u01/app/11.2.0/grid_1/bin/crsctl query crs softwareversion
Oracle Clusterware version on node [db01] is [11.2.0.3.0]
[root@db01 ~]# /u01/app/11.2.0/grid_1/bin/crsctl query crs softwareversion db02
Oracle Clusterware version on node [db02] is [11.2.0.3.0]
*** activeversion is 11.2.0.3.0 ***

- Run "/u01/app/11.2.0/grid_1/cfgtoollogs/configToolAllCommands"
[oracle@db01 grid]$ /u01/app/11.2.0/grid_1/cfgtoollogs/configToolAllCommands
Setting the invPtrLoc to /u01/app/11.2.0/grid_1/oraInst.loc

perform - mode is starting for action: configure

perform - mode finished for action: configure

You can see the log file: /u01/app/11.2.0/grid_1/cfgtoollogs/oui/configActions2011-09-24_06-21-18-PM.log
*** should review /u01/app/11.2.0/grid_1/cfgtoollogs/oui/configActions2011-09-24_06-21-18-PM.log file ***

- Check all resources: It should
[oracle@db01 grid]$ /u01/app/11.2.0/grid_1/bin/crsctl stat res -init -t
[oracle@db01 grid]$ /u01/app/11.2.0/grid_1/bin/crsctl stat res -t
Related Post:
Upgrade - Oracle Database 11.2.0.2 to 11.2.0.3
Upgrade database 11.2.0.1.0 to 11.2.0.2.0 : dbua -silent
struggle to Upgrade Oracle Database 11.2.0.1 to 11.2.0.2
Just upgrade Oracle Database 10gR2 to 11gR2 by command-line
Just Step to upgrade (RAC) 10.2.0.4 to 11.1.0.6
Creating Database 11gR1 on ASM 11gR2

7 comments:

Nukesh Bhoyar said...

Surachart, Great post and that ends my seaching for the way for this upgradatation. One thing I would like to know is if I have a multinode operational cluster, Can this be done in rolling fashion on each node one by one? Also on other blog I read that "To upgrade existing Oracle Grid Infrastructure installations from 11.2.0.2 to a later release, you must apply patch 11.2.0.2.1 (11.2.0.2 PSU 1) or later", is this mendatory?

Regards
Nukesh

Surachart Opun said...

when we are upgrading 11.2.0.2 -> 11.2.0.3 (GI)
I recommend you have to stop GI all nodes when you run "rootupgrade.sh" script.

> "To upgrade existing Oracle Grid Infrastructure installations from 11.2.0.2 to a later release, you must apply patch 11.2.0.2.1 (11.2.0.2 PSU 1) or later"

I am not sure this. I find out in Oracle Support before.

However, when you install 11.2.0.3. Oracle software will force you install in new folder. So, It wasn't supposed to use 11.2.0.2 PSU 1.

By the way, You should read README in patch files before.

Nukesh Bhoyar said...

Thanks. There is one more pre reqs seems to install 12539000 (11203:ASM UPGRADE FAILED ON FIRST NODE WITH ORA-03113)before upgrade. My life doesn't seems easy as I have around 50 databases on 6 node 11.2.0.2 cluster. What is the best approach or recommendation you think for such scenarios.

Surachart Opun said...

OK ..
- patch 12539000
You can patch each nodes. Don't need to stop Cluster all nodes

- 11.2.0.3
You can test it before, If you need to stop node01 -> run it "rootupgrade.sh" -> start node01 -> stop node02 -> run it "rootupgrade.sh" ->

have to test... because You might spend a lot time, when it has the issue.

I still recommend stop GI Cluster all nodes

- Upgrade database ...
A. Install new home... and upgrade each of databases

Anyway, You should check why don't you need to upgrade.

If you have system 24 x 7 and no bugs yet. You should not risk with downtime.

Nukesh Bhoyar said...

Okay Thanks Surachart... Appreciate your feedback...

Anonymous said...

Hi,

is it correct that the CRS services and ASM,database instances are to be kept runnning when executing runinstaller and root scripts

you mentioned in the post:
"If instance stills online, you should shutdown before. because you will see message("Shutting down instance (abort)") in alert log file.."

is this required or will the upgrade script shut down ASM instance,crs,database instance

Surachart Opun said...

When we have executed runinstaller for installation on new folder (GRID). It's not affect with ASM/Database.

Anyway, when you execute "rootupgrade.sh", that will stop your GI(CRS/ASM/...)services. That might stop abort your instance.
So, You should stop database before.