From HowtoConfigureorRe-configureGridInfrastructureWithconfig.shconfig.bat (document ID1354258.1) for: OracleDatabase
From How to Configure or Re-configure Grid Infrastructure With config. sh/config. bat (document ID 1354258.1) applies to: Oracle Database-Enterprise Edition-Version 11.2.0.2 and later Information in this document applies to any platform. purpose:
From How to Configure or Re-configure Grid Infrastructure With config. sh/config. bat (Document ID 1354258.1)
Applicable:
Oracle Database-Enterprise Edition-Version 11.2.0.2 and later
Information in this document applies to any platform.
Purpose:
This document explains the config. sh (config. bat on Windows) file in the $ GRID_HOME/crs/config/directory.
Details:
Basic:
"Config. sh" is a new feature of 11.2.0.2 Grid Infrastructure (GI. This feature is used on configure 11gR2 GI Cluster after GI software is installed or cloned.
Config. sh starts the GI configuration framework GUI, which instructs the user to enter necessary information through some pages. Finally, config. sh prompts the user to run the root script. Config. sh can also be run in silent mode (the response file is used at this time)
Config. sh is not a tool for deploying software. Software can be deployed by running OUI or clonig.
This means that if the GI software is damaged, config. sh will not help in this case.
In this case (if GI software is damaged), deinstall or node removal/addition procedure can be used in this case.
You can use config. sh:
On all nodes, use the rootcrs. pl script
In this case, config. sh will ask the cluster parameter to generate GI configuration files and prompt to run root. sh to create a new GI cluster.
Starting from config. sh asking about the configuration information, config. sh does not care whether the original cluster is a completely new installation or an upgrade from the old version,
It does not concern whether the new cluster has the same number of nodes or whether the locations (OCR/VD location, network info etc) are the same as before.
For 11.2.0.3 or later versions, if diskgroup attribute compatible. asm is set to 11.2.0.0 and above
Config. sh can be reused for ocr and vd (re-use). diskgroups already exists.
GI cloned from other clusters
This is part of the clone process. See:
Oracle Clusterware
Administration and Deployment Guide
11g Release 2 (11.2)
After GI only installs software
In this case:
--- If oracle clusterware is not installed before, config. sh will ask cluster parameter to generate GI configuration files and prompt to run root. sh to configure a new GI cluster
--- If an oracle clusterware installation already exists, config. sh will ask cluster parameter to generate the GI configuration files)
Run rootupgrade. sh to upgrade a new GI cluster. In this case, there is no need to deconfigure anything before running config. sh.
--- If a GI Standalone installation already exists, config. sh reports an error. config. sh cannot be used to Upgrade Oracle Restart.
Config. sh cannot be used:
For GI cluster environment, config. sh will go to all nodes in configure/reconfigure cluster during the downtime (down time) of all nodes.
Therefore, config. sh is not the best option for the following scenarios that can be completed without downtime.
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 ").
Parallel Execution of Root script:
When you create or upgrade a GI cluster with multiple nodes, you can run the root script (root. sh or rootupgrade. sh) on the first node and wait until it is complete.
Then, execute the root script (root. sh or rootupgrade. sh) on all other nodes (except the last node) and wait for the completion.
Finally, run the root script (root. sh or rootupgrade. sh) on the last node)
Known issue:
Bug 10158098-Can not find ASM disks
This issue affects 11.2.0.2 only, refer to Document 1277148.1 for more details.
Bug 10055663-OUI stuck after nodes list are specified (INS-42017 cocould be reported)
This issue affects 11.2.0.2 only, Patch 10055663 needs to be applied.
If INS-42017 still happens after the patch is applied, compare GRID_HOME on all nodes to make sure they are the same, especially $ GRID_HOME/inventory/ContentsXML/comps. xml; if there's a discrepancy, investigate for cause (different patches etc) and fix it.
Refer to note 1623645.1 if ORACLE_HOME_NAME is different on different nodes.
Bug 13409054-OUI does not start with "Exception in thread" main "java. lang. UnsatisfiedLinkError: no oraInstaller in java. library. path"
This issue affects 11.2.0.3 on Solaris, it's fixed in 12.1 and the workaround is to modify /Crs/config. pl
Replace the following:
Sub setLdLibraryPath (){
My $ osname = $ ^ O;
$ LD_LIBRARY_PATH = $ ORACLE_HOME. $ dirSep. 'lib'. $ pathSep. $ OUI_LIBRARY_LOCATION;
$ LD_LIBRARY_PATH. = $ pathSep. $ ORACLE_HOME. $ dirSep. 'bin ';
$ LD_LIBRARY_PATH. = $ pathSep. $ ENV {LD_LIBRARY_PATH} if (exists ($ ENV {LD_LIBRARY_PATH }));
$ ENV {LD_LIBRARY_PATH} = $ LD_LIBRARY_PATH;
}
With:
Sub setLdLibraryPath (){
My $ osname = $ ^ O;
$ LD_LIBRARY_PATH = $ ORACLE_HOME. $ dirSep. 'lib'. $ pathSep. $ OUI_LIBRARY_LOCATION;
$ LD_LIBRARY_PATH. = $ pathSep. $ ORACLE_HOME. $ dirSep. 'bin ';
$ LD_LIBRARY_PATH. = $ pathSep. $ ENV {LD_LIBRARY_PATH} if (exists ($ ENV {LD_LIBRARY_PATH }));
$ ENV {LD_LIBRARY_PATH} = $ LD_LIBRARY_PATH;
My $ libpath = $ ENV {LD_LIBRARY_PATH };
$ ENV {LD_LIBRARY_PATH_64} = $ libpath;
}
