There are loads of things to do to prepare you for a fast start failover.
First you must have a working set of primary / standby database
Then you must have both databases in flashback mode.
Then verify your dataguard configuration with OEM.
Ok, once you are so far, you will need to review your dataguard property.
lsc01 my primary, lsc05 my standby
edit database lsc01 set LogXptMode='SYNC';
edit database lsc01 set FastStartFailoverTarget= 'lsc05'
edit database lsc05 set LogXptMode='SYNC';
edit database lsc05 set FastStartFailoverTarget= 'lsc01'
EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
then you need to start the observer in the background :
nohup dgmgrl -silent sys/*** "start observer" &
note: it does not work if you connect with /. You will get DGM-16979 if you use / or if you use different passwords in standby and primary.
so far so good, let’s enable fast_start failover in dgmgrl
ENABLE FAST_START FAILOVER
Before you switch, check the listener.ora is correctly configured :
SID_LIST_LISTENER=
(SID_LIST=
(SID_DESC=
(GLOBAL_DBNAME=LSC01_DGMGRL.example.com)
(SID_NAME=LSC01)
(ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1)
)
(SID_DESC=
(GLOBAL_DBNAME=LSC05_DGMGRL.example.com)
(SID_NAME=LSC05)
(ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1)
)
)
LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = precision.example.com)(PORT = 1521))
)
The GLOBAL_DBNAME is mandatory to enable a painless switchover. Otherwise the standby startup will fail with ORA-12514.
UPDATE: alternatively in 11gR2 you can set the dataguard property StaticConnectIdentifier to use SID instead of service name :
edit database lsc05 set property StaticConnectIdentifier=
'(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=precision.example.com)(PORT=1521))
(CONNECT_DATA=(SID=LSC05)))';
edit database lsc01 set property StaticConnectIdentifier=
'(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=precision.example.com)(PORT=1521))
(CONNECT_DATA=(SID=LSC01)))';
in this case you will not need global_dbname in listener.ora. See note 308943.1
Ok, let’s see how fast I can switch
$ time dgmgrl -silent sys/*** "switchover to lsc05"
Performing switchover NOW, please wait...
New primary database "lsc05" is opening...
Operation requires shutdown of instance "LSC01" on database "lsc01"
Shutting down instance "LSC01"...
ORACLE instance shut down.
Operation requires startup of instance "LSC01" on database "lsc01"
Starting instance "LSC01"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "lsc05"
real 1m10.685s
user 0m0.052s
sys 0m0.109s
About one minute. most of the time was spent restarting the original primary as a standby, the primary was already available for queries after about 20 seconds.
When you tested the switchover, where there any users connected to the database ? And if you tested with lots of users connected did you notice any difference ?
Thanks.
The sessions must be closed, I suppose the number of open transactions and connected sessions will have a noticeable impact in the time to switch. The test above is on my notebook with no connection. But a good db server should also be faster than my laptop…
Does it matter the two databases are on the same machine and home?
What good is a dadaguard when on he same server?
@Albert
Dataguard should not be on the same server as it is needed for disaster. Both server should be fairly distant, one on Moon and one on Mars if possible
Unfortunately I have only one notebook…
Oh dear. I wanted to drop a comment as a response to your visit on my blog today but I don’t understand a single line of you just wrote, Laurent ! :DDDDD
ok, you save your transactions on your local disk in geneva, but for each transaction you send a log record to zurich. Once your primary computer stops working, you failover to zurich, and within seconds you have all your data available.
Un peu perdue? go to http://perdu.com 🙂
Pingback: OCM 11g upgrade | Laurent Schneider