In today’s article, we will examine Fast-Start Failover Configuration.
The configuration of Fast-Start Failover consists of the following 8 steps in summary.
A. Identifying the Fast-start Failover Standby Database
B. Setting Data Protection Mode
C. Setting the threshold value at which Fast-start Failover will occur
Ç. Setting additional Fast-start Failover features
D. Setting the additional conditions we want to happen
E. Activating Fast-start Failover
F.Starting Observer
G. Verifying the configuration
Now let’s see how these operations are done.
Commands run from DGMGRL will be run from Primary-1 unless specified separately.
A. Identifying the Fast-start Failover Standby Database
The first step of Fast-start Failover configuration is to determine the Target Standby Database.
1. We query the current status of the Fast-start Failover configuration.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | DGMGRL> show configuration Configuration - Broker_Configuration Protection Mode: MaxPerformance Databases: primary - Primary database standby - Physical standby database logical - Logical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS |
2. We question the Fast-start Failover configuration in detail.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | DGMGRL> show fast_start failover Fast-Start Failover: DISABLED Threshold: 30 seconds Target: (none) Observer: (none) Lag Limit: 30 seconds 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) |
3. Fast-start Failover Target Standby Database is determined.
1 2 | DGMGRL> edit database primary set property FastStartFailoverTarget=standby; Property "faststartfailovertarget" updated |
4. We query the Fast-start Failover configuration again.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | DGMGRL> show fast_start failover Fast-Start Failover: DISABLED Threshold: 30 seconds Target: (none) Observer: (none) Lag Limit: 30 seconds 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) |
There is no change in the configuration. It is necessary to ENABLE Fast-start Failover for it to appear, or we can see it when queried as follows.
1 2 3 4 | DGMGRL> show database primary FastStartFailoverTarget; FastStartFailoverTarget = 'standby' DGMGRL> show database standby FastStartFailoverTarget; FastStartFailoverTarget = '' |
B. Setting Data Protection Mode
To enable Fast-start Failover, Data Protection mode must be in either Maximum Availability or Maximum Performance mode.
It is important to choose the right protection mode, as it has a direct effect on data loss in the event of a disaster.
If it is decided to use Maximum Performance mode, the FastStartFailoverLagLimit parameter must be set.
This parameter determines that Fast-start Failover will be activated when the maximum number of seconds of lag occurs.
1. We check the current Data Protection Mode.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | DGMGRL> show configuration Configuration - Broker_Configuration Protection Mode: MaxPerformance Databases: primary - Primary database standby - Physical standby database logical - Logical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS |
2. We question Redo-Transport Mods.
1 2 3 4 5 6 | DGMGRL> show database primary 'LogXptMode'; LogXptMode = 'ASYNC' DGMGRL> show database standby 'LogXptMode'; LogXptMode = 'ASYNC' DGMGRL> Show database logical 'LogXptMode'; LogXptMode = 'ASYNC' |
3. If I want Redos to SYNC to Fast-start Failover Standby Database, I follow these steps.
1 2 3 4 5 6 | DGMGRL> edit database primary set property 'LogXptMode'=SYNC; Property "LogXptMode" updated DGMGRL> edit database standby set property LogXptMode=SYNC; Property "logxptmode" updated DGMGRL> edit configuration set protection mode as MaxAvailability; Succeeded. |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | DGMGRL> show configuration Configuration - Broker_Configuration Protection Mode: MaxAvailability Databases: primary - Primary database Warning: ORA-16629: database reports a different protection level from the protection mode standby - Physical standby database logical - Logical standby database Fast-Start Failover: DISABLED Configuration Status: WARNING |
The reason for this error is because I did not use the correct syntax when setting LogXptMode for Primary Database.
The syntax is corrected and queried again.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | DGMGRL> edit database primary set property LogXptMode=SYNC; Property "logxptmode" updated DGMGRL> show configuration Configuration - Broker_Configuration Protection Mode: MaxAvailability Databases: primary - Primary database standby - Physical standby database logical - Logical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS |
4. To see how to set the FastStartFailoverLagLimit parameter when Maximum Performance mode is used, I change the Protection Mode again and set the parameter.
The default value of this parameter is 30 seconds.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | DGMGRL> show configuration verbose Configuration - Broker_Configuration Protection Mode: MaxPerformance Databases: primary - Primary database standby - Physical standby database logical - Logical standby database Properties: FastStartFailoverThreshold = '30' OperationTimeout = '30' FastStartFailoverLagLimit = '30' CommunicationTimeout = '180' ObserverReconnect = '0' FastStartFailoverAutoReinstate = 'TRUE' FastStartFailoverPmyShutdown = 'TRUE' BystandersFollowRoleChange = 'ALL' ObserverOverride = 'FALSE' ExternalDestination1 = '' ExternalDestination2 = '' PrimaryLostWriteAction = 'CONTINUE' Fast-Start Failover: DISABLED Configuration Status: SUCCESS |
1 2 3 4 | DGMGRL> edit database primary set property LogXptMode=ASYNC; Error: ORA-16802: downgrading redo transport mode from SYNC disallowed Failed. |
The reason for this error is that the Protection Mode needs to be changed first.
1 2 3 4 5 6 7 8 | DGMGRL> edit configuration set protection mode as MaxPerformance; Succeeded. DGMGRL> edit database primary set property LogXptMode=ASYNC; Property "logxptmode" updated DGMGRL> edit database standby set property LogXptMode=ASYNC; Property "logxptmode" updated DGMGRL> edit database logical set property LogXptMode=ASYNC; Property "logxptmode" updated |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | DGMGRL> show configuration Configuration - Broker_Configuration Protection Mode: MaxPerformance Databases: primary - Primary database standby - Physical standby database logical - Logical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS |
1 2 3 4 5 6 | DGMGRL> show database primary LogXptMode; LogXptMode = 'async' DGMGRL> show database standby LogXptMode; LogXptMode = 'async' DGMGRL> show database logical LogXptMode; LogXptMode = 'async' |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | DGMGRL> edit configuration set property FastStartFailoverLagLimit=900; Property "faststartfailoverlaglimit" updated DGMGRL> show configuration verbose Configuration - Broker_Configuration Protection Mode: MaxPerformance Databases: primary - Primary database standby - Physical standby database logical - Logical standby database Properties: FastStartFailoverThreshold = '30' OperationTimeout = '30' FastStartFailoverLagLimit = '900' CommunicationTimeout = '180' ObserverReconnect = '0' FastStartFailoverAutoReinstate = 'TRUE' FastStartFailoverPmyShutdown = 'TRUE' BystandersFollowRoleChange = 'ALL' ObserverOverride = 'FALSE' ExternalDestination1 = '' ExternalDestination2 = '' PrimaryLostWriteAction = 'CONTINUE' Fast-Start Failover: DISABLED Configuration Status: SUCCESS |
C. Setting the threshold value at which Fast-start Failover will occur
Fast-start Failover Standby Database and how long the Observer does not receive a response from the Primary Database, determines how Fast-start Failover will be triggered.
This is done with the FastStartFailoverThreshold parameter.
This parameter must be set very accurately to prevent an unnecessary failover.
For example, if our network connection is constantly interrupted for a few seconds, setting this parameter value low will do more harm than good.
Oracle recommends the optimum values to set this parameter based on.
For a system with a single instace Primary with almost no network latency: 10-15 seconds
For a network latency system with a single instace Primary: 30-45 seconds
For a build with RAC Primary: CSS Miss Count + Reconfiguration Time + 24-40 seconds.
The CSS Miss Count is found as follows.
1 2 3 | [grid@primary1 ~]$ cd $GRID_HOME [grid@primary1 grid]$ crsctl get css misscount; CRS-4678: Successful get misscount 30 for Cluster Synchronization Services. |
1. In the light of the information above, I set this value to 100 since I use RAC structure and CSS MissCount value is 30 seconds.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | DGMGRL> show configuration verbose Configuration - Broker_Configuration Protection Mode: MaxPerformance Databases: primary - Primary database standby - Physical standby database logical - Logical standby database Properties: FastStartFailoverThreshold = '30' OperationTimeout = '30' FastStartFailoverLagLimit = '900' CommunicationTimeout = '180' ObserverReconnect = '0' FastStartFailoverAutoReinstate = 'TRUE' FastStartFailoverPmyShutdown = 'TRUE' BystandersFollowRoleChange = 'ALL' ObserverOverride = 'FALSE' ExternalDestination1 = '' ExternalDestination2 = '' PrimaryLostWriteAction = 'CONTINUE' Fast-Start Failover: DISABLED Configuration Status: SUCCESS |
1 2 | DGMGRL> edit configuration set property FastStartFailoverThreshold=100; Property "faststartfailoverthreshold" updated |
1 2 | DGMGRL> show configuration FastStartFailoverThreshold FastStartFailoverThreshold = '100' |
Ç. Setting additional Fast-start Failover features
In order to use Fast-start Failover most accurately, I need to set many additional parameters.
a. FastStartFailoverLagLimit
We have given information in Protection mode, but there are some restrictions on the use of this parameter.
A conscious use is essential as it is a parameter that directly affects data loss.
Can be set while in Maximum Performance Mode.
Maximum Availability is invalid in this mode because SYNC is already running.
Real-Time Apply must be enabled on the standby side.
The default value is 30 and the minimum value is 10.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | DGMGRL> edit configuration set property FastStartFailoverLagLimit=900; Property "faststartfailoverlaglimit" updated DGMGRL> show configuration verbose Configuration - Broker_Configuration Protection Mode: MaxPerformance Databases: primary - Primary database standby - Physical standby database logical - Logical standby database Properties: FastStartFailoverThreshold = '30' OperationTimeout = '30' FastStartFailoverLagLimit = '900' CommunicationTimeout = '180' ObserverReconnect = '0' FastStartFailoverAutoReinstate = 'TRUE' FastStartFailoverPmyShutdown = 'TRUE' BystandersFollowRoleChange = 'ALL' ObserverOverride = 'FALSE' ExternalDestination1 = '' ExternalDestination2 = '' PrimaryLostWriteAction = 'CONTINUE' Fast-Start Failover: DISABLED Configuration Status: SUCCESS |
b. FastStartFailoverPmyShutdown
It determines whether the Primary Database will be closed after the Failover that will occur by disconnecting the Primary Database from the Observer and Target Standby Database.
The default value is TRUE, that is, it is turned off.
TRUE: After the Failover that occurs after the FastStartFailoverThreshold value, the Primary Database is shut down with Shutdown Abort.
FALSE: Primary Database is not turned off to see what is causing the failover.
This information is visible from the V$FS_FAILOVER_STATS view.
If I don’t want it shut down.
1 2 3 4 | DGMGRL> edit configuration set property FastStartFailoverPmyShutdown=FALSE; Property "faststartfailoverpmyshutdown" updated DGMGRL> show configuration FastStartFailoverPmyShutdown FastStartFailoverPmyShutdown = 'FALSE' |
I set it back to TRUE because I want it to be turned off.
1 2 3 4 | DGMGRL> edit configuration set property FastStartFailoverPmyShutdown=TRUE ; Property "faststartfailoverpmyshutdown" updated DGMGRL> show configuration FastStartFailoverPmyShutdown FastStartFailoverPmyShutdown = 'TRUE' |
In case of user configuration or an application with SYSDBA authorization calls Failover with the DBMS_DG.INITIATE_FS_FAILOVER function, the Primary Database is shutdown even if this parameter is set to FALSE.
c. FastStartFailoverAutoReinstate
It specifies whether the Primary Database, which will no longer work after failover, will be automatically made as a Physical Standby Database.
We call this process REINSTATE. Its default value is TRUE. There are some prerequisites for this process.
The FastStartFailoverAutoReinstate parameter is TRUE.
Before failover and after the original Primary Database’s restart, the original and new primary databases must have the same Fast-start Failover configuration.
The Observer that will perform the REINSTATE and the New Primary Database must be able to connect to the original Primary database.
If automatic REINSTATE is not requested;
1 2 3 4 | DGMGRL> edit configuration set property FastStartFailoverAutoReinstate=FALSE; Property "faststartfailoverautoreinstate" updated DGMGRL> show configuration FastStartFailoverAutoReinstate FastStartFailoverAutoReinstate = 'FALSE' |
I want automatic REINSTATE again I set the parameter to TRUE.
1 2 3 4 | DGMGRL> edit configuration set property FastStartFailoverAutoReinstate=TRUE; Property "faststartfailoverautoreinstate" updated DGMGRL> show configuration FastStartFailoverAutoReinstate FastStartFailoverAutoReinstate = 'TRUE' |
ç. ObserverConnectIdentifier
It is the parameter that determines how the Observer will be connected to the Primary and Standby Database.
By default, this value takes the “DGConnectIdentifier” parameter. If a different value is not used, there is no need to set it.
We set it as follows.
1. We query the current value of the parameter.
1 2 3 4 5 6 | DGMGRL> show database primary ObserverConnectIdentifier ObserverConnectIdentifier = '' DGMGRL> show database standby ObserverConnectIdentifier ObserverConnectIdentifier = '' DGMGRL> show database logical ObserverConnectIdentifier ObserverConnectIdentifier = '' |
2. We set the parameter to its new value.
1 2 3 4 5 6 | DGMGRL> edit database primary set property ObserverConnectIdentifier=PRIMARY; Property "observerconnectidentifier" updated DGMGRL> edit database logical set property ObserverConnectIdentifier=LOGICAL; Property "observerconnectidentifier" updated DGMGRL> edit database standby set property ObserverConnectIdentifier=STANDBY; Property "observerconnectidentifier" updated |
3. We check if the new value is set.
1 2 3 4 5 6 | DGMGRL> show database primary ObserverConnectIdentifier ObserverConnectIdentifier = 'primary' DGMGRL> show database standby ObserverConnectIdentifier ObserverConnectIdentifier = 'standby' DGMGRL> show database logical ObserverConnectIdentifier ObserverConnectIdentifier = 'logical' |
4. We said that if the parameter was not set, we would use DGConnectIdentifier.
The DGConnectIdentifier is queried to see its value.
1 2 3 4 5 6 | DGMGRL> show database logical DGConnectIdentifier DGConnectIdentifier = 'logical' DGMGRL> show database primary DGConnectIdentifier DGConnectIdentifier = 'primary' DGMGRL> show database standby DGConnectIdentifier DGConnectIdentifier = 'standby' |
d. ObserverOverride
Even if the Standby Database has communication with the Primary, it indicates whether the Failover operation will be performed in case the Observer’s communication with the Primary is lost. Default is FALSE.
1 2 3 4 | DGMGRL> edit configuration set property ObserverOverride=FALSE; Property "observeroverride" updated DGMGRL> show configuration ObserverOverride ObserverOverride = 'FALSE' |
e. ObserverReconnect
It determines how often the Observer will establish a connection with the Primary Database. Default value is 0.
In other words, a connection will be established initially, and then there will be no request to establish a connection again.
The advantage of this is that it does not burden the system with new connections, and the disadvantage is that it is not possible to understand whether the Primary will go or not without new connection requests.
Oracle recommends that this value be set so that neither too often a connection load nor too rare a disconnection of communication is detected too late.
1 2 3 4 | DGMGRL> edit configuration set property ObserverReconnect=15; Property "observerreconnect" updated DGMGRL> show configuration ObserverReconnect ObserverReconnect = '15' |
D. Setting the additional conditions we want to happen
When the following conditions occur apart from the parameters, it may request the Failover to be triggered without waiting for the FastStartFailoverThreshold value.
When Datafile goes offline,
When Dictionary Corruption occurs in a critical database object,
If the Control File is damaged due to a problem with the disk,
In case LGWR process cannot write to Online Redo Logs,
If the archive process cannot create an archive due to lack of space in the relevant path, FAST START FAILOVER operation takes place.
When a specific ORA error is received…
1. What these features are can be seen as follows.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | DGMGRL> show fast_start failover Fast-Start Failover: DISABLED Threshold: 100 seconds Target: (none) Observer: (none) Lag Limit: 900 seconds Shutdown Primary: TRUE Auto-reinstate: TRUE Observer Reconnect: 15 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: (none) |
2. We can enable a condition that is NO in the default as follows.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | DGMGRL> enable fast_start failover condition "Inaccessible Logfile"; Succeeded. DGMGRL> show fast_start failover Fast-Start Failover: DISABLED Threshold: 100 seconds Target: (none) Observer: (none) Lag Limit: 900 seconds Shutdown Primary: TRUE Auto-reinstate: TRUE Observer Reconnect: 15 seconds Observer Override: FALSE Configurable Failover Conditions Health Conditions: Corrupted Controlfile YES Corrupted Dictionary YES Inaccessible Logfile YES Stuck Archiver NO Datafile Offline YES Oracle Error Conditions: (none) |
3. We can enable specific ORA errors as follows.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | DGMGRL> enable fast_start failover condition '1578'; Succeeded. DGMGRL> show fast_start failover; Fast-Start Failover: DISABLED Threshold: 100 seconds Target: (none) Observer: (none) Lag Limit: 900 seconds Shutdown Primary: TRUE Auto-reinstate: TRUE Observer Reconnect: 15 seconds Observer Override: FALSE Configurable Failover Conditions Health Conditions: Corrupted Controlfile YES Corrupted Dictionary YES Inaccessible Logfile YES Stuck Archiver NO Datafile Offline YES Oracle Error Conditions: ORA-01578: ORACLE data block corrupted (file # %s, block # %s) |
E. Activating Fast-start Failover
I can now enable Fast-start Failover after I have made both parameter and all condition’ settings.
There is no Observer at this stage yet. Primary Database and Fast-start Failover Standby Database are communicating.
We will get this warning when we enable Fast-start Failover anyway.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | DGMGRL> enable fast_start failover; Enabled. DGMGRL> show configuration Configuration - Broker_Configuration Protection Mode: MaxPerformance Databases: primary - Primary database Warning: ORA-16819: fast-start failover observer not started standby - (*) Physical standby database Warning: ORA-16819: fast-start failover observer not started logical - Logical standby database Fast-Start Failover: ENABLED Configuration Status: WARNING |
1 2 3 4 5 6 | Fri Jan 27 13:33:54 2017 Fast-Start Failover (FSFO) has been enabled between: Primary = "primary" Standby = "standby" Fri Jan 27 13:33:54 2017 FSFP started with pid=27, OS id=21775 |
1 2 | Fri Jan 27 13:34:12 2017 FSFP started with pid=49, OS id=31147 |
1 2 | [root@primary1 ~]# ps -ef |grep fsfp |grep -v grep oracle 21775 1 0 13:33 ? 00:00:00 ora_fsfp_primary1 |
1 2 | [root@primary2 ~]# ps -ef |grep fsfp |grep -v grep oracle 31147 1 0 13:34 ? 00:00:00 ora_fsfp_primary2 |
F.Starting Observer
Observer must first be run on a separate server, if available, or run on Fast-start Failover Standby Database.
When the Observer is run, it tells the Broker to manage the monitoring job of the Data Guard Environment via DGMGRL.
There is only 1 Observer in the Data Guard Environment.
It does all the management with a small configuration file containing information and connection definitions of Observer, Primary and Standby Databases.
Observer is a foreground process. Therefore, it keeps the command prompt busy all the time.
Once stopped, something can be done at the command prompt again.
Therefore, it should be at a point where it will work continuously.
For example, on Terminal servers.
1. The Observer is started.
1 2 | DGMGRL> start observer; Observer Started. |
2. We are querying the status of the configuration.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | DGMGRL> show configuration Configuration - Broker_Configuration Protection Mode: MaxPerformance Databases: primary - Primary database standby - (*) Physical standby database logical - Logical standby database Fast-Start Failover: ENABLED Configuration Status: SUCCESS |
3. The Terminal window where the Observer is started is closed with a cross and the status of the Configuration is questioned.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | DGMGRL> show configuration Configuration - Broker_Configuration Protection Mode: MaxPerformance Databases: primary - Primary database standby - (*) Physical standby database logical - Logical standby database Fast-Start Failover: ENABLED Configuration Status: SUCCESS |
Although the Observer was not running, it did not give an error warning in the configuration.
The reason is that the ObserverReconnect parameter is set to 15 seconds.
We wait for a while and question again.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 | DGMGRL> show configuration verbose Configuration - Broker_Configuration Protection Mode: MaxPerformance Databases: primary - Primary database Error: ORA-16820: fast-start failover observer is no longer observing this database standby - (*) Physical standby database Error: ORA-16820: fast-start failover observer is no longer observing this database logical - Logical standby database (*) Fast-Start Failover target Properties: FastStartFailoverThreshold = '100' OperationTimeout = '30' FastStartFailoverLagLimit = '900' CommunicationTimeout = '180' ObserverReconnect = '15' FastStartFailoverAutoReinstate = 'TRUE' FastStartFailoverPmyShutdown = 'TRUE' BystandersFollowRoleChange = 'ALL' ObserverOverride = 'FALSE' ExternalDestination1 = '' ExternalDestination2 = '' PrimaryLostWriteAction = 'CONTINUE' Fast-Start Failover: ENABLED Threshold: 100 seconds Target: standby Observer: standby1.tivibulab.local Lag Limit: 900 seconds Shutdown Primary: TRUE Auto-reinstate: TRUE Observer Reconnect: 15 seconds Observer Override: FALSE Configuration Status: ERROR |
G. Verifying the configuration
After all operations, it is checked whether there is an error in the configuration.
There are 3 ways.
1. The broker configuration is queried.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 | DGMGRL> show configuration verbose Configuration - Broker_Configuration Protection Mode: MaxPerformance Databases: primary - Primary database standby - (*) Physical standby database logical - Logical standby database (*) Fast-Start Failover target Properties: FastStartFailoverThreshold = '100' OperationTimeout = '30' FastStartFailoverLagLimit = '900' CommunicationTimeout = '180' ObserverReconnect = '15' FastStartFailoverAutoReinstate = 'TRUE' FastStartFailoverPmyShutdown = 'TRUE' BystandersFollowRoleChange = 'ALL' ObserverOverride = 'FALSE' ExternalDestination1 = '' ExternalDestination2 = '' PrimaryLostWriteAction = 'CONTINUE' Fast-Start Failover: ENABLED Threshold: 100 seconds Target: standby Observer: standby1.tivibulab.local Lag Limit: 900 seconds Shutdown Primary: TRUE Auto-reinstate: TRUE Observer Reconnect: 15 seconds Observer Override: FALSE Configuration Status: SUCCESS |
2. The Fast_start Failover configuration is queried.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | DGMGRL> show fast_start failover Fast-Start Failover: ENABLED Threshold: 100 seconds Target: standby Observer: standby1.tivibulab.local Lag Limit: 900 seconds Shutdown Primary: TRUE Auto-reinstate: TRUE Observer Reconnect: 15 seconds Observer Override: FALSE Configurable Failover Conditions Health Conditions: Corrupted Controlfile YES Corrupted Dictionary YES Inaccessible Logfile YES Stuck Archiver NO Datafile Offline YES Oracle Error Conditions: ORA-01578: ORACLE data block corrupted (file # %s, block # %s) |
3. We query from the v$DATABASE view.
1 2 3 4 5 6 7 | [Primary-1] SQL> set linesize 9000 [Primary-1] SQL> column FS_FAILOVER_OBSERVER_HOST format a24 [Primary-1] SQL> select FS_FAILOVER_STATUS, FS_FAILOVER_CURRENT_TARGET, FS_FAILOVER_THRESHOLD, FS_FAILOVER_OBSERVER_PRESENT, FS_FAILOVER_OBSERVER_HOST from v$database; FS_FAILOVER_STATUS FS_FAILOVER_CURRENT_TARGET FS_FAILOVER_THRESHOLD FS_FAILOVER_OBSERVER_PRESENT FS_FAILOVER_OBSERVER_HOST ---------------------- ------------------------------ --------------------- ------- ------------------------ TARGET UNDER LAG LIMIT standby 100 YES standby1.tivibulab.local |
The values and meanings of the FS_FAILOVER_STATUS column