1 person found this helpful
When having more than 1 version database running on GI, you should always ensure that while registering the database with clusterware in OCR you should the srvctl utility of the respective version only.
For, example in order to register and monitor a 10g database via a 11.2 GI, the srvctl utility must be invoked from the 10g RDBMS home only, similarly in order to register a 11.2 database the srvctl utility must be invoked from the 11.2 RDBMS home only. The same stands true for any version
Also, while creating the database via dbca, the dbca utility must be be invoked from the respective homes only.
If you have already done the above and still if the database is not coming up then you need to first verify if the srvctl utility is able to bring up the database or not.
Vandana - Oracle
1. Note Vandana comments.
2. crsctl status res ora.orcl.db -p|grep -i AUTO_START
if result is "AUTO_START=never", execute step 3. if result is restore: it behave in this way "Restores the resource to the same state that it was in when the server stopped". so you can still decided to change it to always.
3. crsctl modify res ora.orcl.db -attr "AUTO_START=always"
srvctl modify database -d orcl -y automatic
For the srvtctl I know that it must be started from the correct home. Teits, as you stated it, my AUTO_START was in "restore". Since I shutdown both instances with srvctl before I restart the Linux cluster, the instances have stayed down. Thank you guy for solving my issue.
1 person found this helpful
For Oracle 11g R2, perform the following procedure on each node of the cluster.
The Oracle ASM instance resource faults if the required Oracle Cluster Synchronization Services process (occsd.bin) is not active. To prevent the resource from faulting, modify the AUTO_START attribute of the CSSD resource (ora.cssd). This configuration change enables the Oracle High Availability Services daemon (ohasd) to start the ocssd.bin process as soon as the ohasd daemon starts on each node in the cluster.
Thus, when the ocssd.bin process starts, it automatically starts up for the ASM instance. However, this could cause concurrency violation issues if the ASMInst resource is configured as a part of failover service group in the following scenario. Suppose a node goes down or reboots for some reason, all the resources on this node comes online on the second node. After the reboot, the ohasd process automatically starts the ocssd.bin process, which automatically starts the ASM instance on node1 which leads to concurrency violation. To resolve this issue, Symantec recommends you to disable automatic startup of asm by running the following command:
# $GRID_HOME/bin/crsctl modify resource ora.asm -attr AUTO_START=never
To enable Oracle Cluster Synchronization Service daemon to start automatically
- Set the AUTO_START attribute of the ora.cssd resource as follows:# $GRID_HOME/bin/crsctl modify resource ora.cssd -attr AUTO_START=always
More information please see: CRSCTL commands that are relevant for Oracle Restart | Mike Desouza&#039;s Blog
I've done the check, our asm resource is configured as you said. Thanks.
Sorry I got here late. You are welcome.