De-Configure & Re-configure GI / Cluster Nodes

when you are De-configuring the cluster there are various reasons. One of the most common case is when root.sh failed on the node. In this case one has to deconfigure the cluster node with -force option and has to run root.sh manually. 

Also there are other use cases for De-configure - 

This procedure applies only when all the followings are true:

• One or partial nodes are having problem, but one or other nodes are running fine - so there's no need to deconfigure the entire clustere

• And GI is a fresh installation (NOT upgrade) without any patch set (interim patch or patch set update(PSU) is fine).

• And cluster parameters have not been changed since original configuration, eg: OCR/VD on same location, network configuration has not been changed etc

Steps to de-configure-

As root, on each problematic node, execute:

# <$GRID_HOME>/crs/install/rootcrs.pl -deconfig -force

Steps to reconfigure       

         # <$GRID_HOME>/root.sh
There is one caveat to this process and that is use of config.sh utility. The config.sh utility invokes the wizard that will ask you the properties of the cluster and prepare the rootcrs_param file, which will be copied to all cluster nodes. It will also prompt you to run root.sh( which will in turn call rootconfig script ).
config.sh only needs to be run on one node of the cluster – all required files are propagated to other nodes within the cluster

Cases that config.sh can be used:

• After GI cluster is deconfigured with rootcrs.pl on all nodes

• After GI is cloned from other cluster

• After GI is installed with software only option

Cases that config.sh is not the best tool:

For GI cluster environment, as it will configure/reconfigure all nodes in the cluster which means down time, it is not the best tool for the following scenarios as no down time is needed to accomplish these tasks:

• one or more nodes are having problem, but there is node or nodes that are running fine, in this case, node removal/addition procedure can be used to avoid downtime.

• one or more nodes are having problem, but there is node or nodes that are running fine, and the cluster is freshly installed without any patch set regardless how long it has been running - if patch set update(PSU) has been applied, that is fine, and cluster parameters are not changed since original configuration, eg: OCR/VD on same location, network configuration has not been changed etc, and GRID_HOME is intact. In this case, deconfig and reconfig on each problematic node can be used (as root, execute "$GRID_HOME/crs/install/rootcrs.pl -deconfig -force" then "$GRID_HOME/root.sh").

If the above doesn't fix the issue then, node removal/addition procedure should be used.

Some important points to remember when Re-running root.sh

• Logfiles
• root.sh log file :    $GRID_HOME/cfgtoollogs/crsconfig/rootcrs_grac31.log
• Checkpoint File    $GRID_HOME/u01/app/grid/Clusterware/ckptxxx.xml
• Voting disks and OCR are re-discovered rerunning root.sh
• User created resources like database resources or service resources are rediscovered
• root.sh reconfigures OLR / OHASD ( files in  /etc/rc.d/ /etc/init.d are recreated )
• Backup OCR / OLR before rerunning root.sh
• rootcrs.pl -deconfig -force -verbose  -lastnode does not  delete the +OCR DG
• If you need to cleanup your OCR DG  you may need to use dd command to erase the +OCR disks ( see reference section )