Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

Enterprise DBA’s Guide to Oracle

Data Guard – Complete Theory +
Practical Walkthrough

SECTION 1: INTRODUCTION TO ORACLE DATA GUARD

1.1 What is Oracle Data Guard?

Oracle Data Guard is the officially supported high availability and disaster recovery (HA/DR)
technology developed by Oracle Corporation. It provides a robust framework for maintaining
synchronized copies of a production (primary) database in the form of one or more standby
databases. These standby databases are continually updated with redo data generated on the
primary, ensuring data consistency and minimizing data loss in the event of failure. It forms a critical
component in any enterprise's data protection and business continuity strategy.
Oracle Data Guard supports the following types of standby databases:

1. Physical Standby:
This is an exact, block-for-block replica of the primary database. It uses Oracle's Redo Apply
technology to apply redo data received from the primary. Physical standby supports all data
types, is always in sync with the primary at the block level, and can optionally be opened in
read-only mode using Active Data Guard.
2. Logical Standby:
This type of standby database uses SQL Apply technology, wherein redo is converted into
SQL statements and then executed on the standby. It allows for some structural differences
such as additional indexes or materialized views, and can be used simultaneously for reporting
and read-only access. However, not all data types are supported.
 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

3. Snapshot Standby:
A snapshot standby is a physical standby database temporarily converted to a read-write
mode for testing or development. While in this state, it diverges from the primary. Later, it can
be flashed back to the restore point and re-synchronized with the primary.
4. Far Sync Instance:
A Far Sync is a lightweight, zero-data storage instance that receives redo synchronously from
the primary and forwards it asynchronously to a remote standby. This architecture allows the
primary to achieve synchronous protection locally without being affected by WAN latency,
while ensuring zero data loss over long distances.
5. Cascaded Standby:
A standby that receives redo not from the primary directly, but from another standby (which
can be physical or Far Sync). This is useful when network topology restricts direct connections
between the primary and all standbys.
Oracle Data Guard continuously monitors the health of the primary and standby environments. It
supports seamless transition of roles during planned maintenance (switchover) or unexpected
outages (failover), ensuring data integrity and minimal recovery time.

1.2 Use Cases and Objectives

Oracle Data Guard plays a vital role across different operational and compliance domains. Its
purpose extends far beyond mere failover, addressing availability, scalability, security, and efficiency.
Some of its most prominent use cases and functional goals include:
• Disaster Recovery Readiness:
Maintain a fully synchronized copy of the production database in a geographically separate
location to survive data center-wide outages.
• Zero or Near-Zero Data Loss Goals:
When configured with synchronous transport modes, Oracle Data Guard ensures zero data
loss (RPO = 0) during failovers or unexpected shutdowns.
• Load Distribution for Reporting and Backups:
Read-only Active Data Guard configurations allow users to offload reports, analytics, and
RMAN backups to the standby database, reducing load on the primary.
• Rolling Upgrades and Patch Testing:
The standby database can be upgraded first in isolation. After successful testing, roles can be
switched to make the upgraded system primary, allowing near-zero-downtime patching or
version changes.
 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

• Protection from Human Errors and Logical Corruption:

Flashback-enabled standby databases can rewind to a specific SCN or time to recover from
accidental data deletion, corruption, or misapplied scripts.
• Regulatory Compliance and Business Continuity Planning:
Many industries (banking, pharma, government) require proof of recovery capability. Data
Guard satisfies Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
mandates efficiently.
• Simulated Failover and DR Drills:
Organizations often test business continuity by simulating failovers. Data Guard allows clean
transitions without disrupting real production data.

1.3 Key Components of Oracle Data Guard

Oracle Data Guard consists of several tightly integrated technical components that work together to
ensure the high availability and protection of mission-critical databases:
• Redo Transport Services:
This component is responsible for transmitting redo data from the primary database to one or
more standby destinations. Transport can be performed in SYNC (synchronous) or ASYNC
(asynchronous) mode, with or without compression. Redo can be written to Standby Redo
Logs (SRLs) for real-time application or as archived logs for batch processing.
• Apply Services:
On the standby side, these services apply the redo data to keep the database synchronized
with the primary. In a physical standby, redo is applied using Redo Apply via managed
recovery mode. In a logical standby, redo is transformed into SQL and then executed using
SQL Apply. These services can operate continuously (real-time apply) or be scheduled.
• Role Management Operations:
Oracle Data Guard allows dynamic transition of roles between the primary and standby
databases. These transitions include:
o Switchover: Planned switch between primary and standby with no data loss.
o Failover: Emergency promotion of a standby to primary when the original primary is
unrecoverable.
o Reinstatement: Restore a failed primary (after failover) to standby role using Flashback
or RMAN.
• Standby Redo Logs (SRLs):
These are additional log files required on standby systems for real-time redo apply. The
number of SRLs should always be equal to or greater than the number of primary redo log
groups, ideally with one extra group to avoid performance stalls.
 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

• Data Guard Broker (Optional but Recommended):

A centralized management layer that simplifies the configuration, monitoring, and role
management of Data Guard environments. It provides CLI (dgmgrl) and GUI interfaces (via
Oracle Enterprise Manager), supports automatic failover, and ensures best practice
compliance during role transitions.
• Network and Listener Configuration:
Proper Oracle Net and listener configuration is critical for communication between primary and
standby databases. Secure, low-latency channels are essential for SYNC mode; TNS must be
properly defined and listeners must support static registration for NOMOUNT connections.
Each of these components must be correctly configured, monitored, and validated in real-time to
achieve the core objectives of Oracle Data Guard: reliability, resilience, and recoverability.

SECTION 2: ARCHITECTURE TYPES AND DESIGN DECISIONS

Designing a Data Guard architecture requires careful planning across multiple layers — including
type of standby database, protection mode, network layout, and redo application strategy. The
decisions made in this phase determine the reliability, performance, and recovery behavior of the
overall HA/DR solution. Below are the foundational components and key decision areas for
architecting a resilient Data Guard setup.

2.1 Standby Database Types: Physical vs Logical vs Snapshot

Oracle Data Guard offers multiple standby configurations tailored to various business and operational
needs. Understanding the behavior, benefits, and limitations of each type is essential before
implementation.
Physical Standby Database
• A physical standby is an exact block-for-block copy of the primary database. It receives and
applies redo at the binary level using media recovery.
• It supports real-time apply using Standby Redo Logs (SRLs), enabling minimal lag.
• Most commonly deployed type due to simplicity, full data type support, and ease of
switchovers.
 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

• Can be opened in read-only mode using Active Data Guard to support reporting and backups
without breaking synchronization.
• Supports Flashback Database for reintegration after failover or testing.
Use Case: Critical transactional systems requiring strong consistency, DR readiness, and identical
schema copies.
Logical Standby Database
• A logical standby receives redo, converts it to SQL statements (DML/DDL), and applies them
using SQL Apply.
• It is not a block-for-block clone and can differ structurally (e.g., additional indexes, materialized
views).
• Supports read-write operations on different objects, making it ideal for reporting and
analytics workloads.
• Does not support all data types or DDL operations (e.g., BFILEs, SecureFiles, some LOBs).
Use Case: Situations where read-write reporting is needed or schema customization is necessary on
standby.
Snapshot Standby Database
• A snapshot standby is a temporary transformation of a physical standby into a read-write
clone for dev/test activity.
• While in snapshot mode, redo is not applied. A restore point is created at the moment of
conversion.
• Once testing is complete, the snapshot standby can be flashed back to the restore point and
resume redo apply from that point.
Use Case: Application testing, schema validation, or UAT on live data without affecting production.
Key Comparison:

Feature Physical Logical Snapshot

Apply Method Redo Apply SQL Apply None (while active)

Supports Active Data Guard Yes No No

Open for reporting Read-only Read-write Read-write

Schema modification No Yes Yes

Flashback supported Yes Yes Yes

 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

2.2 Protection Modes: Balancing Data Loss vs Availability

Oracle Data Guard provides configurable protection modes to match business RPO/RTO goals.
These modes govern how redo is sent and acknowledged between the primary and standby systems.

Maximum Availability
• Uses SYNC transport and requires standby to acknowledge redo receipt before commit.
• If the standby becomes temporarily unreachable, the primary continues operating in resync
mode to avoid application downtime.
• Offers a balance between zero data loss and continuous availability.
• Upon reconnection, Data Guard re-synchronizes the missed logs.
Ideal for: Enterprises that need near-zero data loss but can tolerate short sync gaps.

Maximum Protection
• Uses SYNC transport, but unlike Maximum Availability, halts transactions on the primary if
the standby is unreachable.
• Guarantees zero data loss (RPO = 0).
• Introduces high risk of system unavailability in case of standby/network issues.
• Requires highly stable infrastructure, preferably with Far Sync support and redundant
connections.
Ideal for: Financial institutions or military systems where data loss is unacceptable, and uptime can
be traded for integrity.

Maximum Performance
• Uses ASYNC redo transport, where the primary does not wait for the standby to acknowledge
redo.
• Fastest mode; has no impact on primary performance.
• Accepts the possibility of some data loss (depending on lag between send and apply).
• Most widely used in WAN deployments, cloud-based DRs, and less critical databases.
Ideal for: Non-core business systems or WAN scenarios where latency makes SYNC impractical.
 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

2.3 Redo Apply Models: Real-Time Apply and Active Data Guard
Real-Time Apply
• Redo data is written to SRLs on the standby and applied immediately as it is received.
• This avoids waiting for archived logs and significantly reduces data loss during failover.
• Requires standby redo logs and proper configuration of recovery mode.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE
DISCONNECT;
Benefits:
• Enables near-zero lag
• Improves failover precision
• Used with Maximum Availability/Protection

Active Data Guard

• A licensed feature that allows the standby database to be opened in read-only mode while
redo is applied.
• Supports real-time reporting, dashboards, and ad-hoc queries on live standby without
impacting production.
• Useful for offloading backups, analytics, and integration with ETL tools.
ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE
DISCONNECT;
Benefits:
• Combines HA with operational offloading
• Transparent for most read workloads
• Greatly enhances infrastructure ROI
 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

2.4 Network Architecture and Latency Management

The underlying network plays a pivotal role in redo transport and Data Guard efficiency. Latency,
bandwidth, and connectivity must be optimized based on the protection mode and apply strategy.
Key Design Recommendations:
• Use Dedicated Bandwidth:
Avoid sharing the same channel with user traffic. Implement VLAN tagging or physical
separation for Data Guard traffic.
• Enable TCP Keepalives:
Configure TCP keepalive settings to detect broken connections quickly. Default timeouts are
often too long for HA environments.
• QoS Tagging:
On WAN links, tag redo transport traffic with high-priority classes to minimize impact during
congestion.
• Use Compression:
Oracle supports redo transport compression, especially beneficial in ASYNC + WAN setups
where bandwidth is constrained.
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=STANDBY ASYNC
COMPRESSION=ENABLE ...';
• Implement Far Sync for Long Distance SYNC:
To achieve synchronous transport over WAN without primary latency, introduce a Far Sync
instance at the primary site. It receives redo synchronously and forwards it asynchronously to
remote standby.
• NTP Synchronization:
All nodes in the Data Guard configuration must have their system clocks synchronized via
NTP. Unsynchronized clocks can cause archive gaps, false failures, or mismatched alert
timestamps.
• Secure Communication:
Implement Oracle Net Encryption and Data Guard Redo Transport Authentication using SSL or
password-based access to prevent interception or tampering.
 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

SECTION 3: PRE-IMPLEMENTATION CHECKLIST (SOURCE AND TARGET)

3.1 System Level

• Verify OS is same family/version (RHEL 7.x vs RHEL 8.x)
• Kernel parameters (shmmax, shmall, sem, file-max) match Oracle-recommended limits
• /etc/hosts has forward and reverse entries for all RAC or standalone nodes
3.2 User and Environment
• oracle user exists with proper permissions
• Oracle Base and Home directory structures created with appropriate ownership
• Ulimits: nofile, nproc, stack, and memlock configured
3.3 Directory Structure
/u01/app/oracle/product/19.0.0/dbhome_1
/u02/oradata/DBNAME
/u03/archivelog/DBNAME
3.4 TNS Configuration
• Ensure TNS connectivity between nodes (tnsping PRIMARY, tnsping STANDBY)
• Listener on both ends must be running and configured in listener.ora

SECTION 4: PRIMARY DATABASE CONFIGURATION

4.1 Enable Archive Log and Force Logging

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
ALTER DATABASE FORCE LOGGING;
 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

4.2 Validate Redo Log Groups

SELECT GROUP#, THREAD#, BYTES/1024/1024 AS SIZE_MB, STATUS FROM V$LOG;
Minimum: 3 redo logs per thread.

4.3 Create Standby Redo Logs (SRLs)

If primary has 3 groups, create at least 4 SRLs:
ALTER DATABASE ADD STANDBY LOGFILE GROUP 10 '/u03/srl1.log' SIZE 512M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 11 '/u03/srl2.log' SIZE 512M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 12 '/u03/srl3.log' SIZE 512M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 13 '/u03/srl4.log' SIZE 512M;

4.4 Set Initialization Parameters

-- Required to declare primary and standby databases in configuration
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(PRIMARY,STANDBY)'
SCOPE=BOTH;

-- Destination to send redo to standby over Oracle Net

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=STANDBY ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=STANDBY'
SCOPE=BOTH;

-- Enables redo transmission to standby

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;

-- FAL server (where to fetch missing logs FROM)

ALTER SYSTEM SET FAL_SERVER=STANDBY SCOPE=BOTH;

-- FAL client (how we are known TO the standby)

ALTER SYSTEM SET FAL_CLIENT=PRIMARY SCOPE=BOTH;
 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

-- Automatically convert datafile paths from primary to standby format

ALTER SYSTEM SET DB_FILE_NAME_CONVERT='/u98/','/u02/' SCOPE=SPFILE;

-- Automatically convert redo log paths

ALTER SYSTEM SET LOG_FILE_NAME_CONVERT='/u98/','/u02/' SCOPE=SPFILE;

-- Enables standby redo apply to continue across sessions

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO SCOPE=BOTH;

SECTION 5: STANDBY SERVER PREPARATION

5.1 Create Required Directories

mkdir -p /u02/oradata/DBNAME
mkdir -p /u03/archivelog/DBNAME
chown -R oracle:oinstall /u02 /u03

5.2 Configure Password File

orapwd file=$ORACLE_HOME/dbs/orapwDBNAME password=oracle format=12

5.3 Prepare Static Listener Entry

In listener.ora on standby:
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = DBNAME)
(ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1)
 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

)
)

If you're preparing the standby manually or using DUPLICATE, ensure these are in place:
-- Ensure the unique name is set (must differ from primary)
ALTER SYSTEM SET DB_UNIQUE_NAME='STANDBY' SCOPE=SPFILE;

-- File and log path conversions (if directory structure differs)

ALTER SYSTEM SET DB_FILE_NAME_CONVERT='/u02/','/u98/' SCOPE=SPFILE;
ALTER SYSTEM SET LOG_FILE_NAME_CONVERT='/u02/','/u98/' SCOPE=SPFILE;

-- Enables standby to automatically add/remove files in sync with primary

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO SCOPE=BOTH;

-- Required if using FAL (especially for gap resolution)

ALTER SYSTEM SET FAL_SERVER=PRIMARY SCOPE=BOTH;
ALTER SYSTEM SET FAL_CLIENT=STANDBY SCOPE=BOTH;

-- Accept incoming redo from primary

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/u98/arch
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=STANDBY' SCOPE=BOTH;

-- Accept redo
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_1=ENABLE SCOPE=BOTH;

5.4 Start Instance in NOMOUNT

export ORACLE_SID=DBNAME
sqlplus / as sysdba
STARTUP NOMOUNT;
 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

SECTION 6: RMAN DUPLICATE FOR STANDBY

6.1 Create TNS Entry

TNS should exist for PRIMARY and STANDBY in tnsnames.ora.

6.2 Execute RMAN Command

rman target sys@PRIMARY auxiliary sys@STANDBY
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
DORECOVER
SPFILE
SET DB_UNIQUE_NAME='STANDBY'
SET CONTROL_FILES='/u02/oradata/DBNAME/control01.ctl'
SET DB_FILE_NAME_CONVERT='/u02/','/u02/'
SET LOG_FILE_NAME_CONVERT='/u02/','/u02/'
NOFILENAMECHECK;

SECTION 7: STANDBY ACTIVATION AND LOG APPLY

7.1 Start Real-Time Apply

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE
DISCONNECT;

7.2 Monitor Apply Progress

SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY;
SELECT SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

SECTION 8: SWITCHOVER AND FAILOVER

8.1 Switchover Process

On primary:
SELECT SWITCHOVER_STATUS FROM V$DATABASE;
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY;
SHUTDOWN IMMEDIATE;

STARTUP MOUNT;
On standby:
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
ALTER DATABASE OPEN;

8.2 Failover (Emergency)

On standby:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
ALTER DATABASE ACTIVATE STANDBY DATABASE;

SECTION 9: POST CONFIGURATION & MAINTENANCE

9.1 Configure RMAN Backups on Standby

CONFIGURE CONTROLFILE AUTOBACKUP ON;
BACKUP DATABASE PLUS ARCHIVELOG;

9.2 Setup Log Cleanup

DELETE ARCHIVELOG ALL COMPLETED APPLIED;
 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

9.3 Lag Monitoring

SELECT NAME, VALUE FROM V$DATAGUARD_STATS;

SECTION 10: TROUBLESHOOTING TECHNIQUES

• Check alert.log for errors

• Use show parameter to verify mismatched config
• Validate listener connectivity via tnsping
• Check apply gaps in v$archive_gap
• Verify SRL sizes and counts
• Confirm logs exist in archive dest using ls -ltr

📘 Oracle Data Guard – Summary & Final Thoughts

What We Learned
This handbook provided a comprehensive, in-depth exploration of Oracle Data Guard, covering
everything from core architecture to real-world implementations, including practical scenarios
and enterprise configurations.
We started by understanding the purpose of Data Guard — to ensure disaster recovery, data
protection, and high availability by maintaining one or more synchronized standby databases for a
production (primary) database.
We then explored all types of standby databases:
• Physical Standby – exact binary copy with Redo Apply.
• Logical Standby – uses SQL Apply; allows reporting and customization.
• Snapshot Standby – temporary read-write standby for testing.
• Far Sync – forwards redo without holding full datafiles; ideal for zero data loss across regions.
• Active Data Guard – adds real-time query, DML redirection, and offload capability.
 Oracle Data Guard – Complete Enterprise Handbook (Theory + Practical) – Brijesh Mehra

Real-World Usage & Enterprise Perspective

In real-world enterprise deployments:
• Oracle Data Guard is a critical component in Disaster Recovery (DR) and Business
Continuity Planning (BCP).
• Financial institutions, telecom, government systems, and SaaS platforms rely on it to
ensure 24x7 uptime, data integrity, and automated failover.
• Organizations combine Data Guard with Oracle RAC and Oracle Grid Infrastructure to build
multi-tiered HA+DR solutions.

Key Takeaways
• Oracle Data Guard is essential for any mission-critical Oracle environment.
• It provides physical and logical standby options, each suited for different needs.
• With real-time Redo Apply, automatic failover, and query offloading, it improves both
availability and performance.
• Proper planning, testing, and monitoring are crucial for Data Guard success.
• Oracle’s advanced features like Fast-Start Failover (FSFO) and Data Guard Broker simplify
administration and strengthen reliability.
Oracle Data Guard is not just a tool — it’s a strategic layer of protection for your data. When
configured and managed correctly, it enables your enterprise to survive hardware failures, site
outages, and disasters without data loss or service downtime. Whether you are a DBA, architect, or
IT leader, understanding Data Guard is vital to mastering Oracle high availability and disaster
recovery solutions.