note the value of the AUTO_START attribute, in the example above it is "restore". That means that the clusterware will restart it only if it was running when the clusterware was shutdown.
[oracle@iron1 ~]$ crsctl status resource ora.qsx.db -p NAME=ora.qsx.db TYPE=ora.database.type ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r-- ACTION_FAILURE_TEMPLATE= ACTION_SCRIPT= ACTIVE_PLACEMENT=1 AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX% AUTO_START=restore CARDINALITY=2
I stopped by srvctl stop db first, then using crsctl as root to stop crs.
Is this the right way to do? I thought I have to stop db first before crs.
crsctl status resource ora.plt.db -pThe above command when executed in your previous post shows that the database AUTO_START is set to "restore". This would mean that the database state after server reboot would be restored to the state it was before the server reboot. So, in your case, you had the database down before you rebooted the server and hence the database did not come up after the reboot activity.
GregG wrote:Only if you cobnfigured it that way. If you look at the post above, it is clear:
whem You do crsctl stop crs when DB is up and running this is considered shutdown abort , right ?
Can you see the attribute "Stop options"?
srvctl config database -d plt Database unique name: PLT Database name: PLT Oracle home: /u01/app/oracle/product/11.2.0/dbhome_1 Oracle user: oracle Spfile: +DAT/PLT/spfilePLT.ora Domain: Start options: open Stop options: immediate Database role: PRIMARY Management policy: AUTOMATIC Server pools: PLT Database instances: PLT1,PLT2 Disk Groups: +DAT,+FRA Mount point paths: Services: plt_ro_jdbc,plt_ro_oci,plt_rw_jdbc ,plt_rw_ociType: RAC Database is administrator managed