Wednesday, March 4, 2026

Logical Standby in Oracle Data Guard Overview

 

In Oracle Data Guard, a Logical Standby Database is a standby database that:

  • Receives redo data from the Primary database

  • Converts redo into SQL statements

  • Replays those SQL statements on the standby

  • Can be OPEN READ WRITE while applying changes

This is different from Physical Standby.


🔹 1️⃣ What is Logical Standby?

A Logical Standby:

  • Uses SQL Apply

  • Redo is transformed into SQL statements

  • Allows users to:

    • Query data

    • Create indexes

    • Create additional tables

    • Run reports

  • Can be open in READ WRITE mode

It must have the same logical structure as primary (tables, schemas), but physical storage can differ.


🔹 2️⃣ How It Works (Step-by-Step)

On Primary Database

  1. User commits transaction

  2. Redo generated

  3. Redo shipped to standby

On Logical Standby

  1. Redo received

  2. LogMiner converts redo → SQL

  3. SQL Apply executes SQL statements


🔹 3️⃣ Architecture Diagram

Here is a simple visual diagram for understanding:

PRIMARY DATABASE
----------------
| User DML |
| INSERT/UPD |
----------------
|
| Redo Transport
v
=========================
| Logical Standby |
|------------------------|
| Redo Received |
| LogMiner |
| SQL Apply |
| Open READ WRITE |
=========================

🔹 4️⃣ Logical vs Physical Standby

FeaturePhysical StandbyLogical Standby
Apply MethodRedo ApplySQL Apply
Database Open ModeRead OnlyRead Write
Block Level CopyYesNo
Can create new indexes?NoYes
Good for reporting?LimitedExcellent

🔹 5️⃣ Important Background Processes

Logical standby uses:

  • LSP (Logical Standby Process)

  • LogMiner

  • SQL Apply Engine

Unlike physical standby which uses MRP (Managed Recovery Process).


🔹 6️⃣ Advantages

✅ Reporting without impacting primary
✅ Can create extra indexes
✅ Can skip certain tables
✅ Good for data warehouse reporting


🔹 7️⃣ Limitations

❌ Some data types not supported
❌ Not all DDL supported
❌ Slightly slower apply than physical
❌ More complex


🔹 8️⃣ When to Use Logical Standby?

Use when:

  • You need reporting with write capability

  • You want different indexes

  • You need to replicate subset of objects

🔹 9️⃣ Simple Real DBA Example

Primary:

INSERT INTO employees VALUES (101,'John');

Redo shipped.

Logical standby converts redo into:

INSERT INTO employees VALUES (101,'John');

SQL Apply executes it.


Monday, February 23, 2026

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;

 



Logical Standby in Oracle Data Guard Overview

  In Oracle Data Guard , a Logical Standby Database is a standby database that: Receives redo data from the Primary database Convert...