Oracle 26ai Data Guard & Data Guard Broker

A Complete Step-by-Step Implementation Guide — RAC Primary to Standalone Physical Standby on ASM

Oracle Data Guard remains Oracle's flagship enterprise solution for High Availability (HA) and Disaster Recovery (DR). This guide walks through a real, end-to-end Oracle 26ai implementation that connects a 2-node RAC primary running on ASM to a standalone physical standby — including parameter setup, RMAN duplication, Data Guard Broker configuration, and a successful switchover. It also highlights what is genuinely new in 26ai Data Guard.

1. Introduction — Why Data Guard Still Matters

Oracle Data Guard is Oracle's enterprise-level disaster recovery and high availability solution. It provides real-time data protection, automated failover and switchover capabilities, and efficient redo replication between primary and standby databases. In modern enterprise environments where business continuity is non-negotiable, deploying Data Guard between a highly available 2-Node RAC primary and a standalone physical standby delivers:

High Availability (HA) at the primary site through RAC.
Disaster Recovery (DR) at a remote standby site.
Zero or minimal data loss through synchronous or near-synchronous redo transport.
Automatic log transport and apply with no manual intervention.
Seamless role transitions via Data Guard Broker.

This guide walks through a complete implementation of Oracle Data Guard and Data Guard Broker between a 2-node RAC Primary CDB on ASM and a standalone Physical Standby CDB on ASM, including environment details, prerequisites, configuration, RMAN duplicate, redo apply, verification, and broker setup.

2. Architecture Overview

2.1 High-Level Topology

2.2 Primary (RAC) Configuration

Component	Detail
Nodes	`node1`, `node2`
Cluster	Oracle Grid Infrastructure
Database	Container Database (CDB): `prod`
Instances	`prod1`, `prod2`
PDB	`prods`
DB Unique Name	`PROD`
Storage	ASM (`+DATA`, `+RECO`, `+OCRVD`)
Role	Primary
Version	Oracle 26ai
SCAN	`rac-scan.localdomain`

2.3 Standby (Standalone) Configuration

Component	Detail
Server	`standby.localdomain`
Database	Container Database (CDB): `prod`
PDB	`prods`
Instance	`prod`
DB Unique Name	`PRODSTBY`
Storage	ASM (`+DATA`, `+RECO`)
Role	Physical Standby
Version	Oracle 26ai

3. Objectives of This Implementation

Configure a Physical Standby Database for a 2-Node RAC primary.
Enable real-time redo transport and real-time apply.
Ensure ongoing Data Guard health and synchronization.
Implement Data Guard Broker for simplified, centralized management.
Test and document Switchover and Failover readiness.
Ensure PDB-level replication is preserved within the CDB environment.

4. Prerequisites & Readiness Checklist

4.1 Database & OS Requirements

Identical Oracle version (26ai) on both primary and standby servers.
ASM disk groups are available on both sides.
Network connectivity is open and stable, with TCP port 1521 reachable in both directions.

4.2 Configuration Requirements

Primary in ARCHIVELOG and FORCE LOGGING mode.
Oracle password file copied from primary to standby.
tnsnames.ora and listener.ora configured correctly on all nodes.
Data Guard related initialization parameters set on the primary.
Standby Redo Logs (SRLs) added on the primary (to support the future role swap).

Tip: The number of SRLs per thread should be online redo log groups + 1, and each SRL must match the size of the largest online redo log. The example below uses 3 SRLs per thread for a 2-thread RAC.

5. Primary Database Configuration

5.1 Confirm ARCHIVELOG Mode

SQL> ARCHIVE LOG LIST;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     ...
Next log sequence to archive   ...
Current log sequence           ...

If the database is in NOARCHIVELOG mode, switch it before continuing:

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;

5.2 Verify FORCE LOGGING is Enabled

SQL> SELECT FORCE_LOGGING FROM V$DATABASE;

FORCE_LOGGING
---------------------------------------
YES

If FORCE_LOGGING is NO, enable it so that NOLOGGING operations cannot create gaps on the standby:

SQL> ALTER DATABASE FORCE LOGGING;

6. Initialization Parameters & Standby Redo Logs

6.1 Primary Database Initialization Parameters

Configure Data Guard parameters on the primary so that redo can be transported to the standby and the configuration will work cleanly after a role transition.

ALTER SYSTEM SET DB_UNIQUE_NAME=PROD SCOPE=SPFILE;

ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(PROD,PRODSTBY)';

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1=
  'LOCATION=USE_DB_RECOVERY_FILE_DEST
   VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
   DB_UNIQUE_NAME=PROD';

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=
  'SERVICE=PRODSTBY
   ASYNC NOAFFIRM
   VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
   DB_UNIQUE_NAME=PRODSTBY';

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_1=ENABLE;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;

ALTER SYSTEM SET FAL_SERVER=PRODSTBY;
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
-- On the primary, the convert pair maps standby paths to primary paths
-- so the rule kicks in after a role swap.
ALTER SYSTEM SET DB_FILE_NAME_CONVERT='+DATA/PRODSTBY/','+DATA/PROD/' SCOPE=SPFILE;
ALTER SYSTEM SET LOG_FILE_NAME_CONVERT='+DATA/PRODSTBY/','+DATA/PROD/' SCOPE=SPFILE;
-- (On the standby PFILE, the pair is reversed: '+DATA/PROD/','+DATA/PRODSTBY/'.)

Note: Once Data Guard Broker takes over (Section 12), you must remove the manual LOG_ARCHIVE_DEST_2 "SERVICE=" route. Broker creates and owns that destination automatically. Leaving the manual entry in place causes ORA-16698.

6.2 Standby Redo Logs (SRL)

For a 2-thread RAC, you need SRLs for both threads. The example uses three groups per thread:

-- Thread 1 (groups 5, 6, 7)
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 5 ('+DATA') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 6 ('+DATA') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 7 ('+DATA') SIZE 200M;

-- Thread 2 (groups 8, 9, 10)
ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 8 ('+DATA') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 9 ('+DATA') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 10 ('+DATA') SIZE 200M;

Verify after creation:

SQL> SELECT GROUP#, THREAD#, BYTES/1024/1024 MB, STATUS
     FROM   V$STANDBY_LOG
     ORDER BY THREAD#, GROUP#;

7. Network Configuration

7.1 `/etc/hosts` on All Servers

Each node should resolve all participating hosts: public IPs, VIPs, SCAN IPs, and the standby IP.

# Public
192.168.10.11   node1.localdomain   node1
192.168.10.12   node2.localdomain   node2
192.168.20.50   standby.localdomain standby

# Virtual IPs
192.168.10.21   node1-vip.localdomain  node1-vip
192.168.10.22   node2-vip.localdomain  node2-vip

# SCAN
192.168.10.30   rac-scan.localdomain   rac-scan
192.168.10.31   rac-scan.localdomain   rac-scan
192.168.10.32   rac-scan.localdomain   rac-scan

7.2 `tnsnames.ora`

Both sides need TNS aliases that allow the primary to reach the standby (for redo transport) and the standby to reach the primary (for fetching gaps via FAL_SERVER).

PROD =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan.localdomain)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = prod)
      (UR = A)))

PRODSTBY =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = standby.localdomain)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = prodstby)
      (UR = A)))

7.3 `listener.ora`

The standby listener needs a static service registration so RMAN duplicate can connect even when the database is in NOMOUNT state.

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = PRODSTBY)
      (ORACLE_HOME = /u01/app/oracle/product/26ai/dbhome_1)
      (SID_NAME = prod)))

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = standby.localdomain)(PORT = 1521))))

7.4 Connectivity Sanity Checks

# From every node and the standby:
tnsping PROD
tnsping PRODSTBY

# Verify SYS connectivity over TNS:
sqlplus sys/<pwd>@PROD as sysdba
sqlplus sys/<pwd>@PRODSTBY as sysdba

All four directions must succeed before continuing.

8. Password File & PFILE Setup

8.1 Copy the Password File from ASM

In a RAC + ASM environment the password file lives in ASM. Copy it from ASM to the standby's $ORACLE_HOME/dbs so the standby authenticates with the same SYS credentials as the primary.

# On primary (one of the RAC nodes):
asmcmd
ASMCMD> pwget --dbuniquename PROD
+DATA/PROD/PASSWORD/pwdprod.<n>.<m>
ASMCMD> pwcopy +DATA/PROD/PASSWORD/pwdprod.<n>.<m> \
              /tmp/orapwprod
ASMCMD> exit

# Transfer to standby:
scp /tmp/orapwprod oracle@standby:/u01/app/oracle/product/26ai/dbhome_1/dbs/orapwprod

8.2 Create a Standby PFILE

# On primary:
SQL> CREATE PFILE='/tmp/initprodstby.ora' FROM SPFILE;

# Edit the PFILE so DB_UNIQUE_NAME, control_files, and *_CONVERT
# match the standby paths, e.g.:
*.db_name=prod
*.db_unique_name=PRODSTBY
*.control_files='+DATA/PRODSTBY/CONTROLFILE/control01.ctl'
*.fal_server=PROD
*.log_archive_config='DG_CONFIG=(PROD,PRODSTBY)'
*.db_file_name_convert='+DATA/PROD/','+DATA/PRODSTBY/'
*.log_file_name_convert='+DATA/PROD/','+DATA/PRODSTBY/'

# Copy to standby:
scp /tmp/initprodstby.ora oracle@standby:/u01/app/oracle/product/26ai/dbhome_1/dbs/initprod.ora

9. Creating the Standby Database

9.1 Start the Standby in NOMOUNT

# On standby:
export ORACLE_SID=prod
sqlplus / as sysdba
SQL> STARTUP NOMOUNT PFILE='/u01/app/oracle/product/26ai/dbhome_1/dbs/initprod.ora';
SQL> CREATE SPFILE='+DATA' FROM PFILE;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP NOMOUNT;

9.2 RMAN Duplicate `FROM ACTIVE DATABASE`

Connect RMAN simultaneously to the primary (target) and the auxiliary instance (standby in NOMOUNT) and run a single DUPLICATE. RMAN will:

Create the standby controlfile
Restore datafiles using OMF on ASM
Recover the database
Mount the standby

# On standby:
rman TARGET sys/<pwd>@PROD AUXILIARY sys/<pwd>@PRODSTBY

RMAN> DUPLICATE TARGET DATABASE
       FOR STANDBY
       FROM ACTIVE DATABASE
       DORECOVER
       SPFILE
         SET DB_UNIQUE_NAME='PRODSTBY'
         SET CONTROL_FILES='+DATA/PRODSTBY/CONTROLFILE/control01.ctl'
         SET FAL_SERVER='PROD'
         SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(PROD,PRODSTBY)'
         SET DB_FILE_NAME_CONVERT='+DATA/PROD/','+DATA/PRODSTBY/'
         SET LOG_FILE_NAME_CONVERT='+DATA/PROD/','+DATA/PRODSTBY/'
       NOFILENAMECHECK;

When RMAN finishes, the standby is in MOUNT state with restored datafiles and a standby controlfile, and PDBs replicated from the primary CDB.

10. Start Redo Apply

Enable real-time apply on the standby so redo received from the primary is applied as soon as it arrives:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
        DISCONNECT FROM SESSION
        USING CURRENT LOGFILE;

To stop redo apply (for example, before configuring Broker):

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

11. Verification & Real-Time Apply Test

11.1 On the Primary (RAC)

SQL> SELECT NAME, DB_UNIQUE_NAME, DATABASE_ROLE, OPEN_MODE
     FROM   V$DATABASE;

SQL> SELECT THREAD#, MAX(SEQUENCE#)
     FROM   V$ARCHIVED_LOG
     WHERE  RESETLOGS_CHANGE# = (SELECT RESETLOGS_CHANGE# FROM V$DATABASE)
     GROUP BY THREAD#;

11.2 On the Standby (Standalone)

SQL> SELECT NAME, DB_UNIQUE_NAME, DATABASE_ROLE, OPEN_MODE
     FROM   V$DATABASE;

SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#
     FROM   V$MANAGED_STANDBY
     WHERE  PROCESS IN ('MRP0','RFS','LNS','ARCH');

11.3 Check Apply and Transport Lag

SQL> SELECT NAME, VALUE, TIME_COMPUTED
     FROM   V$DATAGUARD_STATS
     WHERE  NAME IN ('apply lag','transport lag');

Both lag values should be near zero on a healthy configuration.

11.4 Real-Time Log Apply Test (Manual Log Switch)

To prove that redo is flowing and being applied in real time, force a log switch on the primary, then watch the sequence advance on the standby and the MRP apply it immediately.

-- Primary
SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> SELECT THREAD#, MAX(SEQUENCE#) FROM V$ARCHIVED_LOG GROUP BY THREAD#;

-- Standby (run a few seconds later)
SQL> SELECT THREAD#, SEQUENCE#, APPLIED
     FROM   V$ARCHIVED_LOG
     WHERE  SEQUENCE# >= (SELECT MAX(SEQUENCE#)-2 FROM V$ARCHIVED_LOG)
     ORDER  BY THREAD#, SEQUENCE#;

The newly archived sequence should appear on the standby with APPLIED = YES within seconds.

12. Data Guard Broker Configuration

12.1 Enable Broker on Both Databases

-- On primary AND standby:
SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE SCOPE=BOTH;

12.2 Stop MRP Before Broker Takes Control

Before configuring Data Guard Broker, stop the Managed Recovery Process (MRP) on the standby. While MRP is active it can interfere with Broker operations such as enabling the configuration, adding the standby database, performing switchover or failover, and reading database state. Broker manages redo apply itself, so it must take full control.

-- Standby:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

12.3 Remove Manual Redo Routes

Important: When using Broker, manual redo routes (SERVICE=... in LOG_ARCHIVE_DEST_2) must be removed. Broker will automatically create LOG_ARCHIVE_DEST_2 on the primary toward the standby, and on the standby back to the primary. This is what allows automatic failover, switchover, health checks, and automatic redo routing after role transitions. If a manual SERVICE= destination remains, Broker will refuse to take control and you will hit ORA-16698.

-- On primary:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='' SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2='RESET' SCOPE=BOTH;

-- On standby (if a back-route was set manually):
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='' SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2='RESET' SCOPE=BOTH;

12.4 Create the Data Guard Configuration

$ dgmgrl sys/<pwd>@PROD

DGMGRL> CREATE CONFIGURATION 'PROD_DG'
        AS PRIMARY DATABASE IS 'PROD'
        CONNECT IDENTIFIER IS PROD;

DGMGRL> ADD DATABASE 'PRODSTBY'
        AS CONNECT IDENTIFIER IS PRODSTBY
        MAINTAINED AS PHYSICAL;

DGMGRL> ENABLE CONFIGURATION;

DGMGRL> SHOW CONFIGURATION;

12.5 Verify Broker Health

DGMGRL> SHOW CONFIGURATION;

Configuration - PROD_DG

  Protection Mode: MaxPerformance
  Members:
  PROD     - Primary database
    PRODSTBY - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated <n> second(s) ago)

DGMGRL> SHOW DATABASE 'PROD';
DGMGRL> SHOW DATABASE 'PRODSTBY';

Both databases should report Transport Lag: 0 and Apply Lag: 0.

13. Switchover Operation in Data Guard Broker

A Switchover is a planned, fully reversible role reversal between primary and standby, performed while both databases are healthy. Used for:

Maintenance activities on the primary site.
Testing the disaster recovery (DR) site.
Validating Data Guard configuration and runbooks.
Planned failover simulations.

During a switchover:

The primary becomes a standby.
The standby becomes the new primary.
Redo transport and apply automatically reverse direction.
Data Guard Broker handles all internal steps.

Switchover is safe, fast, and zero-data-loss as long as both databases are synchronized.

13.1 Prerequisites Before Switchover

Data Guard Broker configuration status must be SUCCESS.
Both databases must show no apply or transport lag.
The standby host must be able to reach all primary nodes (and vice versa).
No long-running maintenance jobs on either side.

13.2 Execute the Switchover Using DGMGRL

# Step 1 — Login to DGMGRL on the primary or standby:
$ dgmgrl sys/<pwd>@PROD

# Step 2 — Validate before switching:
DGMGRL> VALIDATE DATABASE 'PRODSTBY';

# Step 3 — Perform the switchover:
DGMGRL> SWITCHOVER TO 'PRODSTBY';

During the switchover, Broker stops redo apply, converts the standby to primary, converts the original primary to a standby, and starts redo apply on the new standby.

13.3 Post-Switchover Verification

DGMGRL> SHOW CONFIGURATION;

# On new primary (PRODSTBY):
SQL> SELECT NAME, DB_UNIQUE_NAME, DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;

# On new standby (PROD):
SQL> SELECT NAME, DB_UNIQUE_NAME, DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;

The Data Guard Broker configuration PROD_DG should show STATUS = SUCCESS, confirming both databases are healthy, synchronized, and communicating. The configuration is operating in Maximum Performance mode, with no transport or apply issues — validating that the switchover was successful and the Data Guard environment is functioning normally.

13.4 Benefits of Performing a Switchover

Zero data loss (safe, planned operation).
Validates HA/DR readiness end to end.
Confirms Data Guard health.
Used for patching or rolling maintenance with minimal impact.
Ensures both sites are operational and synchronized.

14. Final Status Summary

Item	Status
Primary DB	`PROD` (RAC), OPEN
Standby DB	`PRODSTBY` (Standalone), APPLYING LOGS
Data Guard	ACTIVE, SYNCHRONIZED
Log Transport	WORKING
Broker	ENABLED & HEALTHY
PDBs	Successfully replicated

15. What's New in Oracle 26ai Data Guard

Oracle Database 26ai introduces several enhancements that improve Data Guard manageability, automation, and resilience. Key highlights:

Area	Enhancement in 26ai	Why it matters
Broker Automation	Faster configuration and better integration with dynamic environments, with reduced manual tuning.	Less hand-edited `LOG_ARCHIVE_DEST_n`; quicker bring-up of new standbys.
Role Transition Stability	Switchover and failover operations are more consistent with reduced downtime.	Tighter RTO during planned maintenance and DR drills.
Monitoring & Observability	Improved diagnostic visibility for redo transport, apply lag, and health validation.	Faster root-cause analysis when lag spikes or transport stalls.
Redo Transport Performance	More efficient network handling for high-throughput environments.	Better behavior on busy OLTP primaries and long-distance DR links.
Cloud-Ready Integration	Designed for hybrid deployments across on-premises and cloud platforms.	Cleaner path for OCI / hybrid DR topologies.

These improvements make Data Guard in 26ai more stable, intelligent, and easier to manage compared to earlier versions.

16. Why Use Data Guard Broker

Using Data Guard without Broker is possible, but Broker brings significant operational advantages:

Centralized configuration management — one configuration object, one source of truth.
Simplified switchover and failover — single SWITCHOVER / FAILOVER command.
Automatic health monitoring — Broker continuously evaluates transport, apply, and role state.
Easier automation and scripting — DGMGRL is friendlier to runbooks than raw SQL*Plus steps.
Reduced human error during DR events — fewer hand-edited parameters during a stressful incident.

In Oracle 26ai, Broker is more mature and recommended for all production setups.

17. Common Pitfalls & Troubleshooting (Bonus)

This section is editorial commentary based on the steps above and is intended as practical context — not a reproduction of the source PDF.

Symptom	Likely Cause	Where to Check
`ORA-16698` when enabling Broker	Manual `LOG_ARCHIVE_DEST_2 'SERVICE=...'` still set; Broker can't take control.	Section 12.3 — clear the manual destination and reset its state.
Standby not advancing sequence	MRP not started, or `FAL_SERVER` wrong; SRLs missing or undersized.	Section 6.2 (SRLs), Section 10 (MRP), `V$MANAGED_STANDBY`.
RMAN `DUPLICATE` can't connect to auxiliary	Standby not started in NOMOUNT, or no static service in `listener.ora`.	Section 7.3 (static listener), Section 9.1 (NOMOUNT).
Apply lag grows during peak load	Network bandwidth saturation or insufficient SRLs.	`V$DATAGUARD_STATS`, `V$STANDBY_LOG`, redo throughput on the link.
Switchover fails midway	Pre-switch validation skipped; lag > 0 or sessions blocking.	`VALIDATE DATABASE` in DGMGRL before switching.

18. Conclusion

This implementation successfully establishes a robust disaster recovery environment using Oracle Data Guard between a highly available 2-node RAC primary and a standalone ASM-based physical standby. With Data Guard Broker, database role transitions become easier, faster, and automated — ensuring maximum uptime and simplified administration.

The setup aligns with best practices for:

High Availability (HA)
Disaster Recovery (DR)
Minimal downtime architecture
Enterprise-level data protection

In Oracle 26ai, the combination of a well-configured Data Guard topology and a healthy Broker configuration gives DBAs a manageable, observable, and predictable DR posture — exactly what enterprise SLAs demand.