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 26ai |
|
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 26ai |
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 (26ai) 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 ORA-16698 conflict.
PRIMARY :
Standby :
Begin Data Guard Broker Configuration
12.4 Verify
13. Manual Data Guard vs Data Guard Broker
|
Feature |
Manual Data
Guard |
Data Guard
Broker |
|
Configuration Method |
SQL*Plus + init
parameters |
DGMGRL CLI or OEM GUI |
|
Setup Complexity |
Higher (many parameters
to configure manually) |
Lower (guided and
automated) |
|
Role Transitions |
Manual
switchover/failover commands |
Single command
switchover/failover |
|
Monitoring |
Dynamic views (V$
views) |
Built-in health
monitoring |
|
Error Handling |
Prone to human error |
Automated validation
and checks |
|
Failover Management |
Manual intervention
required |
Fast-start failover
supported |
|
Reinstate After
Failover |
Manual rebuild required |
Automatic reinstate
supported |
|
Centralized Management |
No |
Yes (Broker
configuration) |
|
Ease of Use |
Requires deep expertise |
DBA-friendly and
simplified |
|
Automation Level |
Low |
High |
|
Integration with OEM |
Limited |
Fully integrated |
|
Production Suitability |
Small or learning
setups |
Recommended for
production |
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
16. What’s New in Oracle 26ai Data Guard
Oracle Database 26ai introduces several enhancements that improve Data
Guard manageability, automation, and resilience. Key highlights include:
- Improved Broker
Automation – Faster configuration and better
integration with dynamic environments, reducing manual tuning.
- Enhanced Role
Transition Stability – Switchover and failover
operations are more consistent with reduced downtime.
- Better Monitoring
& Observability – Improved diagnostic
visibility for redo transport, apply lag, and health validation.
- Optimized Redo
Transport Performance – More efficient network
handling for high-throughput environments.
- Cloud-Ready
Integration – Designed for hybrid deployments
across on-premises and cloud platforms.
These improvements make Data Guard in 26ai more stable, intelligent, and
easier to manage compared to earlier versions.
17. Why Use
Data Guard Broker
Using Data Guard without Broker is possible, but Broker adds significant
advantages:
- Centralized
configuration management
- Simplified
switchover/failover
- Automatic health
monitoring
- Easier automation
and scripting
- Reduced human error
during DR events
In Oracle 26ai, Broker is more mature and recommended for all production
setups.