Oracle Data Guard Overview and Benefits: Basics of Disaster Recovery and High Availability

Oracle Data Guard provides the highest level of availability for Oracle Database. In this article, we will explain the overview of Oracle Data Guard, which is the cornerstone of Disaster Recovery (DR), using illustrations. We will also summarize its benefits and precautions from a practical perspective.

Conclusion: What You Can Achieve with Oracle Data Guard
Background and Fundamentals: Detailed Data Guard Architecture
Streamlining Operations with “Data Guard Broker”
Comparison between Data Guard and Oracle GoldenGate (GG)
1. Comparison Table: DG vs GG
Advantages and Disadvantages of Data Guard
1. Advantages
2. Disadvantages
FAQ
Summary

Conclusion: What You Can Achieve with Oracle Data Guard

By implementing Oracle Data Guard, the following four points can be realized:

Disaster Recovery (DR): Even if the primary site is affected by a disaster, business continuity is maintained by switching to a standby system in a remote location.
Data Protection: Minimizes data loss (can even be reduced to zero) through real-time transfer of REDO data.
Load Balancing: By using Active Data Guard, read-only processing and backups can be executed on the standby side.
Downtime Reduction: Minimizes switchover time by utilizing the standby during migrations and patch applications.

Background and Fundamentals: Detailed Data Guard Architecture

Oracle Data Guard maintains synchronization by transferring and applying changes (REDO) generated in the primary database to the standby. This is supported by three primary services.

1. Redo Transport Services

Responsible for transferring REDO data generated on the primary side to the standby.

LNS (Log Network Server) Process: Reads data from the primary’s log buffer or online REDO logs and sends it to the standby via the network.
Transmission Modes:
- SYNC (Synchronous): Commits after waiting for the write completion on the standby side. Prioritizes zero data loss.
- ASYNC (Asynchronous): Commits without waiting for the write completion. Prioritizes performance.

2. Apply Services

Reflects the REDO data received on the standby side into the database.

RFS (Remote File Server) Process: Receives the REDO arriving from the primary and writes it to the Standby REDO Logs (SRL).
MRP (Managed Recovery Process): In a physical standby, this executes the recovery process to apply the contents of the SRL to the data files.
Real-Time Apply: A mechanism where the MRP starts applying as soon as data is written to the SRL, without waiting for a log switch.

3. Role Management Services

Controls the role transitions (Switchover/Failover) between the primary and standby.

[Detailed Illustration] Data Guard Architecture Configuration

      [ Primary DB ]                         [ Standby DB ]
   +-------------------+                +-------------------+
   |   User Process    |                |  Managed Recovery |
   |        ↓          |                |  Process (MRP)    |
   | [Log Buffer]      |                |        ↑          |
   |        ↓          |   Network      | [Standby REDO]    |
   | [LGWR] → [LNS] ---(REDO Transfer)--> [RFS] ----┘       |
   |        ↓          |                |        ↓          |
   | [Online REDO]     |                |  [Data Files]     |
   +-------------------+                +-------------------+

Streamlining Operations with “Data Guard Broker”

Operating Data Guard involves many parameter settings and complex SQL operations. Data Guard Broker integrates, manages, and automates these tasks.

Benefits of Introducing Broker

Simplification of Switchover: A transition that would manually require multi-step SQL processing is completed safely with a single command: SWITCHOVER TO <standby>.
Fast-Start Failover (FSFO): A mandatory component for performing automatic failover within seconds of detecting a failure.
Centralized Management (DGMGRL): Allows monitoring and managing the status of both primary and standby as a single logical configuration.

[Illustration] Management Structure of Data Guard Broker

          [ Administrator / DGMGRL ]
                 |
        (1) Configuration change, Monitoring, Switchover instructions
                 v
       +-----------------------+              +-----------------------+
       |     Primary Node      |   (3) Comm   |     Standby Node      |
       |  +-----------------+  |<------------>|  +-----------------+  |
       |  |  DMON Process   |  |              |  |  DMON Process   |  |
       |  +-------+---------+  |              |  +-------+---------+  |
       |          |            |              |          |            |
       |  (2) Instance Control |              |  (2) Instance Control |
       |          v            |              |          v            |
       |   [ Database ]        |              |   [ Database ]        |
       +-----------------------+              +-----------------------+

 (1) The administrator issues monitoring or switchover instructions through DGMGRL.
 (2) The DMON process on each node controls local DB configuration changes and startup/shutdown.
 (3) DMONs on both sites communicate with each other to synchronize configuration information and perform health checks.

Supplement based on Primary Information

In Oracle official documentation, the use of Broker is “Highly Recommended” as a best practice to prevent operational errors caused by configuration complexity.

Comparison between Data Guard and Oracle GoldenGate (GG)

We summarize the differences from Oracle GoldenGate (GG), which is often compared in the context of disaster recovery and data integration.

Comparison Table: DG vs GG

Comparison Item	Oracle Data Guard (DG)	Oracle GoldenGate (GG)
Replication Unit	Entire Database (Physical Level)	Table / Schema Unit (Logical Level)
Synchronization Direction	Unidirectional (1 to N)	Unidirectional / Bidirectional (Active-Active)
Main Use Cases	Disaster Recovery (DR) / High Availability (HA)	Data Migration / Aggregation / Real-time Integration
License	Included in Enterprise Edition	Requires separate purchase

Advantages and Disadvantages of Data Guard

Here we organize the benefits of implementing Data Guard.

Advantages

High Data Protection Level: Resilient against site failures and data corruption.
Load Balancing: Standby can be utilized as read-only using Active Data Guard.
Downtime Reduction: Can be utilized for rolling upgrades, etc.

Disadvantages

Cost: Requires a standby environment with the same specs and an Enterprise Edition (EE) license.
Network Dependency: Network bandwidth and latency directly impact synchronization performance.

FAQ

Q: Can Data Guard be used with Standard Edition (SE2)? A: No. Data Guard is a feature limited to Enterprise Edition (EE).

Q: Is it okay to build without using Broker? A: It is technically possible (supported). However, manual operation is complex and prone to human error, and automatic failover cannot be used. Therefore, Oracle strongly recommends using the Broker.

Q: If I have GoldenGate, is Data Guard unnecessary? A: The use cases are different. If you need a complete DB-level substitute (DR measure), Data Guard is the most robust and simplest to operate.

Summary

Data Guard is Oracle’s standard DR solution utilizing REDO transfer.
Broker is a “Highly Recommended” management framework to enhance availability.
Choose between Data Guard for physical replication (DG) or GoldenGate for logical data integration (GG).

[reference]
Scenarios for Using DGMGRL with a DG PDB Configuration (26ai)

This article explains targeting Oracle Database 19c / 23ai / 26ai.