Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

Introduction to Oracle Data Guard

Oracle Data Guard is a high availability and disaster recovery solution provided by Oracle that ensures
data protection and business continuity. It maintains standby copies of a production database (known
as the primary database) and keeps them synchronized in real time or near-real time. These standby
databases can be physical (block-for-block copies) or logical (SQL-level replicas) and are
automatically updated using redo data sent from the primary. Data Guard can automatically detect
and recover from failures, providing a seamless failover mechanism to the standby database with
minimal downtime. It supports switchover and failover operations, allowing planned maintenance or
unexpected outages without impacting business operations. It also integrates with Oracle Fast-Start
Failover (FSFO) for automatic failover when the primary becomes unavailable. Data Guard plays a
critical role in achieving high availability (HA), disaster recovery (DR), and data consistency across
geographies. It supports both synchronous and asynchronous redo transport methods based on
business needs. Oracle Active Data Guard, an extension of Data Guard, allows read-only access to
standby databases, enabling reporting and backups without affecting the primary. This powerful tool
is widely used in mission-critical enterprise environments to ensure zero data loss and maximum
uptime.

Types of Standby Databases in Oracle Data Guard

Oracle Data Guard offers multiple standby database configurations to ensure high availability, disaster
recovery, and data protection. Each type serves a specific purpose depending on the use case,
system requirements, and business continuity strategy. Below is a detailed explanation of each
standby database type supported by Oracle Data Guard.

1. Physical Standby Database

A Physical Standby Database is an exact, block-for-block replica of the primary database. It uses
Redo Apply to keep in sync by applying redo logs received from the primary in real-time or at
scheduled intervals.

Key Features:

• Uses Redo Apply technology.

• Supports both real-time apply and archived log apply.
• Data is kept in physical and binary identical format to the primary.

Use Cases:

• Ideal for disaster recovery and failover scenarios.

• Can be used for read-only reporting with Active Data Guard license.
• Supports backup offloading—backups can be taken from standby to reduce primary load.

Page 1
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

Pros:

• Best for fast failover due to exact physical structure.

• Supports Data Guard Broker for automated management.
• Minimal divergence from the primary when in real-time apply mode.

Limitations:

• Cannot be used for read-write operations (unless activated).

• Requires same Oracle version and platform as the primary.

2. Logical Standby Database

A Logical Standby Database maintains the same logical data but does not have to be an exact
physical copy. It uses SQL Apply to apply changes by re-executing SQL statements from redo logs.

Key Features:

• Uses SQL Apply (not redo block apply).

• Supports read-write access to non-replicated tables.
• Enables reporting and custom queries alongside replication.

Use Cases:

• Perfect for read-intensive environments needing custom queries.

• Used for rolling upgrades using DBMS_ROLLING.

Pros:

• Can have custom indexes, materialized views, and partitions.

• Supports heterogeneous platforms (e.g., Linux → Windows).
• Greater flexibility in schema-level replication.

Limitations:

• Not all data types and DDL operations are supported.

• More complex to configure and maintain.
• Slight lag in replication due to SQL parsing and execution.

Page 2
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

3. Snapshot Standby Database

A Snapshot Standby is a read-write clone of a physical standby. It allows users to run tests, apply
patches, or perform QA in a temporary writable mode. Once done, it can be reverted to its original
standby role.

Key Features:

• Converts a physical standby to read-write mode.

• Maintains flashback point to revert to previous standby state.
• Ideal for testing and development on production-like data.

Use Cases:

• Patching and testing without disturbing production.

• UAT on real-time replicated data without affecting standby sync.

Pros:

• Flexibility to switch between read-write and standby mode.

• Allows safe testing on live data with rollback capability.
• No need to recreate standby after testing.

Limitations:

• During Snapshot mode, no redo apply occurs.

• Needs sufficient flashback log space to maintain restore point.
• Reversion takes time if large changes are done during testing.

4. Far Sync Instance

A Far Sync Instance is a lightweight Oracle instance that forwards redo from primary to one or more
remote standby databases. It doesn’t hold full data but only redo logs, improving performance and
data protection across distances.

Key Features:

• Contains only controlfile, SRLs, and Oracle instance (no datafiles).

• Forwards redo to remote standby in synchronous or asynchronous mode.
• Ensures zero data loss for remote standby without performance hit.

Use Cases:

• Used when remote standby is across regions/datacenters.

• Helps meet RTO/RPO compliance in disaster recovery strategy.

Page 3
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

Pros:

• Enables Zero Data Loss across wide area networks (WANs).

• Reduces latency impact on primary performance.
• Requires less resources than full standby.

Limitations:

• Cannot be used for query or reporting.

• Still needs network availability to function effectively.
• Needs careful configuration of SYNC/ASYNC transport modes.

5. Active Data Guard (ADG)

Active Data Guard is an Oracle licensed feature that allows the physical standby to be open in read-
only mode while redo apply is actively happening. This allows reporting and queries on a real-time
synced database.

Key Features:

• Standby open in read-only mode with real-time redo apply.

• Queries don’t block apply, and apply doesn’t block queries.
• Needs Active Data Guard license.

Use Cases:

• Real-time reporting and analytics on production-synced data.

• Running health checks, dashboards, or BI tools on standby.

Pros:

• Reduces load on primary database.

• Provides immediate data visibility for users.
• Backup, reporting, and ETL jobs can run on ADG.

Limitations:

• Requires additional licensing cost.

• Cannot write on standby (except for temporary tables).
• Slight lag possible depending on redo transport mode.

Page 4
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

Oracle Data Guard – Modes of Operation

(Protection Modes)

Oracle Data Guard offers three Protection Modes, each tailored to balance data protection,
availability, and performance. These modes govern how redo data is transmitted from the
primary database to its standby database(s) and how the primary database responds if a failure
occurs. Below is a detailed look at each mode, their internals, use cases, and trade-offs:

1. Maximum Protection Mode

This is the highest level of data protection offered by Oracle Data Guard. It ensures zero data
loss in case of a primary database failure. The primary will not commit any transaction until the
redo has been written to the standby's standby redo logs (SRLs) and acknowledged.

Key Features:

• Zero Data Loss guarantee.

• Transactions cannot commit on the primary unless redo is safely stored on at least one
standby.

• Requires standby to be in SYNC and AFFIRM mode with SRLs configured.

• If standby becomes unavailable, the primary shuts down to preserve data integrity.

Page 5
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

Pros:

• Ensures 100% data consistency between primary and standby.

• Ideal for mission-critical systems like banking, financial trading, healthcare.

• Suitable for companies with zero tolerance for data loss.

Cons:

• Potential for primary database shutdown if standby isn’t reachable.

• Higher latency and commit wait time.

• Not suitable for unstable networks or high-latency links.

Use Case:

• Businesses that cannot afford any data loss under any scenario.

• Often combined with Far Sync Instances to minimize impact.

2. Maximum Availability Mode

This mode provides zero data loss like Maximum Protection but adds high availability. If the
standby is not available, the primary continues processing transactions, temporarily at the
cost of zero data loss.

Key Features:

• Attempts zero data loss as long as standby is reachable.

• Runs in SYNC + AFFIRM mode.

• If standby is unreachable, it automatically falls back to asynchronous redo transport,

avoiding downtime.

Pros:

• Best balance between protection and availability.

• Ensures data safety in most situations without impacting uptime.

• Commonly used in production enterprise workloads.

Page 6
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

Cons:

• Risk of minimal data loss if failover happens during the async window.

• Requires fast and reliable network for effective sync operations.

• Complexity in failover configurations.

Use Case:

• Businesses needing high availability with near-zero RPO (Recovery Point Objective).

• Ideal for cloud hybrid or multi-region DR setups.

3. Maximum Performance Mode

This is the default and most widely used mode. It emphasizes primary performance and
availability over data protection. Redo is sent to standby asynchronously, meaning the
primary doesn’t wait for acknowledgment.

Key Features:

• Redo is transmitted using ASYNC transport.

• Primary does not wait for standby confirmation—ensures maximum throughput.

• Some data loss is possible if the primary crashes before redo reaches standby.

Pros:

• Best primary performance — no commit delays.

• Ideal for long-distance disaster recovery, where network latency is high.

• Simple to configure and maintain.

Cons:

• Potential for data loss during sudden primary failure.

• Cannot be used when strict regulatory requirements mandate no data loss.

Page 7
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

Use Case:

• Companies prioritizing performance over protection.

• Suitable for development, QA, or reporting databases where some data loss is acceptable.

Page 8
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

Data Guard Architecture :-

Oracle Data Guard Architecture – Deep Dive

Oracle Data Guard architecture is a robust and intelligent high availability solution designed to provide
disaster recovery, data protection, and data availability across primary and standby database
environments. Let’s break down the architecture into clear components and data flow mechanics
without generic repetitions.

Page 9
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

1. Primary Database
This is the production database, where all user transactions and operations occur. It is fully
operational in read-write mode. All redo logs generated here are vital for keeping the standby
synchronized.

• Role: Source of truth

• Mode: Read/Write

• Generates redo for every transaction

The Data Guard setup constantly extracts redo from the online redo logs and sends it to the standby
database to maintain consistency.

2. Standby Database(s)
A standby is a copy of the primary database, maintained through continuous application of redo
data received from the primary. It can be:

• Physical Standby: Block-level replica, using Redo Apply.

• Logical Standby: SQL-level replica, using SQL Apply.

• Snapshot Standby: Temporary read-write standby created for testing with capability to revert
back.

• Far Sync Instance: A lightweight instance to relay redo to remote standby with near-zero data
loss.

• Active Data Guard: An extension to allow read-only access while redo is applied.

Standby databases are always in sync with the primary (either real-time or delayed) using continuous
redo shipping.

Page 10
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

3. Log Transport Services (LNS Process)

This service is responsible for sending redo data from the primary database to one or more standby
databases.

• Operates using SYNC (synchronous) or ASYNC (asynchronous) transport.

• Works with Log Writer (LGWR) or Archiver (ARCH) processes.

• Key parameters: LOG_ARCHIVE_DEST_n, SYNC/ASYNC, AFFIRM/NOAFFIRM,

NET_TIMEOUT

For example:

LOG_ARCHIVE_DEST_2='SERVICE=stdby SYNC AFFIRM

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stdby';

This mechanism ensures real-time or near-real-time transfer of critical redo information.

4. Redo Apply (MRP Process) – Physical Standby

Once the redo is received at the standby, Managed Recovery Process (MRP) reads from the
standby redo logs or archived logs and applies the changes to the standby datafiles at the block level.

• Highly efficient for performance and consistency

• Requires redo logs to be sequential and complete

• Runs in the background and maintains database in MOUNT mode (unless Active Data Guard
is enabled)

Command to start MRP:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Page 11
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

5. SQL Apply (Logical Standby)

For logical standby databases, redo is transformed into SQL statements and applied by SQL Apply
engine using LSP (Logical Standby Process).

• Enables reporting and DML on standby

• Allows data transformations and schema-level filtering

• Slightly more complex due to SQL-based replication

SQL Apply is more flexible but sensitive to data type changes and unsupported SQL features.

6. Standby Redo Logs (SRLs)

These are mandatory in SYNC mode. Standby redo logs temporarily store redo data as it arrives
from the primary, before applying it.

• Should be same size and number as primary redo logs (plus a few extra)

• Improve real-time apply capabilities

• Essential for real-time apply and zero data loss protection modes

Example creation:

ALTER DATABASE ADD STANDBY LOGFILE GROUP 10 ('/oradata/stdby/srl10.log') SIZE 500M;

7. Data Guard Broker (DGMGRL)

This is a management and automation framework to simplify configuration, monitoring, failover,
switchover, and recovery operations in a Data Guard environment.

• CLI: dgmgrl

• Automatically monitors health of the primary and standby roles

• Supports fast-start failover (FSFO)

• Maintains metadata in a repository for automated role transitions

Page 12
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

Example commands:

dgmgrl> CREATE CONFIGURATION 'DGConfig' AS PRIMARY DATABASE IS 'prim' CONNECT

IDENTIFIER IS 'prim';

dgmgrl> ADD DATABASE 'stdby' AS CONNECT IDENTIFIER IS 'stdby' MAINTAINED AS PHYSICAL;

8. Role Transitions – Switchover / Failover

• Switchover: Planned role reversal between primary and standby without data loss. Ideal
during maintenance.

• Failover: Unplanned transition due to failure of primary. May result in some data loss unless
synchronous redo was enabled.

Switchover:

DGMGRL> SWITCHOVER TO stdby;

Failover:

DGMGRL> FAILOVER TO stdby;

These transitions are handled smoothly using Data Guard Broker or manual SQL commands,
depending on configuration.

9. Protection Modes (Linked to Architecture)

Depending on business need, the log transport and apply services operate under:

• Maximum Protection

• Maximum Availability

• Maximum Performance

Each mode defines how redo is shipped and acknowledged, directly influencing architecture behavior.

Page 13
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

10. Monitoring Views and Queries

To track the health of Data Guard components, several dynamic performance views are available:

SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST;

SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;

SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;

These views help monitor redo transport, apply lag, and status of LNS, MRP, RFS, and other
processes.

Final Thoughts

Oracle Data Guard architecture is deeply engineered for resilient, consistent, and recoverable
enterprise data environments. Understanding the flow of redo, role of background processes, and
physical/logical separation of tasks is essential for any DBA managing high-availability
architectures.

Benefits of Oracle Data Guard

Oracle Data Guard is a robust solution for data protection and disaster recovery in Oracle databases.
It helps organizations maintain high availability and data integrity by creating and managing standby
databases that replicate the primary database. Below are the key benefits explained in detail:

--------------------------------

Page 14
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

1. Disaster Recovery
Oracle Data Guard provides an automated and reliable disaster recovery solution. In the event of a
catastrophic failure on the primary database — such as hardware failure, data corruption, or site loss
— the standby database can be activated to take over, ensuring business continuity.

Automatic failover (with Fast-Start Failover) can quickly promote a standby to primary without manual
intervention.Maintains an up-to-date copy of the primary database by continuously applying redo logs.
Protects against site failures when the standby is located in a geographically separate location. This
ensures minimal data loss and rapid recovery from disasters.

--------------------------------

2. High Availability
Data Guard increases overall system availability by allowing quick switching between primary and
standby databases.

Planned Maintenance: Enables switchover operations to shift the primary role to the standby database
without downtime for maintenance activities.

Unplanned Downtime: Failover functionality quickly transfers workload to the standby in case of
unexpected primary database failure.

Supports Automatic Gap Resolution to keep standby databases synchronized without manual
intervention.This minimizes database downtime and provides continuous service availability.

--------------------------------

Page 15
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

3. Efficient Offloading for Reporting

Data Guard standby databases can be opened in read-only mode (using Active Data Guard option),
allowing reporting and query workloads to run on the standby instead of the primary. Reduces the
performance impact on the primary database caused by heavy reporting or batch jobs. Standby
databases can be used for backup validation, reporting, and ad-hoc queries. Supports real-time query
of standby data while redo apply is ongoing, providing near real-time data access.This offloading
improves overall system performance and resource utilization.

--------------------------------

4. No Data Loss (Depending on Mode)

Data Guard supports multiple protection modes that balance performance and data safety:

Maximum Protection Mode: Guarantees zero data loss by ensuring transactions are committed on
both primary and standby before acknowledgment.

Maximum Availability Mode: Provides high protection with minimal impact on performance,
automatically failing over if the standby is unreachable.

Maximum Performance Mode: Focuses on performance, with redo data shipped asynchronously;
minor data loss is possible in failure scenarios.

This flexibility allows organizations to choose the right balance of performance and data protection.

--------------------------------

Page 16
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

5. Easy Role Transitions

Data Guard makes switching roles between primary and standby databases straightforward:

Switchover: Planned role reversal without data loss or downtime, useful for maintenance or load
balancing.

Failover: Unplanned role switch in response to a primary database failure to minimize downtime.

These operations are simple to execute, often automated, and ensure minimal disruption to business
operations.

--------------------------------

6. Automated Redo Transport and Apply

Data Guard automates the transmission and application of redo data from primary to standby:

Redo data (transaction logs) are continuously shipped to the standby database. Redo apply
processes keep the standby synchronized by applying changes in real-time or near real-time.
Supports network-efficient transport mechanisms, including compression and encryption.
Automatically handles network interruptions and gap resolution to maintain synchronization. This
reduces manual effort, errors, and administrative overhead in maintaining standby databases.

--------------------------------

Page 17
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

7. Reduces Downtime

By providing rapid failover and switchover capabilities, Data Guard dramatically reduces both planned
and unplanned downtime: Planned downtime for maintenance or upgrades can be scheduled with
minimal impact using role transitions. Unplanned outages due to hardware or software failures are
mitigated with fast failover options. Standby databases allow for quick recovery, minimizing business
disruption.This ensures high service levels and supports demanding uptime requirements.

Real-World Use Cases

1. Banks using Active Data Guard for reporting and HA.

2. E-commerce platforms for failover.

3. Government systems for zero-downtime DR.

Data warehousing companies using logical standby for transformation queries.

New Features in Oracle 19c Data Guard

New Features in Oracle 19c Data Guard

Oracle 19c is a long-term support release with many stability and performance improvements. It also
brings enhancements specifically in Data Guard, focusing on better availability, easier management,
and improved data protection. Below are the key new features introduced in Oracle 19c Data Guard:

Page 18
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

1. Automatic Block Repair Improvements

• Oracle 19c enhances the Automatic Block Repair feature to improve data corruption
handling in Data Guard environments.

• If a corrupted block is detected on the primary or standby database, Data Guard can
automatically repair it using a good copy from the other database.

• In 19c, automatic block repair now supports Logical Standby and Far Sync instances,
expanding protection coverage.

• This helps maintain data integrity with less manual intervention and reduces downtime caused
by block corruption.

2. Far Sync Instance Enhancements

• Far Sync instances are lightweight standby databases that receive redo from the primary and
forward it to one or more physical standby databases.

• Oracle 19c introduces better scalability and manageability for Far Sync.

• Multiple Far Sync instances can be used to improve availability across different geographic
locations.

• You can now configure redo transport timeout parameters for Far Sync, improving control
over redo transmission and network resilience.

• Far Sync instances help achieve zero data loss protection with minimal performance impact
on the primary database.

3. Automatic Gap Resolution Optimizations

• Data Guard improves how it detects and resolves redo gaps between primary and standby
databases.

• Oracle 19c introduces faster gap detection and resolution algorithms, which minimizes
replication lag.

• This reduces the chances of the standby falling behind and needing manual catch-up
interventions.

• Enhances overall synchronization reliability and reduces administrative overhead.

Page 19
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

4. Faster Switchover and Failover Operations

• Switchover and failover processes in Data Guard 19c are optimized for speed and automation.

• Oracle 19c supports parallel execution of various role transition steps, reducing the total
downtime during these operations.

• Improved automation with better integration with Oracle Restart and Oracle Grid
Infrastructure.

• Fast-Start Failover now includes improved monitoring and alerting for quicker detection and
resolution of failover conditions.

5. Support for Oracle RAC One Node on Standby

• Oracle 19c Data Guard supports running the standby database as an Oracle RAC One Node
database.

• This allows the standby to benefit from RAC's high availability features, even though it is a
single-node cluster.

• Improves standby database availability and provides easier failover to RAC environments.

• Enables better resource utilization and management of standby databases in clustered

environments.

6. Integration with Oracle Cloud Infrastructure (OCI)

• Oracle 19c enhances Data Guard integration with Oracle Cloud, making it easier to deploy
standby databases in OCI.

• Supports Data Guard Broker management of cloud-based standby databases.

• Simplifies hybrid cloud disaster recovery strategies by allowing seamless failover and
switchover between on-premises and cloud databases.

• Enables cloud-based backups and restores as part of the Data Guard environment.

Page 20
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

7. Improved Data Guard Broker Features

• Oracle 19c Data Guard Broker gains enhanced capabilities for managing Data Guard
configurations.

• New command-line interface improvements and scripting options make automation easier.

• Improved support for rolling upgrades and patching of standby databases with minimal
downtime.

• Better monitoring and alerting features for rapid issue identification and resolution.

8. Enhanced Security and Encryption

• Oracle 19c improves redo transport encryption between primary and standby databases.

• Supports stronger encryption algorithms and better key management.

• Helps meet stricter compliance requirements for data in transit.

• Enhances overall security posture of Data Guard environments.

Page 21
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

Monitoring and Maintenance

Maintaining a healthy Oracle Data Guard configuration is crucial to ensure continuous data protection,
disaster recovery readiness, and high availability. Oracle provides several tools and views to monitor
the configuration effectively and perform routine maintenance.

Let’s explore the key aspects of monitoring and maintaining a Data Guard environment:

1. Use DGMGRL for Managing Data Guard

DGMGRL (Data Guard Manager Command-Line) is Oracle’s primary interface for configuring,
managing, and monitoring a Data Guard setup using the Data Guard Broker.

• Enables centralized management of both primary and standby databases.

• Simplifies tasks like switchover, failover, adding/removing standby databases, and

checking configuration health.

• Useful commands:

2. Monitor Log Gaps and Apply Lag

Monitoring redo log gaps and apply lag is critical to ensure standby databases remain synchronized
with the primary.

• Transport Lag: Time difference between the current SCN on the primary and the last SCN
received by the standby.

• Apply Lag: Time delay in applying the received redo logs to the standby database.

Page 22
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

Use these queries:

-- Check transport and apply lag

SELECT DEST_ID, STATUS, ERROR, TRANSMIT_MODE, APPLY_MODE,

TRANSPORT_LAG, APPLY_LAG

FROM V$DATAGUARD_STATS;

-- Redo log gap detection

SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE#

FROM V$ARCHIVE_GAP;

Why it matters:

• Large lags can lead to increased recovery time during failover.

• Gaps may indicate network issues, configuration problems, or standby performance

bottlenecks.

3. Check Configuration Status Using V$ Views and Broker Commands

Oracle provides several dynamic performance views (v$ views) to monitor Data Guard status in
real time.

Key views include:

• V$DATAGUARD_STATS – Lag metrics, redo transport/apply status.

• V$ARCHIVE_DEST_STATUS – Redo log transmission status to all destinations.

• V$MANAGED_STANDBY – Shows background processes like RFS, MRP, and their statuses.

• V$DATABASE – Confirms database role (PRIMARY, STANDBY, etc.).

• V$STANDBY_EVENT_HISTOGRAM – Helps analyze redo apply delays.

Page 23
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

DGMGRL COMMANDS--

4. Schedule Periodic Health Checks

Routine health checks help maintain a robust and resilient Data Guard setup. Best practices:
Validate Data Guard Configuration periodically using:

bash

DGMGRL> validate configuration;

DGMGRL> validate database verbose 'DB_UNIQUE_NAME';

Check MRP status:

SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE

PROCESS='MRP0';

Automate alerts for transport/apply lag and redo gap thresholds using Oracle Enterprise
Manager (OEM), scripts, or third-party tools. Schedule backups from the standby to reduce
load on the primary. Test failover readiness regularly using Fast-Start Failover simulations or
manual switchovers in non-production environments.

Page 24
Oracle Data Guard - A Complete Technical Guide – By Brijesh Mehra

Health Check Scripts: Create shell or SQL scripts to log and email key metrics:

• Transport and apply lag

• Archive gap
• MRP/RFS process status
• Disk space in archive destinations

Summary
Proper monitoring and maintenance of Oracle Data Guard ensures your standby systems are
always ready to take over in a disaster. Leveraging tools like DGMGRL, dynamic views (v$), and
scheduled health checks allows you to detect and resolve issues before they impact your business.
Data Guard is not just a set-and-forget technology—it requires active monitoring to truly guarantee
high availability and zero data loss.

Page 25