Enable Fast Start Failover Data Guard Broker

 

Configure fast-start failover with Oracle Data Guard Broker for HA

Configure Fast Start Failover

Check StaticConnectIdentifier: In order to enable FSFO, the StaticConnectIdentifier parameter must be set both in primary and standby

On primary(test):
===================
dgmgrl sys/sys@test

DGMGRL> show database test StaticConnectIdentifier;
DGMGRL> show database test_s StaticConnectIdentifier;

If StaticConnectIdentifier is blank: The StaticConnectIdentifier takes its value from LOCAL_LISTENER parameter from the database. If this value is not set (or blank) for any database above, then connect to sqlplus and edit LOCAL_LISTENER parameter

SQL> ALTER SYSTEM SET LOCAL_LISTENER='(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.204)(PORT=1521))';

Once you make changes to LOCAL_LISTENER parameter, you must restart the listener.

Note:----->>>the Above is required only if you have RAC and ASM environment since we are working on standalone database skip all the above steps

 

Define FastStartFailoverTarget: In general, there can be more than one physical standby database. So, we need to pair physical standby with primary to let Fast Start Failover know which physical standby to be activated

On primary (test):

====================

dgmgrl sys/sys@test

DGMGRL> SHOW FAST_START FAILOVER

DGMGRL> EDIT DATABASE test SET PROPERTY FastStartFailoverTarget = 'test_s';

DGMGRL> EDIT DATABASE test_s SET PROPERTY FastStartFailoverTarget = 'test';

DGMGRL> show database verbose test;

DGMGRL> show database verbose test_s;

Define FastStartFailoverThreshold: Next we need to let broker know when to initiate automatic failover. What is the time (in seconds) that FSFO will wait before initiating failover

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold=30;

DGMGRL> show fast_start failover

Define FastStartFailoverLagLimit: We can optionally define how much time (in seconds) data we are ready to lose in case the Data Guard is in Max Performance Mode

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverLagLimit = 30;

Enable FSFO: Now we can enable FSFO. Never start observer on production database

On Standby Server:

==================

 

dgmgrl sys/sys@test_s

 

DGMGRL> ENABLE FAST_START FAILOVER;

DGMGRL> show configuration;

DGMGRL> start observer;

Test FSFO Configuration

Let us simulate a failure. We will abort primary (test) instance and wait for FSFO to perform automatic failover.

Simulate failure: On test, the current primary, let us shut abort the instance

On primary (test):

===================

sqlplus / as sysdb

SQL> shut abort;

Check logfiles: At this stage, check alert log and observer log files. FSFO must perform automatic failover and test_s would be your new primary database

check client connectivity.

SQL> select name, open_mode, db_unique_name from v$database;

On new primary (test_s):

===========================

sqlplus / as sysdba

SQL> select name, open_mode, db_unique_name from v$database;

Reinstate Failed Primary

Mount the failed primary (test) and it will auto reinstate. 

Note: Do not open the database as it will be switched to physical standby

On failed primary (test):

===========================

sqlplus / as sysdba

SQL> startup mount;

 

dgmgrl sys/sys@test

DGMGRL> show configuration;

You can perform switchover to get back the original configuration

On current primary (test_s):

===============================

dgmgrl sys/sys@test_s

DGMGRL> show configuration;

DGMGRL> switchover to test;

Disable FSFO

dgmgrl sys/sys@test

DGMGRL> DISABLE FAST_START FAILOVER;

 

Stop observer:

==============

dgmgrl sys/sys@test_s

DGMGRL> stop observer;

 

FSFO in Oracle Data Guard Broker

 

FSFO in Oracle Data Guard Broker

📌 What is FSFO?

FSFO = Fast-Start Failover

It is a feature that allows automatic failover from Primary to Standby without DBA intervention when the primary database crashes.

---

🔑 Key Benefits of FSFO

1. Automatic Failover
• Standby becomes Primary automatically if Primary fails
• No DBA intervention required
2. Minimizes Downtime
• Critical for production systems
• Failover happens within seconds
3. Improves High Availability
• Ensures continuous database access
• Reduces business impact during outages
4. Safe Role Transition
• Only triggers failover when Broker detects confirmed failure
• Avoids human error
5. Reintegration of Old Primary(reinstate)
• Old Primary can be automatically reinstated as standby if Flashback Database is enabled

EX: reinstate to SCN when Standby_Became_primary and we used to run :

flashback database to SCN 121212; but here every thing will be taken care by FSFO

🎯 Simple Explanation :

Normally:

• If Primary fails → DBA must manually run failover.

With FSFO enabled:

• If Primary fails → Broker automatically promotes Standby to Primary.

No manual command needed.

FSFO:

• Continuously monitors the Primary database

• Uses a separate process called the Observer

• Automatically triggers failover if conditions are met

• Minimizes downtime

• Can provide zero or near-zero data loss (depending on protection mode)

---

🔑 Key Components

1. Primary database

2. Standby database

3. Observer process (runs on separate server)

---

✅ In One Line

FSFO is automatic failover in Data Guard Broker that switches to standby immediately when primary fails.

Downside of FSFO (Fast-Start Failover) in Data Guard Broker:

• Observer must run on separate server
• If Observer stops → FSFO does not work
• Extra monitoring responsibility for DBA

• May trigger failover on temporary glitches → risk of unnecessary role change

• Requires Observer process running on separate server

• Possible data loss if using ASYNC redo transport

• Needs Flashback Database enabled to easily reinstate old primary

• Adds configuration complexity

In short: FSFO improves availability but can increase risk and complexity if not properly configured.

====>>>>>In real time it is not advisable to use observer (FSFO)  <<<<<<<=========

but in case your Client want to have install it on separate server so not to hit the database performance.

Oracle Data Guard Broker Failover

 

Perform smooth  failover with Data Guard Broker.

Data Guard Broker Failover

A failover is when you have lost primary database. It’s very simple to perform failover using data guard broker.

Crash Primary Database (Simulate)

Let us simulate failure. We will kill the PMON process at OS level on primary

On primary:

===========

ps -ef|grep pmon

 

oracle   16914     1  0 14:03 ?        00:00:00 ora_pmon_test

oracle   17722 15893  0 15:08 pts/0    00:00:00 grep pmon

 

kill -9 16914 

Failover to Standby

Connect to standby database test_s (as primary crashed or not available) and failover to standby test_s

On standby:

===========

dgmgrl sys/sys@test_s

 

DGMGRL> show configuration;

DGMGRL> FAILOVER TO test_s;

Performing failover NOW, please wait...

Failover succeeded, new primary is "test_s"

 

DGMGRL> show configuration;

Rebuild Primary After Failover

Post failover, there are two methods of rebuilding your failed primary

• Method 1: Rebuild from scratch –> RMAN duplicate
• Method 2: Flashback database –> only if Flashback was enabled

Reinstate failed primary: When you use data guard broker, with just one command, the primary can be rebuilt. Start the failed primary server, in this case start test server

on Crush Server

===========

Su - oracle

lsnrctl start listener

sqlplus / as sysdba

startup mount;

On current primary (test_s):

===============================

dgmgrl sys/sys@test_s

 

DGMGRL> show configuration;

DGMGRL> reinstate database test;   ------>>>>After a failover, the old primary database (TEST) is marked as failed.

The reinstate command automatically:

• Flashbacks the old primary
• Converts it into a standby
• Rejoins it to the Data Guard configuration

👉 In simple words:
It brings the old primary back as a standby after failover.

Continuing to reinstate database "test" ...

Reinstatement of database "test" succeeded

Verify test post reinstate: The best part is broker will automatically recover earlier failed primary test, mount the database and start MRP too

On failed primary (test):

===========================

select name,open_mode from v$database;

select process, status, sequence# from v$managed_standby;

Switchover to get original configuration: At this stage, you can perform switchover to again get back original configuration

On current primary (test_s):

===============================

dgmgrl sys/sys@test_s

DGMGRL> switchover to test;