Oracle 19c Data Guard & Data Guard Broker

A complete, step-by-step implementation guide for a 2-Node RAC Primary and a Standalone Physical Standby (both on ASM)

Real-time redo transport, zero data loss, automated role transitions — Data Guard remains Oracle's gold standard for high availability and disaster recovery. This walkthrough takes a working configuration from prerequisites all the way through Broker-managed switchover, with every command, every parameter, and the reasoning behind each decision.

What this guide covers

Why Data Guard, and what this implementation proves
Reference architecture (RAC primary + standalone standby)
Prerequisites and design decisions
Primary database preparation (archivelog, force logging, init params)
Standby Redo Logs — sizing and thread mapping
Network configuration (hosts, tnsnames, listener)
Password file, PFILE and standby instance bring-up
Cloning the standby with RMAN DUPLICATE … FROM ACTIVE DATABASE
Starting Redo Apply and verifying synchronization
Real-time log apply verification
Configuring Data Guard Broker (and avoiding ORA-16698)
Performing a Broker-managed switchover
Best practices, pitfalls, and where to take this next

1. Introduction: why Data Guard still matters

Oracle Data Guard is Oracle's enterprise-grade disaster recovery and high availability solution. It maintains one or more synchronized copies (standby databases) of a production database, transports redo from the primary in real time, and applies it on the standby — providing protection against site failures, storage corruption, human error, and planned outages.

In modern environments where the cost of downtime is measured in minutes of revenue, a Data Guard pair between a 2-Node RAC primary and a standalone physical standby is one of the most pragmatic patterns available. It combines:

High Availability (HA) at the primary site through RAC.
Disaster Recovery (DR) at the secondary site through the physical standby.
Zero or minimal data loss via SYNC/ASYNC redo transport.
Automatic redo transport and apply, including gap resolution.
Seamless switchover and failover, especially with Data Guard Broker.

This guide documents an end-to-end implementation between a 2-node RAC primary CDB on ASM and a standalone physical standby CDB on ASM, then layers Data Guard Broker on top to simplify ongoing management.

1.1 What you will build by the end

A physical standby database (PRODSTBY) cloned from a live RAC primary (PROD) using RMAN active duplication.
Real-time redo transport & apply with full PDB-level replication inside the CDB.
A Broker configuration (PROD_DG) running in MaxPerformance mode and reporting SUCCESS.
A validated, fully reversible switchover between primary and standby — performed entirely through DGMGRL.

2. Reference architecture

2.1 Primary (RAC) configuration

Component	Details
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 19.16
SCAN	`rac-scan.localdomain`

2.2 Standby (standalone) configuration

Component	Details
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 19.16

2.3 The picture in your head

+----------------------- PRIMARY SITE (RAC) -----------------------+
|                                                                  |
|   node1: prod1  -----+                                           |
|                       \   redo (LOG_ARCHIVE_DEST_2,              |
|   node2: prod2  ------+-->  SERVICE=PRODSTBY ASYNC) ----+        |
|                                                          |       |
|   +DATA  +RECO  +OCRVD  (ASM)                            |       |
+----------------------------------------------------------|-------+
                                                           |
                                                           v
+----------------------- DR SITE (Standalone) ---------------------+
|                                                                  |
|   standby: prod   <-- RFS receives redo, MRP applies it          |
|                                                                  |
|   +DATA  +RECO  (ASM)                                            |
|                                                                  |
|   DB_UNIQUE_NAME = PRODSTBY                                      |
+------------------------------------------------------------------+

Figure 1: Logical layout. Both sides are CDBs on ASM; the standby has half the instance count but maintains all PDB content.

3. Objectives and prerequisites

3.1 Objectives

Configure a physical standby database for a 2-node RAC primary.
Enable real-time redo transport & apply.
Ensure Data Guard health and synchronization.
Implement Data Guard Broker for simplified management.
Test and document switchover and failover readiness.
Ensure PDB-level replication in a CDB environment.

3.2 Database & OS prerequisites

Identical Oracle binaries (19.16) and patch level on both servers.
ASM disk groups (+DATA, +RECO) provisioned on the standby with enough capacity for full datafiles + flashback logs + 1.5× redo retention.
TCP port 1521 reachable both ways between RAC SCAN/VIPs and the standby host.
Equal endianness and patch sets (no cross-platform hops in this design).

3.3 Configuration prerequisites

Primary running in ARCHIVELOG and FORCE LOGGING mode.
Oracle password file copied to standby (must be in EXCLUSIVE mode).
tnsnames.ora and listener.ora entries on both ends.
Data Guard initialization parameters set on the primary.
Standby Redo Logs (SRLs) added on the primary before the duplicate.

Why SRLs go on the primary tooA common mistake is to add SRLs only on the standby. They should also exist on the primary so that when roles reverse during a switchover, the new standby (former primary) is immediately ready to receive redo without an outage to add log groups.

4. Primary database preparation

4.1 Confirm ARCHIVELOG mode

[oracle@node1 ~]$ . oraenv
ORACLE_SID = [prod] ? prod1
[oracle@node1 ~]$ sqlplus / as sysdba

SQL> archive log list;
Database log mode               Archive Mode
Automatic archival              Enabled
Archive destination             USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence      12
Next log sequence to archive    13
Current log sequence            13

4.2 Enable FORCE LOGGING

SQL> select force_logging from v$database;
FORCE_LOGGING
---
NO

SQL> alter database force logging;
Database altered.

SQL> select force_logging from v$database;
FORCE_LOGGING
---
YES

FORCE LOGGING guarantees that even NOLOGGING direct-path operations generate redo, so the standby never silently misses changes. In a Data Guard environment this is non-negotiable.

4.3 Set primary initialization parameters

SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(PROD,PRODSTBY)' SCOPE=BOTH SID='*';
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST
       VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PROD' SCOPE=BOTH SID='*';
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=PRODSTBY ASYNC
       VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PRODSTBY' SCOPE=BOTH SID='*';
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_1=ENABLE SCOPE=BOTH SID='*';
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH SID='*';
SQL> ALTER SYSTEM SET FAL_SERVER='PRODSTBY' SCOPE=BOTH SID='*';
SQL> ALTER SYSTEM SET FAL_CLIENT='PROD' SCOPE=BOTH SID='*';
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO SCOPE=BOTH SID='*';
SQL> ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE SID='*';

What each parameter buys you:

Parameter	Purpose
`LOG_ARCHIVE_CONFIG`	Enumerates DB unique names that may participate in redo transport.
`LOG_ARCHIVE_DEST_1`	Local archival into the FRA, valid in any role.
`LOG_ARCHIVE_DEST_2`	Remote shipping to standby. `ASYNC` = MaxPerformance; switch to `SYNC AFFIRM` for MaxAvailability.
`FAL_SERVER` / `FAL_CLIENT`	Used by FAL (Fetch Archive Log) to resolve gaps automatically.
`STANDBY_FILE_MANAGEMENT=AUTO`	New datafiles on the primary auto-create on the standby.
`REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE`	Required so the standby can authenticate redo transport with SYS.

Verify with show parameter log_archive — both destinations should be enable with their full VALID_FOR clauses present.

5. Standby Redo Logs (SRLs)

SRL sizing rule of thumb: same size as the largest online redo log, and (threads × online groups) + 1 per thread. With two RAC threads of 200 MB online redo, we add three SRLs per thread (groups 5–7 for thread 1, groups 8–10 for thread 2):

SQL> alter database add standby logfile THREAD 1 group 5  ('+DATA','+RECO') size 200m;
SQL> alter database add standby logfile THREAD 1 group 6  ('+DATA','+RECO') size 200m;
SQL> alter database add standby logfile THREAD 1 group 7  ('+DATA','+RECO') size 200m;
SQL> alter database add standby logfile THREAD 2 group 8  ('+DATA','+RECO') size 200m;
SQL> alter database add standby logfile THREAD 2 group 9  ('+DATA','+RECO') size 200m;
SQL> alter database add standby logfile THREAD 2 group 10 ('+DATA','+RECO') size 200m;

Confirm both online and standby groups are visible:

SQL> select GROUP#, THREAD#, BYTES/1024/1024 from v$standby_log;
GROUP#  THREAD#  BYTES/1024/1024
------  -------  ---------------
   5      1          200
   6      1          200
   7      1          200
   8      2          200
   9      2          200
  10      2          200

6. Network configuration

6.1 `/etc/hosts` on every host

Every node — both RAC nodes and the standby — needs a consistent host map covering public IPs, RAC VIPs, SCAN, and the standby IP. Without this, redo transport works "sometimes" and switchover ends in tears.

6.2 `tnsnames.ora`

Define separate entries for each instance, the RAC service, and the standby:

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

PRODPRMY =                          # used by RMAN as the active source
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = node1.localdomain)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = node2.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)))

Why (UR = A) mattersDuring RMAN active duplication and Data Guard role transitions, the target instance is in NOMOUNT or MOUNT. (UR = A) ("UseRestricted = Allowed") tells the listener it is fine to hand a session to a database that is not yet open. Skipping it is a very common cause of ORA-12514 at the worst possible moment.

6.3 `listener.ora`

On the standby, statically register the standby instance so the listener can serve connections even when the database is not OPEN:

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = prodstby)
      (ORACLE_HOME = /u01/app/oracle/product/19/db_1)
      (SID_NAME = prod)))

6.4 Verify connectivity

tnsping PRODSTBY
sqlplus sys@PRODSTBY as sysdba
sqlplus sys@PRODPRMY as sysdba

All three should succeed before you touch RMAN.

7. Standby instance preparation

7.1 Copy the password file

Copy from ASM (or $ORACLE_HOME/dbs) on the primary to $ORACLE_HOME/dbs/orapwprod on the standby. The SYS password must match; otherwise redo transport authentication fails with ORA-16191.

7.2 Build a minimal PFILE for the standby

*.audit_file_dest='/u01/app/oracle/admin/prod/adump'
*.audit_trail='db'
*.cluster_database=false
*.compatible='19.0.0'
*.control_files='+DATA/PROD/CONTROLFILE/current.261.1218045679',
                '+RECO/PROD/CONTROLFILE/current.256.1218045679'
*.db_block_size=8192
*.db_create_file_dest='+DATA'
*.db_name='prod'
*.db_unique_name='prodstby'
*.db_recovery_file_dest='+RECO'
*.db_recovery_file_dest_size=19732m
*.diagnostic_dest='/u01/app/oracle'
*.enable_pluggable_database=true
*.fal_client='PRODSTBY'
*.fal_server='PROD'
*.log_archive_config='DG_CONFIG=(PRODSTBY,PROD)'
*.log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST
   VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PRODSTBY'
*.log_archive_dest_2='SERVICE=PROD ASYNC
   VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PROD'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_format='%t_%s_%r.dbf'
*.remote_login_passwordfile='EXCLUSIVE'
*.standby_file_management='AUTO'
*.pga_aggregate_target=966m
*.sga_target=2896m
*.processes=300
*.open_cursors=300

Note the symmetry: db_unique_name is reversed, fal_server/fal_client are swapped, and LOG_ARCHIVE_DEST_2 already points back to PROD so the configuration "just works" after a future switchover.

7.3 Start the standby in NOMOUNT

[oracle@standby ~]$ export ORACLE_SID=prod
[oracle@standby ~]$ sqlplus / as sysdba
SQL> startup nomount pfile='/u01/app/oracle/product/19/db_1/dbs/initprod.ora';
ORACLE instance started.

Total System Global Area  3036673240 bytes
Fixed Size                   9139416 bytes
Variable Size              620756992 bytes
Database Buffers          2399141888 bytes
Redo Buffers                 7634944 bytes

8. Cloning the standby with RMAN `DUPLICATE … FROM ACTIVE DATABASE`

Connect from the standby host with the auxiliary set to the new instance and the target set to the live primary:

[oracle@standby ~]$ rman target sys@PRODPRMY auxiliary sys@PRODSTBY
target database Password:
auxiliary database Password:
connected to target database: PROD (DBID=629884015)
connected to auxiliary database: PROD (not mounted)

RMAN> DUPLICATE TARGET DATABASE FOR STANDBY
      FROM ACTIVE DATABASE
      DORECOVER
      NOFILENAMECHECK;

Behind the scenes RMAN will:

Create a standby controlfile.
Create OMF datafiles in +DATA sized from the source.
Restore the database from the active source over the network.
Recover the clone up to the latest available SCN.
Mount the standby and exit cleanly.

You will see a memory script along these lines as RMAN finishes the recover phase:

contents of Memory Script:
{
   set until scn  2518050;
   recover
   standby
   clone database
    delete archivelog
   ;
}
executing Memory Script
...
media recovery complete, elapsed time: 00:00:02
Finished recover at 27-NOV-25
Finished Duplicate Db at 27-NOV-25
RMAN> exit
Recovery Manager complete.

Tip — keep the duplicate fast and predictableAdd SECTION SIZE 32G for very large datafiles, increase the number of channels (ALLOCATE AUXILIARY CHANNEL …) for parallelism, and ensure the network between the two sites is the bottleneck you actually expect — not an asymmetric routing rule.

9. Start Redo Apply and verify

9.1 Engage Managed Recovery (MRP)

[oracle@standby ~]$ sqlplus / as sysdba

SQL> select status from v$instance;
STATUS
------------
MOUNTED

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Database altered.

The DISCONNECT clause runs the recovery in a background process so your session is free.

9.2 Verify roles, modes, and unique names

-- On the primary (RAC):
SQL> SELECT name, open_mode, database_role, db_unique_name FROM v$database;
NAME   OPEN_MODE   DATABASE_ROLE   DB_UNIQUE_NAME
----   ----------  -------------   --------------
PROD   READ WRITE  PRIMARY         PROD

-- On the standby:
SQL> SELECT name, open_mode, database_role, db_unique_name FROM v$database;
NAME   OPEN_MODE          DATABASE_ROLE     DB_UNIQUE_NAME
----   -----------------  ----------------  --------------
PROD   MOUNTED            PHYSICAL STANDBY  PRODSTBY

9.3 Check transport & apply lag

SQL> SELECT name, value, time_computed
     FROM v$dataguard_stats
     WHERE name IN ('transport lag','apply lag','apply finish time');

Healthy values are +00 00:00:00 for both transport and apply lag.

9.4 Real-time apply check (manual log switch)

-- Primary
SQL> alter system switch logfile;
SQL> /
SQL> /
SQL> select thread#, max(sequence#) from v$archived_log group by thread#;
   THREAD#  MAX(SEQUENCE#)
   -------  --------------
        1        21
        2        14

-- Standby
SQL> select thread#, max(sequence#) from v$archived_log group by thread#;
   THREAD#  MAX(SEQUENCE#)
   -------  --------------
        1        21
        2        14

If both sides report identical max sequence numbers within seconds, your transport and apply pipeline is alive.

10. Configuring Data Guard Broker

The Broker turns Data Guard from "a set of init parameters and SQL commands" into a managed configuration with a single source of truth. Every switchover, every health check, every protection-mode change becomes a single DGMGRL command.

10.1 Enable the Broker on both sides

-- Primary AND standby
SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE SCOPE=BOTH SID='*';

Make sure each broker config file location is set, or rely on the defaults under $ORACLE_HOME/dbs/dr1<DB_UNIQUE_NAME>.dat.

10.2 Stop the manual MRP before adding the standby

This step is non-negotiable: the Broker must take exclusive control of redo apply. If MRP is running, ENABLE CONFIGURATION can fail or behave unpredictably.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.

SQL> SELECT process, status, thread#, sequence# FROM v$managed_standby;
PROCESS  STATUS      THREAD#  SEQUENCE#
-------  ----------  -------  ---------
ARCH     CLOSING        1        27
ARCH     CLOSING        2        18
RFS      IDLE           2          0
RFS      RECEIVING      2         19
RFS      IDLE           1         29

10.3 Remove manual `SERVICE=` redo routes

If you keep LOG_ARCHIVE_DEST_2 with a manual SERVICE= attribute, the Broker refuses to take over and you get the classic:

Error: ORA-16698: member has a LOG_ARCHIVE_DEST_n parameter with SERVICE attribute set

Clear it on both sides before running ENABLE CONFIGURATION:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='' SCOPE=BOTH SID='*';

The Broker will recreate LOG_ARCHIVE_DEST_2 automatically on both sides — symmetrical, role-aware, and updated after every switchover.

10.4 Create and enable the configuration

[oracle@node1 ~]$ dgmgrl sys@PROD
DGMGRL> CREATE CONFIGURATION 'PROD_DG'
        AS PRIMARY DATABASE IS 'PROD'
        CONNECT IDENTIFIER IS PROD;
Configuration "PROD_DG" created with primary database "PROD"

DGMGRL> ADD DATABASE 'PRODSTBY'
        AS CONNECT IDENTIFIER IS PRODSTBY
        MAINTAINED AS PHYSICAL;
Database "prodstby" added

DGMGRL> ENABLE CONFIGURATION;
Enabled.

10.5 Verify

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 35 seconds ago)

From this moment on, you can use SHOW DATABASE, VALIDATE DATABASE, SWITCHOVER TO, and FAILOVER TO commands to drive the configuration.

11. Performing a Broker-managed switchover

A switchover is a planned, fully reversible role reversal between the primary and the standby — performed when both sides are healthy. It validates DR readiness, supports rolling maintenance, and is the safest way to exercise the configuration before you ever need a real failover.

11.1 Pre-flight checks

DGMGRL> SHOW CONFIGURATION;
-- Configuration Status: SUCCESS

DGMGRL> VALIDATE DATABASE prod;
  Database Role:    Primary database
  Ready for Switchover:  Yes
  Managed by Clusterware:  PROD: YES

DGMGRL> VALIDATE DATABASE prodstby;
  Database Role:     Physical standby database
  Primary Database:  PROD
  Ready for Switchover:  Yes
  Ready for Failover:    Yes (Primary Running)

Both databases must report Ready for Switchover: Yes, and there must be no transport or apply lag. Then:

11.2 Execute the switchover

[oracle@node1 ~]$ dgmgrl sys@PRODPRMY
DGMGRL> SWITCHOVER TO 'PRODSTBY';

Performing switchover NOW, please wait...
Operation requires a connection to database "prodstby"
...
New primary database "prodstby" is opening...
Operation requires start up of instance "prod" on database "prod"
Starting instance "prod"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "prodstby"

What the Broker does for you, in order:

Stops redo apply on the standby.
Switches over the current primary to standby role.
Switches the standby to primary role.
Restarts redo apply on the new standby.
Reverses redo transport direction by rewriting LOG_ARCHIVE_DEST_2 on both sides.

11.3 Post-switchover verification

DGMGRL> SHOW CONFIGURATION;
Configuration - PROD_DG
  Protection Mode: MaxPerformance
  Members:
  PRODSTBY - Primary database
    PROD     - Physical standby database
Configuration Status:
SUCCESS

-- New primary
SQL> select db_unique_name, database_role, open_mode from v$database;
DB_UNIQUE_NAME  DATABASE_ROLE  OPEN_MODE
--------------  -------------  ----------
PRODSTBY        PRIMARY        READ WRITE

-- New standby
SQL> select db_unique_name, database_role, open_mode from v$database;
DB_UNIQUE_NAME  DATABASE_ROLE     OPEN_MODE
--------------  ----------------  ---------
PROD            PHYSICAL STANDBY  MOUNTED

11.4 Why this matters operationally

Zero data loss — switchover is graceful and only proceeds when redo is fully synchronized.
HA/DR validation — every switchover proves your runbooks, listeners, application connect strings, and clusterware integration.
Rolling maintenance — patch the standby, switch over, patch the original primary, switch back. Application downtime drops to a handful of seconds while connections drain.
Confidence before failover — failover is the unplanned cousin of switchover. Practising switchover regularly is the single best preparation for a real DR event.

12. 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

13. Best practices, common pitfalls, and what to do next

13.1 Best practices that pay back over years

Symmetric configurations. Whatever you set on the primary (memory, parameter file structure, audit destinations, password file) should exist on the standby. After a switchover, today's standby is tomorrow's primary.
SRLs on both sides, sized to match online redo. Always one extra group per thread.
Use the Broker. Manual LOG_ARCHIVE_DEST_n management is fragile during role transitions; the Broker is not.
Regular validation. Schedule a weekly VALIDATE DATABASE from DGMGRL plus a monthly switchover drill.
Test failover, not just switchover. A real failover is forced and may include lag — exercise it in a non-prod copy.
Match patch levels. Apply RU/RUR on both sides in lockstep; mismatched binaries are a leading cause of redo apply errors.
Monitor v$dataguard_stats, v$archive_dest_status, and the alert log. Lag thresholds belong in your monitoring tool, not your memory.

13.2 Common pitfalls and how to avoid them

Symptom	Likely cause	Fix
`ORA-16191: Primary log shipping client not logged on`	Password files out of sync	Recopy `orapw` from primary; ensure `REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE`
`ORA-16698: member has a LOG_ARCHIVE_DEST_n parameter with SERVICE attribute set`	Manual redo route still present when adding the database to the Broker	Clear `LOG_ARCHIVE_DEST_2` on both sides, then re-enable
Standby falls behind, large transport lag	Network bandwidth or async overhead	Increase `LOG_ARCHIVE_MAX_PROCESSES`, check link MTU, consider compression
Switchover hangs at "waiting for dispatcher"	Active sessions or jobs holding cursors on the primary	Drain services, kill long-running sessions, retry
Datafile created on primary but missing on standby	`STANDBY_FILE_MANAGEMENT` set to `MANUAL`	Set to `AUTO` on both sides
Cannot connect to standby in NOMOUNT for RMAN duplicate	Listener has no static SID entry, or `(UR=A)` missing in TNS	Add static `SID_DESC` in `listener.ora`; add `(UR=A)` to the descriptor

13.3 Where to take this next

Move to MaxAvailability. Switch LOG_ARCHIVE_DEST_2 from ASYNC to SYNC AFFIRM when network latency between sites is acceptable, then set PROTECTION_MODE via the Broker.
Enable Fast-Start Failover (FSFO). An observer process can promote the standby automatically when the primary is unreachable, with zero or bounded data loss.
Active Data Guard. Open the standby READ ONLY WITH APPLY for offloaded reporting, backups, and ad-hoc queries — without breaking DR.
Cascaded standbys and far-sync instances. Tier your DR for both performance and zero data loss across geographies.
Backups from the standby. Move RMAN backups to the standby to take pressure off production.

14. Conclusion

The implementation walked through here delivers a robust DR posture: a 2-node RAC primary feeds redo in real time to a standalone ASM-based physical standby, the standby applies it continuously, and Data Guard Broker gives you a single, auditable control plane for switchover, failover, and health monitoring. PDBs replicate transparently inside the CDB, and every piece of the configuration is symmetrical — so the standby is genuinely ready to become the primary at any moment.

Build it, validate it, and rehearse the role transitions on a regular schedule. The first time you need DR is a terrible time to discover something was missing.

thanks for reading.

BR,

Zaheer