1.
Introduction
Oracle Data Guard is Oracle’s enterprise-level disaster
recovery and high availability (HA) solution. It provides real-time data
protection, automated failover/switchover capabilities, and efficient
replication between primary and standby databases.
In modern enterprise environments, where business continuity
is critical, implementing Data Guard between a highly available 2-Node RAC (Real Application Clusters)
primary and a standalone physical
standby ensures:
•
High
Availability (HA)
•
Disaster
Recovery (DR)
•
Zero/Minimal
Data Loss
•
Automatic
log transport and apply
•
Seamless
role transitions
This document explains the complete end-to-end implementation of Oracle Data Guard and Data
Guard Broker between:
•
A 2-node RAC Primary
CDB running on ASM
•
A Standalone Physical
Standby CDB running on ASM
This guide includes environment details, prerequisites,
configurations, duplicate process, redo apply, verification, and broker setup.
2. Architecture Overview
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 |
3.
Objectives of This Implementation
•
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.
4. Prerequisites
4.1 Database & OS
Requirements
•
Identical Oracle version (19.16) on both servers.
•
ASM disk groups available on primary and standby.
•
Sufficient network connectivity (ports 1521 open).
4.2 Configuration Requirements
•
Primary in ARCHIVELOG
and FORCE LOGGING mode.
•
Oracle Password File copied to standby.
•
tnsnames.ora and listener.ora configured correctly.
•
DG-related initialization parameters set.
•
SRLs (Standby Redo Logs) added on PRIMARY.
5. Primary Database Configuration
5.1 Make sure primary is in archivelog mode :
5.2
Check FORCE LOGGING is enabled :
6 Initialization Parameters
6.1 Set
Primary Database Initialization Parameters :
6.2 Add Standby Redo Logs (SRL)
For RAC (2 threads), SRLs created:
Thread 1: Groups 5, 6, 7
Thread 2: Groups 8, 9, 10
7. Network Configuration
7.1 Update /etc/hosts on all servers
Includes:
- Public IPs
- VIPs
- SCAN IPs
- Standby IP
Node1 :
Node 2:
Standby :
7.2 tnsnames.ora
Node1 :
Node 2:
Standby :
7.3 listener.ora
Proper global names and SID entries configured.
Node1 :
Node2 :
Standby :
7.3 checking connectivity
Node 1 :
Node 2:
Standby :
8. Password File & Initialization File Setup
Copy Password File from ASM and ORACLE_HOME/dbs
Create PFILE and Copy
9. Creating the Standby Database
9.1 Start Standby NOMOUNT
9.2 RMAN Duplicate Command
RMAN will:
✔ Create Controlfile
✔ Create Datafiles (OMF)
✔ Restore DB
✔ Recover DB
✔ Mount Standby
10. Start Redo Apply
11. Verification
11.1 PRODUCTION side: Primary RAC (prod)
11.2 DR side:standby standalone (prod)
11.3 Check Lag
All values confirmed synchronized.
11.4 Real-Time Log Apply Verification by Manual Log Switch
To verify that the physical standby database is receiving redo in real
time and applying it correctly, we manually force a log switch on the primary
database. This sends a new archived log to the standby, and the Managed
Recovery Process (MRP) should immediately begin applying it.
Primary
>Force Redo Log Switch on Primary
>Check Latest Archive Log Sequence on Primary
Standby
>Verify Redo Reception on Standby
12. Data Guard Broker Configuration
12.1 Enable Broker on Both DBs Primary
Standby
12.2 Removing MRP Before Data Guard
Broker Configuration
Before
configuring Data Guard Broker, it is important to stop the Managed Recovery Process (MRP) on the standby database.
MRP is
responsible for applying redo logs, but when active, it can interfere with
Broker operations such as:
•
enabling the Data Guard configuration
•
adding the standby database to the broker
•
performing switchover/failover
•
reading the correct database state information
Data Guard
Broker automatically manages redo apply, so it must take full control.
Therefore, MRP must be stopped manually before
enabling DG Broker.
12.3 Create DG Configuration
########### NOTE ###############
When using Broker, manual redo routes (SERVICE=…) must be
removed.
Broker will automatically create:
LOG_ARCHIVE_DEST_2 on Primary to Standby
LOG_ARCHIVE_DEST_2 on Standby back to Primary
This allows:
Automatic failover
Switchover
Health checks
Automatic redo routing after role transitions
If manual SERVICE=… exists, the broker does NOT take control
— this creates the ORA16698 conflict.
PRIMARY :
Standby :
Begin Data Guard Broker Configuration
12.4 Verify
13. Switchover Operation in Data Guard
Broker
A Switchover is a
planned role reversal between the Primary
and the Standby database, performed
when both databases are healthy.
It is a zero data loss
operation and is typically done for:
•
maintenance activities on the primary
•
testing the disaster recovery (DR) site
•
validating Data Guard configuration
•
planned failover simulations
During a switchover:
•
The Primary
becomes a Standby
•
The Standby
becomes the new Primary
•
Redo transport and apply automatically reverse directions
•
Data Guard Broker handles all internal steps
Switchover is safe,
fast, and fully reversible as long as both databases are synchronized.
13.1 Prerequisites Before Performing Switchover
Ensure the following:
1. Data Guard
Broker Configuration Status = SUCCESS
2. Both
databases have no apply/transport lag
13.2 Execute the Switchover Using DGMGRL
Step 1:
Login to DGMGRL
Step
2: Perform the Switchover During switchover:
•
Broker stops redo apply
•
Converts the standby database to primary
•
Converts the original primary to standby
•
Starts redo apply on the new standby
13.3 Post-Switchover Verification
Check
configuration status
The Data Guard Broker configuration (PROD_DG) shows STATUS =
SUCCESS, confirming that both the
primary database (PRODSTBY) and the physical standby database (PROD) are
healthy, synchronized, and communicating properly. The configuration is
operating in Maximum Performance mode, with no transport or apply issues. This
validates that the switchover was
successful and the Data Guard environment is functioning normally.
Verify new database roles
On new
primary (PRODSTBY):
On new
standby (PROD):
13.4 Benefits of Performing a Switchover
•
Zero data loss (safe operation)
•
Validates HA/DR readiness
•
Confirms Data Guard health
•
Used for patching or maintenance
•
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. 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.
This setup aligns with best practices for:
•
High
Availability (HA)
•
Disaster
Recovery (DR)
•
Minimal
downtime architecture
•
Enterprise-level
data protection