Implementing Data Guard - Expert Consolidation in Oracle Database 12c - page 363

Auto-reinstate: TRUE
Observer Reconnect: (none)
Observer Override: FALSE
Configuration Status:
SUCCESS
The output of the Fast Start Failover configuration is shown next:
DGMGRL> show fast_start failover
Fast-Start Failover: ENABLED
Threshold: 30 seconds
Target: CDBFSDCA
Observer: server3.example.com
Lag Limit: 30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Observer Reconnect: (none)
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:
(none)
DGMGRL>
It summarizes the settings which trigger a failover, the ones shown here are the defaults. Note that a graceful
shutdown of the primary will not automatically trigger a failover. Translated into English the FSFO process will be
initiated if the observer and the standby database cannot “see” the primary database for more than 30 seconds. The
lag limit which defines the maximum allowable time the standby is lagging behind the primary to be an eligible target
for an automatic failover is not used in a Maximum Availability configuration. As part of the automated process the
old primary will be shut down to ensure no one can connect to it. The old primary will also be reinstated. And finally,
the observer will not reconnect to its targets. This is a property you should probably change. The value is in seconds;
do not set it too low to incur the overhead of frequent connections but not too high either. Allowing the observer to
reconnect gives you some more resilience over transient network glitches.
The section “configurable failover conditions” allow the administrator to fine-tune the failover conditions, and you
can even add your own custom conditions using ORA-xxxxx error codes. If now for example your network connectivity
from data center A to the rest of the world fails, the Broker will automatically fail over to the designated standby
database. The output from the Observer process in data center C indicates that there has indeed been a problem:
DGMGRL> start observer
Observer started