In its traditional, (and free) configuration, Oracle Data Guard operates in an active/passive architecture.  This incredibly well-designed and valuable solution from Oracle which comes included with the Enterprise Edition has as part of its architecture:

• A primary database, which is an active, accessible database system.
• One or more standby databases, which are passive replicas that continuously receive redo data from the primary.

The standby databases receive a continuous changes from redo.  By sending redo data from the primary across the network and applying it to the standby, the two are kept in sync. This is done using the Log Transport Services and Apply Services. Depending on the configuration (SYNC vs. ASYNC), data is sent in real-time or with minimal delay.

Disaster Recovery First, but Not Only

The primary goal of Data Guard is disaster recovery: ensuring you have a transactionally consistent standby ready to take over in the event of failure. This minimizes data loss (RPO) and failover time (RTO).

With the introduction of on-premises and cloud data centers, separated by distance, Data Guard has matured into an HA solution, too. With Fast-Start Failover (FSFO), a standby can be promoted automatically if the primary becomes unreachable. FSFO uses a Data Guard Broker configuration and a witness (observer) to monitor the health of the systems and act immediately upon failure without need of manual intervention.

Failover Options in Oracle Data Guard

Oracle supports multiple types of failover, each suited to different operational needs:

1. Manual Failover – Administrator manually initiates switchover after assessing downtime.
2. Switchover – Planned role reversal between primary and standby, usually for patching or maintenance.
3. Automatic Failover (FSFO) – Enabled via Data Guard Broker and observer, ensures minimal downtime without human action.
4. Reinstate – After the original primary is recovered, it can be re-synced with the new primary to resume protection.

In Oracle 19c, a single primary database in Oracle Data Guard can support up to 30 standby databases.

These standby databases can be a mix of:

• Physical Standbys (most common, using Redo Apply),
• Logical Standbys (using SQL Apply),
• Snapshot Standbys (for read-write testing that can later be converted back to a standby),
• and Far Sync instances (to help with zero data loss over long distances).

You can use Data Guard Broker to manage the configuration more easily, though it currently supports a subset of the total – 9 standby databases managed through the Broker as of 19c  vs. standard Oracle Data Guard.

Active Data Guard: Read-Only Standbys With Real Purpose

One of the biggest advancements has been Active Data Guard, which transforms a passive standby into a read-only replica and makes it usable for:

• Ad hoc queries and reporting
• Backups
• ETL processes

This read-only capability is a game-changer for offloading workloads from the primary and maximizing resource usage.  It allows for some scaling of the database by offering a read-only replica that can be used separately, while a passive can be available for failover and disaster recovery.  If desired, as there is additional cost for Active Data Guard, an active replica can be used for FSFO for faster failover, lending to faster failover times when used for HA.

When using a read-only replica with RMAN or other backup technology, a Data Guard standby eliminates the I/O pressure on the primary and reduces the risk of backup-related slowdowns or disruptions.

Global Resiliency: Far Sync

Depending on requirements written into customer Service Level Agreements (SLA), a secondary replica may be needed.  When dealing with geographically distant standby databases, maintaining real-time sync becomes challenging due to latency, but this is where Far Sync comes in.

Far Sync acts as a lightweight intermediary host/node located close to the primary, which receives redo data synchronously, and then forwards it asynchronously to the remote standby. This ensures zero data loss (SYNC) commitments are met locally, without suffering from long-distance network delays to the distant located replica.

Use Case: If your primary is in North America and your DR site is in Europe or Asia, a Far Sync server in the same region as your primary ensures high-speed SYNC delivery, while the actual standby can afford the longer ASYNC replication from Far Sync.

Data Guard’s Expanding Role

Oracle Data Guard is no longer just a disaster recovery tool, an essential part of Oracle’s Maximum Availability Architecture (MAA).  It’s a foundational piece of a high-availability and performance strategy to meet the requirements of uptime for an Oracle environment. With capabilities ranging from FSFO to Active Data Guard and Far Sync, it supports:

• Business continuity
• Operational resilience
• Workload optimization
• Geographical scalability

Whether you’re protecting a mission-critical single-instance or RAC database with failover or disaster recovery or simply want a way to offload read-only workload, understanding the full spectrum of Data Guard is an important part of the Oracle architectural ecosystem.  If you want to dig into DG deeper, I recommend you follow Ludovico Caldera.   He’s a wonderful friend, but even a better Product Manager on the Data Guard and Flashback product at Oracle!