Examine the Data Guard configuration:
DGMGRL> show configuration:
Configuration-Animals
Protection Mode: MaxAvailability
Databases:
Sheep- Primary database
Warning: ORA-16817: unsynchronized fast-start failover configuration
Dogs – (*) Physical standby database (disabled)
ORA- 16661: the standby database needs to be reinstated
Fast-Start Failover: ENABLED
Configuration Status:
WARNINGAnd the fast-start failover configuration:
DGMGRL> show fast_start failover;
Fast-Start Failover: ENABLED
Threshold : 30 seconds
Target: dogs
Observer : 017.example.com
Lag Limit: 30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Observer Reconnect: 10 seconds
Observer Override: FALSE
Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Offline YES
Oracle error Conditions:
ORA-01578: ORACLE data block corrupted (file # %s, block # %s)
And finally the reason for the fail over:
SQL> select last_failover_reason from v$fs_failover_stats;
LAST_FAILOVER_REASON
ORA-01578: ORACLE data block corrupted (file # %s, block # %s)
Identify the task, or sequence of tasks, to bring the configuration into the SUCCESS state.
A.
Bring Dogs to the NOMOUNT state and let the broker reinstate Dogs automatically.
B.
MOUNT DOGS and issue “reinstate database dogs:” at the DGMGRL prompt while connected to Dogs.
C.
MOUNT DOGS and issue “reinstate database dogs:” at the DGMGRL prompt while connected to Sheep.
D.
Open Dogs and let the broker reinstate Dogs automatically.
Explanation:
The command REINSTATE DATABASE reinstates a database as a new standby database in the broker
configuration for the current primary database.
https://docs.oracle.com/cd/B28359_01/server.111/b28295/dgmgrl.htm#BABDACIF
Correct Ans: D
Here Auto-reinstate: TRUE
If a fast-start failover was initiated because the primary database had crashed or lost connectivity with the observer and target standby database, the observer automatically attempts to reinstate the former primary database as a standby database, if the FastStartFailoverAutoReinstate configuration property is set to TRUE.
To allow the observer to automatically reinstate the former primary database, the database must be started and mounted, but it cannot be opened. The observer will restart the former primary database to the mounted state if it is open, prior to reinstating the database. The broker reinstates the database as a standby database of the same type as the former standby database of the new primary database.
D – Observer identifies DOGS is open instead of mount and automatically restart it in mount state and reinstate DOGS.
If the former primary database cannot be reinstated automatically, you can manually reinstate it using either the DGMGRL REINSTATE command or Cloud Control.
Note the two settings
Shutdown Primary: TRUE
Auto-reinstate: TRUE
In this case Primary database will be shutdown by Observer when it encounters errors so you just have to mount the database and let the Observer do the rest but you can also open the database and leave it to observer. Observer will shutdown dogs and then mount it and reinstate dogs.
Did you test it?
Yes
I think here the primary database is sheep and it is working fine and the problem is with the standby database [dogs]so auto reinstate property only working if the former primary database had crashed or lost connectivity with the observer and target standby database, the observer automatically attempts to reinstate the former primary database as a standby database, if the FastStartFailoverAutoReinstate configuration property is set to TRUE.
Please note:
SQL> select last_failover_reason from v$fs_failover_stats;
LAST_FAILOVER_REASON
ORA-01578: ORACLE data block corrupted (file # %s, block # %s)
Which means fast start failover has already occurred……
Former primary (current standby) will be shutdown based on the configuration settings.
D