Resetting the Cluster Synchronization Service daemon (CSSd) in 11g

It is known that part of Oracle's Clusterware is needed, namely the Cluster Synchronization Service daemon (CSSd), in a single instance installation to communicate between a DB instance and an ASM instance. It is necessary to perform some operations as root user before creating an 11g ASM instance under Linux and Unix.

When using the Oracle 11g dbca, it asks that $ORACLE_HOME/bin/localconfig reset be ran in order to upgrade the version of the cluster synchronization services (CSS) if necessary:

Figure 3:  Upgrading CCS in 11g dbca

ASM Rolling Upgrade

An UPGRADE of ASM in a clustered environment is very different from a single instance installation. If there are multiple ASM instances with the parameter cluster_database=TRUE which are protected by the clusterware, the 11g ASM ROLLING UPGRADES New Feature can be used. This allows the ASM software to be upgraded in a rolling fashion, which means node by node in the cluster. This can be done with the new syntax:

ALTER SYSTEM START ROLLING MIGRATION TO 11.2.0.0.0;

% Rolling Upgrade for ASM only works from 11g upwards.
           So this cannot be used to upgrade from 10g to 11g! 

This puts the entire ASM cluster into the rolling upgrade mode. This enables the ASM cluster software to be ran in a multi-version mode. In order to do this, first upgrade the Oracle Clusterware on all nodes of the cluster to the new version before the upgrade of the ASM software can be started. During the rolling upgrade, only very limited operations are allowed in the cluster such as:

• Disk group mount and dismount

• Database file open, close, resize, and delete

• Limited access to fixed views and fixed packages

After the rolling upgrade process has been started, it is possible to shutdown one ASM instance after the other in order to upgrade the software installation.