This content has been marked as final. Show 13 replies
What in the docs led you to move to hugepages? Please post the link and how it relates to your specific database. And where did you do it? Cache fusion interconnect? Storage? Public? Would you like us to guess? Post the commands you used to make the change ... every one, in order, the exact syntax. Also the specific syntax you used to alter the spfile for hugepages.
Finally: Writing "the DB does not start" is as meaningful a statement as saying "my car doesn't start." I can no more tell from thousands of miles away in an internet forum why your database doesn't start than I can tell whether the battery is dead or someone stole the fuel pump. Assume your database was a car ... what would your mechanic ask you? What sound do you hear when you turn the key? Well I'll ask "what did the database write to your alert log?" And please don't describe it ... post it.
Along with all of the other relevant information if you want further help.
Check how the database is registered in the OCR, for example,
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
Thank you for your reply.
Here is the information per your command:
crsctl status resource ora.plt.db -p
DEFAULT_TEMPLATE=PROPERTY(RESOURCE_CLASS=database) PROPERTY(DB_UNIQUE_NAME= CONCAT(PARSE(%NAME%, ., 2), %USR_ORA_DOMAIN%, .)) ELEMENT(INSTANCE_NAME= %GEN_USR_ORA_INST_NAME%) ELEMENT(DATABASE_TYPE= %DATABASE_TYPE%)
DESCRIPTION=Oracle Database resource
START_DEPENDENCIES=hard(ora._DAT.dg,ora._FRA.dg) weak(type:ora.listener.type,global:type:ora.scan_listener.type,uniform:ora.ons,global:ora.gns) pullup(ora._DAT.dg,ora._FRA.dg)
Are they looking right?
How did you stop the database before the server reboot? If you stopped it by using srvctl stop database then it is normal that the database is not coming back automated when the server rebooted. If you stop everything using crsctl command then the database will be back automated. Otherwise check you cluster related log files
Hope it helps
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.
I have seen some environments stop database with srvctl first but I also have seen some other environments stop everything using crsctl. Both command will work without problem. crsctl will stop all resources managed by clusterware.
Hope it helps
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.
What does the "srvctl config database -d plt" show ? Just make sure that the POLICY MANAGEMENT is set to AUTOMATIC and if so then I do not consider there to be any issue.
Just a note: With 11gR2, crsctl is not supported to modify or edit resources with prefix ora.* .
Here is the result from srvctl config database:
rvctl 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
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
if you stopped the db with "srvctl stop database", then this is recorded in OCR. And when the clusterstack restarts it does not restart the database (since you told clusterware it should be stopped).
Works as designed.
If you want that the cluster restarts database simply shutdown the clusterware (crsctl stop crs).
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