Introduction

For organizations with mission-critical Oracle databases, database availability and disaster recovery are not optional. Database outages can affect applications, business operations, customer access, and revenue.

Oracle Data Guard lets you maintain one or more standby databases for high availability and disaster recovery. In a physical standby configuration, redo generated by the primary database is shipped to the standby and is continuously applied using Redo Apply to keep the standby database in sync with the primary.

But setting up an Oracle Data Guard environment is only half the battle.

To be production-ready, a setup must also answer some key questions:

• Is redo being generated correctly?
• Is redo reaching the standby?
• Is the standby really applying the redo?
• Does it have an archive log gap?
• Does the standby experience transport/apply lag?
• Are we executing the Managed Recovery Process (MRP)?
• How to validate synchronization?

In this guide, we will walk you through the basic steps to configure an Oracle Database 19c physical standby database. We will discuss configuring the primary database, network configuration, RMAN duplication, Redo Apply and synchronization checks

Note: Commands in this guide are only examples. Paths, database names, hostnames, Oracle Homes, storage configuration and other environment specific values need to be adapted to the target environment.

1.  Oracle Data Guard 19c Physical Standby: Step-by-Step Configuration What We Are Building?

The environment is, at a high level:

Primary Database → Redo Transport → Standby Database → Redo Apply

When transactions modify the database, the primary database generates redo.

Oracle Data Guard transports the redo to the standby database, and applies it to keep a synchronized copy of the primary.

A Physical Standby is a block-for-block copy of the primary database and is maintained by Redo Apply.

The actual architecture may vary if the environment is using Oracle RAC, ASM, Oracle Managed Files, Data Guard Broker, Active Data Guard or other components.

This article talks about a physical standby setup for Oracle Database 19c.

2.  Oracle Data Guard 19c prerequisites

Before starting the configuration, verify that the primary and standby environments satisfy the prerequisites listed.

The provided configuration file shows Oracle 19c and different DB_UNIQUE_NAME values for the databases.

A simple environment could look like this:3. Enable ARCHIVELOG Mode on the Primary

3.  Put the primary in ARCHIVELOG mode.

What is ARCHIVELOG mode?

In ARCHIVELOG mode, you can archive the online redo logs and reuse the logs.

This archived redo is the basis for database recovery and Data Guard redo transport.

First, check the mode:

‍4.  Force Logging enable

What is LOGGING FORCING?

FORCE LOGGING forces database changes to be written to redo, even if the operations try to use NOLOGGING.

This is important because Data Guard uses redo to replay the changes on the standby.

5.  Turn on Flashback Database

You can use the Flashback Database to move the database forward or backward in time without restoring the whole database from a backup.

Flashback can help you recover from human errors and from certain Data Guard role-transition and resynchronization scenarios.

6.  Configure Standby Redo Log Files

Standby redo logs or SRLs are an important aspect of a Data Guard configuration. They are redone from the primary and support real-time redo application. In a real environment, do not copy the example size. The SRL configuration should be planned according to the online redo log configuration of the primary, the number of redo threads, and the intended Data Guard configuration.

As a general guideline when sizing and verifying SRLs:

• How many SRLs to create: configure at least one more standby redo log group, per redo thread, than the number of online redo log groups the primary has for that thread. For example, if the primary has 3 online redo log groups on a thread, configure at least 4 standby redo log groups for that thread on the standby.
• What size they should be: each standby redo log file should match the size of the primary's online redo log files exactly. A size mismatch between SRLs and online redo logs can prevent redo transport from working correctly.
• How to verify them: query V$STANDBY_LOG on the standby database to confirm the group count, file size, group status, and whether groups are currently in use.
• How thread count affects SRL configuration: in an Oracle RAC primary with multiple redo threads, standby redo logs must be configured per thread. Even if the standby is a single-instance database, it still needs enough SRL groups provisioned for every thread on the primary, so the environment is ready to support future role transitions and RAC standby configurations.

7.  Set up the TNS and Listener

The primary and standby databases must be connected by a reliable network.

The Oracle Listener is responsible for listening to incoming connections, and the Oracle Net / TNS configuration stores the connection information to be able to reach the databases.

Before you run the RMAN duplication check connectivity with tnsping and the correct administrative database connections.‍

8. Configure Data Guard Initialization Parameters

Several initialization parameters are important when configuring Data Guard.

These include DB_UNIQUE_NAME, LOG_ARCHIVE_CONFIG, LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_DEST_2, FAL_SERVER, STANDBY_FILE_MANAGEMENT and REMOTE_LOGIN_PASSWORDFILE.

The exact LOG_ARCHIVE_DEST_n configuration depends on the environment, protection mode and redo transport requirements.

Do not copy production parameter values from a tutorial without validating them against the target architecture.

9. Configure the Password File

Data Guard requires appropriate authentication for communication between the primary and standby databases.

Depending on the method used to create the standby, the password file may be copied or created as part of the RMAN duplication workflow.

When using RMAN active duplication, RMAN can handle the password file transfer as part of the standby creation process.

10. Prepare the Standby Server

The standby server needs the required Oracle software, directories and database configuration.

Consider ORACLE_BASE, ORACLE_HOME, datafile directories, archive log destinations, Fast Recovery Area, audit directories, diagnostic directories and standby redo log locations.

The directory structure does not always have to be identical. If primary and standby storage paths differ, appropriate Oracle/RMAN storage mapping options should be planned before duplication.

11. Create the Physical Standby Using RMAN

Once the primary and standby environments are prepared, the physical standby database can be created using RMAN.

The supplied configuration document uses:

DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE;

Oracle 19c documents RMAN-based standby creation, including active database duplication.

Active duplication creates the standby using the primary database over the network. Backup-based duplication creates the standby using RMAN backup files.

The appropriate method depends on factors such as network bandwidth, database size, backup availability and operational requirements.

12. Start Managed Recovery on the Standby

After the physical standby has been created, Redo Apply needs to be started.

The Managed Recovery Process, commonly referred to as MRP, applies redo received from the primary to the standby.

First verify the database role and open mode. Then start managed recovery using the appropriate syntax for the configuration.

13. Verify the Managed Recovery Process

Starting MRP is not enough. You need to verify that the standby is actually receiving and applying redo.

Useful process states include CONNECTED, RECEIVING and APPLYING_LOG.

ARCH manages archived redo, RFS receives redo from the primary, and MRP0 applies the received redo to the standby.

14. Verify Redo Transport

A successful Data Guard configuration needs to demonstrate the complete flow:

Redo generated → Redo transported → Redo received → Redo applied

Compare the latest archived redo sequence on the primary with the latest applied sequence on the standby.

If the standby is caught up, the values may match. If the standby sequence is behind, there may be transport or apply lag.

Sequence-number comparison should be treated as a useful validation check rather than the only measure of Data Guard health.

15. How to Check Oracle Data Guard Synchronization

A practical validation process should answer three questions:

1. Is redo being generated?

2. Is redo reaching the standby?

3. Is redo being applied?

For a production environment, also investigate transport lag, apply lag, archive gaps and the status of the redo transport and apply processes.

16. Oracle Data Guard Apply Lag: What Does It Mean?

Apply lag occurs when the standby has received redo but has not yet applied it as quickly as the primary is generating it.

Possible causes include insufficient standby CPU, storage I/O bottlenecks, network latency, high redo generation rate, archive log gaps, MRP or recovery issues, inadequate standby configuration, and contention from other workloads.

A lag problem should not automatically be attributed to the network. The troubleshooting process should identify where the lag is occurring.

17. Common Oracle Data Guard 19c Troubleshooting Scenarios

MRP0 is not running:

Check V$MANAGED_STANDBY, database role, standby state, alert log, recovery errors and missing archive logs.

Standby is behind the primary:

Compare archived and applied sequences, then investigate redo transport, MRP, network connectivity and archive gaps.

TNS connectivity fails:

Check host, port, listener, service name, firewall and TNS configuration.

Missing archive logs:

Investigate archive log sequences, archive destinations, FAL configuration, network connectivity, missing files and recovery process status.

Standby redo logs are not configured correctly:

Check V$STANDBY_LOG and compare SRL configuration with the primary's online redo configuration.

18. Should You Use Oracle Data Guard Broker in Oracle 19c? 

Manual SQL*Plus configuration is useful for understanding how Data Guard works and can be appropriate for certain environments.

For ongoing management, Data Guard Broker is an important consideration.

Broker can simplify configuration management, standby monitoring, switchover, failover, protection mode configuration and role management.

For a production implementation, the decision to use Broker should be made based on the operational requirements and architecture.

19. Production Readiness Checklist

Before considering an Oracle Data Guard 19c physical standby configuration complete, validate the following.

20. Conclusion

Setting up an Oracle Data Guard 19c physical standby is more than executing a sequence of SQL and RMAN commands.

The real objective is to establish a reliable chain:

Primary Database

↓

Redo Generation

↓

Redo Transport

↓

Standby Redo Logs

↓

Redo Apply / MRP

↓

Synchronized Physical Standby

A successful configuration should therefore be validated at every stage.

The initial setup should confirm that the primary is correctly prepared. Network connectivity should be tested before standby creation. RMAN should be used to create the physical standby according to the selected implementation method. MRP should then be verified, and redo transport and apply should be continuously monitored.

Finally, the environment should be tested through operational scenarios such as switchover and failover rather than being considered complete simply because the standby database has been created.

Oracle Data Guard provides the foundation for high availability and disaster recovery, but the reliability of the final environment depends on correct configuration, continuous monitoring and tested recovery procedures.

Not sure whether your current Data Guard setup would actually survive a real failover? Geopits offers a focused Data Guard health check, architecture review, monitoring assessment, or disaster recovery readiness assessment - so gaps are found during a planned review, not during an outage. Reach out to Geopits to schedule an assessment for your environment.

FAQ

What is Oracle Data Guard 19c?
Oracle Data Guard 19c is Oracle's database availability and disaster recovery technology for maintaining standby databases and enabling role transitions between primary and standby databases.

What is a physical standby database in Oracle?
A physical standby database is a block-for-block copy of the primary database that is maintained by continuously applying redo received from the primary.

Why is ARCHIVELOG required for Oracle Data Guard?
The primary database must run in ARCHIVELOG mode so that redo information can be archived and used as part of the Data Guard redo transport and recovery process.

What is MRP in Oracle Data Guard?
MRP, or Managed Recovery Process, applies redo received by the physical standby database so that it remains synchronized with the primary.

How is a physical standby created in Oracle 19c?
One common method is RMAN active database duplication using DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE. Oracle 19c also supports other RMAN-based standby creation approaches.

What is the difference between transport lag and apply lag?
Transport lag is the delay between redo generation on the primary and its arrival on the standby. Apply lag is the delay between arrival and application by MRP. Both are visible in V$DATAGUARD_STATS.

What causes Oracle Data Guard apply lag?
Apply lag can result from standby performance limitations, I/O bottlenecks, high redo generation, network issues, archive gaps or recovery-process problems.

Is a Data Guard Broker necessary?
Not necessarily for every environment, but Data Guard Broker provides an important management and monitoring interface and can simplify operational tasks such as configuration, switchover and failover.

Key Takeaway

Oracle Data Guard 19c configuration is only successful when the standby is not merely created, but continuously receiving, applying and validating redo from the primary.

For DBAs, the most important checks are therefore not just “Did the RMAN duplicate finish?” but:

Is redo moving? Is MRP applying it? Is there a gap? Is the standby lagging? And can the environment actually support a recovery when it matters?

Reference Tables

Example Environment

Key Data Guard Parameters