This content has been marked as final. Show 4 replies
Thanks for your quick reply.
I believe I have done that already:
$> srvctl add database -d stby1 -o /home/path -r PHYSICAL_STANDBY -s MOUNT
or does the modify make a difference?
I am using
$> srvctl config database -d stby1
to display the configuration values
If "add" and "modify" are the same then the problem remains because prim1 database always opens in "READ ONLY WITH APPLY" and the standby only ever opens as far as "MOUNTED". If however I've misunderstood what you're advising then please let me know.
What I'm really looking for is for the primary (whether it be prim1 or stby1) to open READ/WRITE and the standby (whether it be prim1 or stby1) to only go as far as MOUNTED. It seems like the Grid Infrastructure is gettinng some of the information (it knows when the role has changed because it starts up the service properly) but it doesn't affect the open mode.
I would try the modify command.
srvctl modify database -d stby1 -s mount
Followed by this :
srvctl config database -d stby1
You could also specify the start mode as a parameter to the SRVCTL START DATABASE command :
srvctl start database -d stby1 -o mount
srvctl start database -d prim1 -o open
Edited by: mseberg on Dec 17, 2012 8:30 AM
Sorry for the delay in replying. I did some further testing and was about to reply when I decided to raise an SR with Oracle about this.
It seems that this is a known issue (see support.oracle.com article [ID 1436313.1]). However it is not acknowledged as a bug and is in the list of enhancements i.e. may be changed in the next release.
From the article:
"In 11g the Broker does not change the Startmode in Oracle Restart as expected because the Broker does not care for the Status of the Database any more."
The article then suggests using a script (outline example given) to check the value for the start option and amend it if the database had failed/switched over. The advice in the SR was to manually change the start option following/before a switchover.
Neither of these (it seems to me) offers a) a solution for a failover (which can be automated to happen without DBA intervention) or b) a proper switchover method. The fact that the Grid Control switchover command needs to be followed/preceeded by running a script or logging onto the database host to use SRVCTL seems to me an imcomplete solution.
We will discuss it further with Oracle. I wanted to post back my findings as you spent some time on my problem - thanks again for that. If I receive an update I will let you know. Until then I will leave the question marked as unanswered because I have not finished the SR yet.