1. Introduction
Oracle Data Guard is
Oracle’s enterprise-grade disaster recovery and high availability (HA)
solution. It delivers real-time data protection, automated failover and
switchover capabilities, and efficient redo replication between primary and
standby databases.
In modern enterprise
environments—where continuous availability and zero data loss are
business-critical—implementing Oracle Data Guard between a 2-Node RAC
Primary and a 2-Node RAC Physical Standby provides a robust,
scalable, and highly resilient architecture that ensures:
• High Availability (HA)
across multiple nodes
• Enterprise-grade Disaster Recovery (DR)
• Zero or near-zero data loss (Maximum Availability / Protection modes)
• Automatic redo log transport and real-time apply
• Seamless role transitions using Data Guard Broker
• Node-level and site-level fault tolerance
This document provides a complete
end-to-end implementation guide for configuring Oracle Data Guard and
Data Guard Broker in a RAC-to-RAC environment, covering both infrastructure
and database layers.
This guide includes
environment details, prerequisites, configurations, duplicate process, redo
apply, verification, and broker setup.
This RAC-to-RAC
Data Guard implementation ensures maximum availability, scalability, and
business continuity, making it suitable for mission-critical enterprise
workloads.
2. Architecture Overview
2.1
Primary (RAC) Configuration
|
Component |
Details |
|
Nodes |
node1, node2 |
|
Cluster |
Oracle Grid Infrastructure (2-Node RAC) |
|
Database |
Container Database (CDB): test |
|
Instances |
test1, test2 |
|
PDB |
testpdb |
|
DB Unique Name |
test |
|
Storage |
ASM (+DATA, +RECO, +OCRVD) |
|
Role |
Primary |
|
Version |
Oracle Database 19.16 |
|
SCAN |
rac-scan.localdomain |
2.2 Standby (RAC) Configuration
|
Component |
Details |
|
Nodes |
DG-node1, DG-node2 |
|
Cluster |
Oracle Grid Infrastructure (2-Node RAC) |
|
Database |
Container Database (CDB): test |
|
Instances |
test1, test2 |
|
PDB |
testpdb |
|
DB Unique Name |
teststby |
|
Storage |
ASM (+DATA, +RECO) |
|
Role |
Physical Standby |
|
Version |
Oracle Database 19.16 |
|
SCAN |
DG-rac-scan.localdomain |
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 of all RAC nodes (Primary
& Standby)
• Private IPs (interconnect) of all
RAC nodes
• VIPs for all RAC nodes
• SCAN IPs for both Primary and
Standby clusters
Primary :
Node1 :
Node 2:
Standby :
DG-Node1 :
DG-Node2 :
7.2 tnsnames.ora
Primary :
Node1 :
Node 2:
Standby :
DG-Node1 :
DG-Node2 :
7.3 listener.ora
Proper global names and SID entries configured.
Primary :
Node1 :
Node2 :
Standby :
DG-Node1 :
DG-Node2 :
7.3 checking connectivity
Primary :
Node 1 :
Node 2:
Standby :
DG-Node1 :
DG-Node2 :
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
9.3 Post-Duplication Configuration for RAC Physical Standby
After the RMAN duplication completed successfully, the standby database
was created as a single-instance physical standby in MOUNT state.
To enable 2-node RAC functionality on the standby, additional configuration
steps were required.
Verify Standby Database Status
First, confirm that the database is a physical standby and is mounted:
✔ Database role: PHYSICAL STANDBY
✔ Open mode: MOUNTED
✔ Instance running on first standby node
Purpose:
Ensures RMAN duplication completed successfully and the standby is ready for
RAC conversion.
Create PFILE from Existing SPFILE
A PFILE was created from the default SPFILE to allow modification and
relocation of the SPFILE into ASM:
Purpose:
RAC databases must use an ASM-based SPFILE
accessible by all nodes.
Create ASM-Based SPFILE for RAC Standby
Using the generated PFILE, a new SPFILE was created in ASM:
The PFILE was then updated to point to the ASM SPFILE:
Database restarted in MOUNT mode using this SPFILE.
Purpose:
Allows all RAC instances to read a shared
parameter file.
Register Standby Database with Oracle Clusterware
The physical standby database was registered with Oracle Clusterware as
a RAC database:
Instances were then added for both nodes:
Purpose:
Enables Oracle Clusterware to manage the
standby database across both nodes.
9.4 RAC-Specific Standby Parameter Configuration
Initially, only one instance started successfully.
This was expected because RAC-specific parameters were not yet defined.
The following instance-level parameters were configured in the SPFILE:
Database was then restarted via Clusterware:
✔ Instance test1 running on DG-node1
✔ Instance test2 running on DG-node2
10.
Start Redo Apply
11.
Verification
11.1 PRODUCTION side: Primary RAC (TEST)
11.2 DR side:standby standalone (TEST)
11.3 Check Lag
All values confirmed synchronized.
11.4 Enable Real-Time Redo Apply (Active Data Guard) on RAC Standby
In a physical standby database, the default state after creation
is MOUNTED, where redo logs can be applied but no user queries are
allowed.
Opening the standby database in READ ONLY mode is required to
enable Active Data Guard.
Key Reasons for Opening READ ONLY
Enable Active Data Guard
- OPEN READ ONLY
allows users and applications to query the standby database
- Reporting and
read-only workloads can be offloaded from the primary database
- Improves primary
database performance
Without READ ONLY mode, the standby cannot be used for reporting.
STEPS:
Ø Before opening the standby database, any
existing redo apply was stopped:
Ø The physical standby database was opened in READ
ONLY mode:
Ø Managed recovery was restarted using current
redo logs:
11.5 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 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.
########### 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 ORA-16698 conflict.
Primary :
Standby :
12.2 Enable Broker on Both DBs
Primary
Standby
12.3 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
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 (TEST_DG)
shows STATUS = SUCCESS, confirming that both the primary database (TESTSTBY)
and the physical standby database (TEST) 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 (TESTSTBY):
Ø
On
new standby (TEST):
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 |
TEST (2-Node RAC), OPEN |
|
Standby DB |
TESTSTBY (2-Node RAC), APPLYING
LOGS |
|
Data Guard |
ACTIVE, SYNCHRONIZED |
|
Log Transport |
WORKING |
|
Broker |
ENABLED & HEALTHY |
|
PDBs |
Successfully replicated |
15.
Conclusion
This implementation successfully establishes
a highly resilient disaster recovery environment using Oracle Data Guard
between a 2-Node RAC Primary and a 2-Node RAC Physical Standby,
both leveraging ASM for storage.
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