Oracle Data Guard Master Guide

Oracle Data Guard

Master Guide
Oracle Database 19c - Fundamentals, Architecture, Installation Lab,
Administration, RAC/ASM, Troubleshooting, and Interview
Preparation

Professional Training and Operations Handbook

Prepared for database administrators, architects, support engineers, and interview

candidates

Oracle Data Guard Master Guide | Page 1

 Oracle Data Guard Master Guide
Automatic Table of Contents
Right-click and choose Update Field in Word to refresh the automatic table of contents.

Oracle Data Guard Master Guide | Page 2

 Oracle Data Guard Master Guide

How to Use This Guide

This guide explains the concept, design, implementation, and operation of Oracle Data Guard
19c. It is written for practical learning: every major concept is followed by operational notes,
validation checks, and interview-style recall points. Commands are representative and must be
adjusted to match the actual database names, file paths, services, storage layout, and
organizational standards.
 For architecture learning, read Parts 1, 4, and 5 first.
 For implementation practice, follow Part 6 in a non-production lab.
 For operations, monitoring, and troubleshooting, keep Parts 7 and 8 as runbook references.
 For enterprise designs, review Part 9 before implementing Data Guard with RAC and ASM.
 For interviews, use Part 10 as a revision bank and expand each answer with command
examples.

Symbol Meaning
Current production database that accepts application
Primary database
writes.
Synchronized copy that receives redo from the
Standby database
primary.
RPO Maximum acceptable data loss window.
RTO Maximum acceptable recovery time after failure.
Data Guard management framework controlled with
Broker
DGMGRL or Cloud Control.

Oracle Data Guard Master Guide | Page 3

 Oracle Data Guard Master Guide

Part 1: Oracle Data Guard Fundamentals and Architecture

Chapter objective: understand the subject deeply enough to design, implement, monitor, and
explain it in production and interview contexts. Each section includes practical DBA notes and
validation thinking.

Figure 1. Oracle Data Guard 19c reference architecture.

Business Problem Solved by Data Guard

Oracle Data Guard addresses two related risks: loss of database availability and loss of
protected data. A production database can fail because of server loss, storage failure, network
partition, operating system crash, logical corruption, planned maintenance, or site disaster.
Data Guard reduces the impact by maintaining standby databases that can take over production
processing.
A Data Guard design should begin with the business requirement, not with commands. First
define the acceptable RPO and RTO. Then decide the protection mode, standby type, network
design, apply method, monitoring threshold, and role transition procedure.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

Oracle Data Guard Master Guide | Page 4

 Oracle Data Guard Master Guide
SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Primary and Standby Roles

A Data Guard configuration contains one primary database and one or more standby databases.
The primary is the database currently open for read-write application workload. The standby
receives redo from the primary and either applies it using media recovery, applies it as SQL
transformations, or stores it temporarily for later use depending on its standby type.
The terms primary and standby describe roles, not fixed servers. During a switchover or failover,
the former standby can become the new primary. This role mobility is the foundation of planned
maintenance and disaster recovery.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Standby Database Types

Physical standby is the most common design. It is block-for-block equivalent to the primary and
uses Redo Apply. Logical standby uses SQL Apply and maintains a logical representation,
enabling more selective reporting and transformations but with more restrictions. Snapshot
standby is a temporary read-write version of a physical standby used for testing; redo is
received but not applied until conversion back.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Oracle Data Guard Master Guide | Page 5

 Oracle Data Guard Master Guide
Data Guard Processes and Components
Important components include LGWR, ARCH, LNS, RFS, MRP, SQL Apply processes, standby redo
logs, archived redo logs, FAL gap resolution, listeners, Oracle Net services, password files, and
Data Guard Broker. In a healthy system, redo is generated, transported, received, and applied
without gaps beyond defined thresholds.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Architecture Design Principles

Separate failure domains, protect network paths, keep naming predictable, use standby redo
logs, enable FORCE LOGGING unless there is a documented exception, implement monitoring
before go-live, and rehearse switchover/failover. A clean architecture is easier to operate during
an outage when pressure is high.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Component Purpose Typical Validation

Primary Database Production source of redo DATABASE_ROLE=PRIMARY
Block-level replica using Redo
Physical Standby MRP running, apply lag acceptable
Apply
SQL Apply active, unsupported
Logical Standby SQL Apply logical replica
objects reviewed
Temporary read-write testing Converted back to physical after
Snapshot Standby
standby test
SHOW CONFIGURATION returns
Broker Centralized management
SUCCESS

Oracle Data Guard Master Guide | Page 6

 Oracle Data Guard Master Guide

Oracle Data Guard Master Guide | Page 7

 Oracle Data Guard Master Guide

Part 2: Physical Standby

Chapter objective: understand the subject deeply enough to design, implement, monitor, and
explain it in production and interview contexts. Each section includes practical DBA notes and
validation thinking.

Physical Standby Overview

A physical standby database is an exact physical replica of the primary database. It is
maintained by Redo Apply, which uses Oracle media recovery mechanisms to apply redo in
block format. This makes it highly suitable for disaster recovery and high availability because
the standby remains structurally identical to the primary.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Prerequisites for Physical Standby

The primary database must be in ARCHIVELOG mode. FORCE LOGGING should be enabled to
prevent unrecoverable direct-path operations from creating data divergence. Password files,
listeners, TNS aliases, initialization parameters, and storage locations must be consistent and
tested before starting the duplicate operation.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Oracle Data Guard Master Guide | Page 8

 Oracle Data Guard Master Guide
Standby Redo Logs
Standby redo logs allow real-time receipt of redo and support real-time apply. A practical rule is
to create standby redo log groups for each redo thread, with one more group than the number
of online redo log groups per thread, and with matching or greater size. In RAC, every thread
requires appropriate standby redo logs.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Creating the Physical Standby

Common approaches include RMAN active duplicate, backup-based duplicate, DBCA standby
creation, and cloud-control assisted creation. RMAN active duplicate is convenient in labs
because it copies the database over the network while connected to the active primary.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Managed Recovery
Managed recovery applies received redo on the standby. Real-time apply uses current standby
redo log contents rather than waiting for archived log completion. Recovery can be started,
stopped, monitored, and validated through SQL views or broker commands.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.

Oracle Data Guard Master Guide | Page 9

 Oracle Data Guard Master Guide
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Oracle Data Guard Master Guide | Page 10

 Oracle Data Guard Master Guide

Part 3: Logical Standby and Snapshot Standby

Chapter objective: understand the subject deeply enough to design, implement, monitor, and
explain it in production and interview contexts. Each section includes practical DBA notes and
validation thinking.

Logical Standby Concept

Logical standby transforms redo into SQL statements and applies logical changes. This allows
the standby to be open read-write for objects not maintained by SQL Apply and read-only or
reporting use for maintained objects. It is powerful but has more datatype and feature
restrictions than physical standby.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Logical Standby Use Cases

Typical use cases include reporting with structural changes, rolling upgrades in specific
scenarios, selective replication, and workloads where logical access is more important than
block-level identity. Because SQL Apply has restrictions, every application schema must be
assessed before design approval.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Oracle Data Guard Master Guide | Page 11

 Oracle Data Guard Master Guide
Creating a Logical Standby
A logical standby is commonly created by first creating a physical standby, ensuring it is
synchronized, preparing dictionary information, stopping Redo Apply, and converting to logical
standby. After conversion, SQL Apply is started and monitored through logical standby views.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Snapshot Standby Concept

A snapshot standby is a physical standby temporarily opened read-write for testing or reporting
experiments. It continues to receive redo from the primary but does not apply it while in
snapshot mode. When converted back to physical standby, local changes are discarded and
accumulated redo is applied.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Risks and Controls

Logical standby requires compatibility checks. Snapshot standby requires careful scheduling
because it increases apply lag while in snapshot mode. Never confuse snapshot standby with a
backup replacement; it is a temporary testing mode for a standby database.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.

Oracle Data Guard Master Guide | Page 12

 Oracle Data Guard Master Guide
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Oracle Data Guard Master Guide | Page 13

 Oracle Data Guard Master Guide

Part 4: Active Data Guard and Redo Transport Services

Chapter objective: understand the subject deeply enough to design, implement, monitor, and
explain it in production and interview contexts. Each section includes practical DBA notes and
validation thinking.

Figure 2. Redo transport and apply flow.

Active Data Guard Overview

Active Data Guard extends physical standby usage by allowing read-only workload while redo
apply continues. It is commonly used for reporting, backups, query offload, automatic block
repair, and improving return on DR investment. Licensing requirements must be checked before
enabling production use.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Real-Time Query
Real-time query allows the standby to be open read-only while redo is being applied. This
enables reports to run against near-current data without using primary CPU and I/O. Application

Oracle Data Guard Master Guide | Page 14

 Oracle Data Guard Master Guide
routing should use dedicated services so read-only sessions go to standby and write sessions
stay on primary.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Redo Transport Services

Redo transport services automate the transfer of redo from primary to standby destinations.
Transport can be synchronous or asynchronous and can use LGWR or archived redo depending
on configuration. Service names, network reliability, and standby redo logs strongly influence
transport health.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

SYNC, ASYNC, AFFIRM and NOAFFIRM

SYNC requires remote acknowledgement before commit completion. ASYNC does not wait for
remote acknowledgement and favors primary throughput. AFFIRM confirms redo is written to
disk at the destination, whereas NOAFFIRM acknowledges without forcing disk write in the same
way. The selected combination must match RPO/RTO and latency realities.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.

Oracle Data Guard Master Guide | Page 15

 Oracle Data Guard Master Guide
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Far Sync
Far Sync is a lightweight instance that receives redo synchronously from the primary and
forwards it asynchronously to a distant standby. It is useful where zero or near-zero data loss is
desired without forcing the primary to wait for long-distance standby latency.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Oracle Data Guard Master Guide | Page 16

 Oracle Data Guard Master Guide

Part 5: Protection Modes and Data Guard Broker

Chapter objective: understand the subject deeply enough to design, implement, monitor, and
explain it in production and interview contexts. Each section includes practical DBA notes and
validation thinking.

Protection Mode Overview

Data Guard protection modes express the trade-off between data protection and primary
availability. Maximum Protection prioritizes zero data loss even if the primary must shut down.
Maximum Availability aims for zero data loss while allowing the primary to continue if standby
connectivity is temporarily lost. Maximum Performance favors throughput and availability with
possible data loss.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Choosing a Protection Mode

Start with business RPO. If no data loss is acceptable and infrastructure supports low-latency
synchronous transport, maximum availability or maximum protection may be considered. If
throughput and distance make synchronous transport impractical, maximum performance is
commonly used with careful lag monitoring.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Oracle Data Guard Master Guide | Page 17

 Oracle Data Guard Master Guide
Data Guard Broker
Data Guard Broker provides a management layer for configuration, monitoring, switchover,
failover, reinstatement, and FSFO. It can be operated with DGMGRL or Enterprise Manager.
Broker does not remove the need to understand the underlying database, network, and redo
behavior, but it simplifies safe operations.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Broker Configuration Lifecycle

The normal flow is: enable DG_BROKER_START, create configuration, add primary and standby
database objects, set properties, enable configuration, validate each database, and use broker
for role transitions. Configuration files must be protected and consistent.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Fast-Start Failover
Fast-start failover allows the broker and observer to automatically fail over to a target standby
when configured conditions are met. Observer placement is critical. Observe-only mode is useful
for testing behavior before automatic failover is allowed.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.

Oracle Data Guard Master Guide | Page 18

 Oracle Data Guard Master Guide
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Primary Availability
Protection Mode Redo Transport Data Loss Target
Behavior
Primary may stop if
Synchronous with strict required standby
Maximum Protection Zero data loss
zero-loss behavior acknowledgement is
unavailable
Primary can continue if
Synchronous while Zero data loss when
Maximum Availability standby temporarily
possible synchronized
unavailable
Primary throughput and
Maximum Performance Asynchronous Possible data loss
availability prioritized

Oracle Data Guard Master Guide | Page 19

 Oracle Data Guard Master Guide

Part 6: Complete Installation Lab - Oracle Linux and Oracle 19c

Chapter objective: understand the subject deeply enough to design, implement, monitor, and
explain it in production and interview contexts. Each section includes practical DBA notes and
validation thinking.

Figure 4. Complete installation lab topology.

Lab Objective and Assumptions

This lab builds a two-node physical standby configuration using Oracle Linux and Oracle
Database 19c. It is intended for non-production training. The sample names are primdb and
stbydb. Replace hostnames, paths, DB names, and service names with your own values.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Operating System Preparation

Prepare both servers with required packages, kernel parameters, oracle user, groups,
directories, network resolution, firewall rules, time synchronization, and storage capacity.
Oracle Data Guard Master Guide | Page 20
 Oracle Data Guard Master Guide
Ensure the same Oracle software release and patch level on both nodes unless your lab is
specifically testing patch behavior.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Primary Database Preparation

Enable ARCHIVELOG, enable FORCE LOGGING, configure password file, create standby redo
logs, set required initialization parameters, and verify listener/TNS connectivity. Take a backup
or use RMAN active duplicate depending on lab method.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Standby Creation with RMAN

Use RMAN DUPLICATE FROM ACTIVE DATABASE when network bandwidth and privileges are
available. Ensure auxiliary instance starts in NOMOUNT and has correct pfile/spfile parameters.
After duplicate, mount standby and start managed recovery.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Oracle Data Guard Master Guide | Page 21

 Oracle Data Guard Master Guide
Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Broker Enablement and Validation

Enable DG_BROKER_START on both databases, create broker configuration, add the standby,
enable the configuration, validate both databases, and perform a controlled test such as log
switch and apply lag check.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Oracle Data Guard Master Guide | Page 22

 Oracle Data Guard Master Guide

Part 7: RMAN, Monitoring and Administration

Chapter objective: understand the subject deeply enough to design, implement, monitor, and
explain it in production and interview contexts. Each section includes practical DBA notes and
validation thinking.

RMAN in Data Guard

RMAN can back up primary and standby databases. Backups taken on a physical standby can be
used for primary recovery in many designs because of physical equivalence. Configure retention
policy, archivelog deletion policy, control file autobackup, and backup location standards
carefully.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Backup Strategy
The backup design must specify where backups run, which role owns catalog registration,
whether backups go to disk or media manager, how archived redo is retained, and how restore
is tested. A standby database is not a replacement for backups because logical mistakes and
some corruptions can propagate.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Oracle Data Guard Master Guide | Page 23

 Oracle Data Guard Master Guide
Monitoring Views
Core views include V$DATABASE, V$ARCHIVE_DEST_STATUS, V$DATAGUARD_STATS,
V$MANAGED_STANDBY, V$ARCHIVED_LOG, V$LOG_HISTORY, V$STANDBY_LOG,
V$DATAGUARD_PROCESS, and broker command output. Monitoring must cover both transport
and apply, not just database open status.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Daily Administration Checklist

Review broker configuration, check lag, confirm MRP/SQL Apply status, validate archivelog
shipping, verify backups, check alert logs, review gap resolution, ensure services are on the
correct role, and test that operational contacts know the runbook.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Capacity and Performance Management

Redo generation rate determines network and standby I/O needs. Monitor peak redo, apply rate,
CPU, I/O latency, FRA usage, and archive destination errors. Capacity planning must include
maintenance windows and catch-up after network outages.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.

Oracle Data Guard Master Guide | Page 24

 Oracle Data Guard Master Guide
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

View / Tool Primary Use Question It Answers

V$DATAGUARD_STATS Lag metrics How far behind is the standby?
V$MANAGED_STANDBY / Are redo receive/apply processes
Apply/receive process status
V$DATAGUARD_PROCESS running?
V$ARCHIVE_DEST_STATUS Transport destination status Is shipping successful?
Is the broker configuration
DGMGRL SHOW CONFIGURATION Broker health
healthy?
Alert log Detailed errors and state changes What changed and when?

Oracle Data Guard Master Guide | Page 25

 Oracle Data Guard Master Guide

Part 8: Switchover, Failover, FSFO and Troubleshooting

Chapter objective: understand the subject deeply enough to design, implement, monitor, and
explain it in production and interview contexts. Each section includes practical DBA notes and
validation thinking.

Figure 3. Switchover, failover and reinstate lifecycle.

Figure 6. Troubleshooting decision map.

Switchover Procedure
A switchover is a planned role reversal. It should be done only when the configuration is healthy,
standby is synchronized, application owners are ready, and rollback/restore plans are known.
Broker simplifies the command sequence but validation remains mandatory.
Oracle Data Guard Master Guide | Page 26
 Oracle Data Guard Master Guide
Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Failover Procedure
A failover is used when the primary is unavailable or cannot continue service. Before failover,
determine whether the original primary is truly lost, estimate potential data loss, choose the
target standby, communicate impact, and preserve evidence for root-cause analysis.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Fast-Start Failover Operations

FSFO automates failover based on broker configuration and observer decisions. It requires
careful target selection, thresholds, observer placement, and repeated testing. Use observe-only
mode before production enablement.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

Oracle Data Guard Master Guide | Page 27

 Oracle Data Guard Master Guide
SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Troubleshooting Method
Troubleshooting begins with symptom classification: transport issue, apply issue, broker issue,
network issue, storage issue, parameter mismatch, or application service routing issue. Always
collect broker output, alert logs, relevant dynamic view output, and recent change history.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Common Incidents
Common incidents include ORA- errors in archive destinations, transport lag due to network
bottleneck, apply lag due to I/O or long transactions, archive gaps, missing standby redo logs,
listener/TNS mismatch, standby file creation failure, and broker warnings after manual changes.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Oracle Data Guard Master Guide | Page 28

 Oracle Data Guard Master Guide

Part 9: RAC, ASM and Data Guard

Chapter objective: understand the subject deeply enough to design, implement, monitor, and
explain it in production and interview contexts. Each section includes practical DBA notes and
validation thinking.

Figure 5. RAC, ASM and Data Guard topology.

RAC Data Guard Concepts

RAC adds multiple instances and redo threads. Data Guard must handle redo from every
enabled thread. Services should be role-based so applications connect to the correct primary or
read-only standby service after role transitions.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Oracle Data Guard Master Guide | Page 29

 Oracle Data Guard Master Guide
ASM Considerations
ASM simplifies storage management using disk groups such as +DATA and +FRA. Data Guard
naming can use Oracle Managed Files to reduce manual file-name conversion. File creation and
storage placement must be tested during datafile addition and role transition scenarios.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Standby Redo Logs in RAC

Each primary redo thread requires corresponding standby redo logs. Missing or undersized
standby redo logs are a common RAC Data Guard design mistake. Verify V$STANDBY_LOG
across all threads before go-live.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Broker with RAC

Broker understands RAC configurations and can manage role transitions, but instance/service
configuration must be aligned. Ensure static listener entries where required, broker properties
are set correctly, and Clusterware-managed services follow roles.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
Oracle Data Guard Master Guide | Page 30
 Oracle Data Guard Master Guide
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Patch and Maintenance Design

RAC plus Data Guard enables sophisticated maintenance patterns, but complexity increases.
Plan patch sequence, database services, observer behavior, backup windows, and rollback. Test
with the same topology as production whenever possible.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Oracle Data Guard Master Guide | Page 31

 Oracle Data Guard Master Guide

Part 10: Best Practices and Interview Questions

Chapter objective: understand the subject deeply enough to design, implement, monitor, and
explain it in production and interview contexts. Each section includes practical DBA notes and
validation thinking.

Figure 1. Oracle Data Guard 19c reference architecture.

Design Best Practices

Choose the simplest architecture that meets RPO/RTO. Use broker unless there is a strong
operational reason not to. Keep primary and standby patch levels aligned. Use standby redo
logs. Use role-based services. Monitor lag and archive destination errors. Document every role
transition procedure.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Oracle Data Guard Master Guide | Page 32

 Oracle Data Guard Master Guide
Security Best Practices
Protect SYS and broker credentials, secure Oracle Net, restrict administrative access, rotate
passwords according to policy, audit privileged operations, and avoid exposing listener
endpoints broadly. Data Guard protects availability, but it must still follow database security
principles.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Operational Best Practices

Run regular DR drills. Update runbooks after every drill. Track actual RTO/RPO, not just design
targets. Keep backups independent from standby. Monitor FRA space aggressively. Train
multiple DBAs so failover knowledge is not held by one person.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Interview Preparation Strategy

For interviews, explain concepts first, then commands, then validation. Strong answers usually
include a why, a command or view, and a production caution. For example: explain switchover,
show DGMGRL SWITCHOVER, and mention pre-checks using VALIDATE DATABASE.

Operational Notes
 Confirm the requirement before changing configuration. In Data Guard, a technically valid
command can still be operationally wrong if it violates the RPO/RTO or maintenance plan.

Oracle Data Guard Master Guide | Page 33

 Oracle Data Guard Master Guide
 Always capture pre-change evidence: database role, open mode, protection mode,
switchover status, transport lag, apply lag, and broker status.
 Do not rely on a single check. Validate through broker output, dynamic performance views,
alert logs, and an end-to-end redo apply test.

Key Checks
SHOW CONFIGURATION VERBOSE;

SELECT database_role, open_mode, protection_mode FROM v$database;

SELECT name, value, unit FROM v$dataguard_stats;

SELECT dest_id, status, error FROM v$archive_dest_status WHERE status <> 'INACTIVE';

Oracle Data Guard Master Guide | Page 34

 Oracle Data Guard Master Guide

Appendix A: Command Reference

Primary preparation
-- Enable archiving and force logging (maintenance window recommended)
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
ALTER DATABASE FORCE LOGGING;

-- Check role and archivelog status

ARCHIVE LOG LIST;
SELECT force_logging FROM v$database;

Standby redo logs

-- Example only; size must match online redo log design
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 11 SIZE 1024M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 12 SIZE 1024M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 13 SIZE 1024M;

SELECT thread#, group#, bytes/1024/1024 AS mb, status FROM v$standby_log;

RMAN active duplicate

rman TARGET sys/password@primdb AUXILIARY sys/password@stbydb

DUPLICATE TARGET DATABASE FOR STANDBY

FROM ACTIVE DATABASE
DORECOVER
SPFILE
SET DB_UNIQUE_NAME='stbydb'
SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(primdb,stbydb)'
SET FAL_SERVER='primdb'
NOFILENAMECHECK;

Managed recovery
-- Start real-time apply
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

-- Stop managed recovery

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

DGMGRL broker setup

DGMGRL> CREATE CONFIGURATION dg_config AS
PRIMARY DATABASE IS primdb
CONNECT IDENTIFIER IS primdb;

DGMGRL> ADD DATABASE stbydb AS

CONNECT IDENTIFIER IS stbydb
MAINTAINED AS PHYSICAL;

DGMGRL> ENABLE CONFIGURATION;

DGMGRL> SHOW CONFIGURATION;
DGMGRL> VALIDATE DATABASE primdb;
DGMGRL> VALIDATE DATABASE stbydb;

Oracle Data Guard Master Guide | Page 35

 Oracle Data Guard Master Guide
Switchover and failover
DGMGRL> VALIDATE DATABASE primdb;
DGMGRL> VALIDATE DATABASE stbydb;
DGMGRL> SWITCHOVER TO stbydb;

-- Emergency only; confirm business approval and target standby first

DGMGRL> FAILOVER TO stbydb;

Oracle Data Guard Master Guide | Page 36

 Oracle Data Guard Master Guide

Glossary
Term Definition
Licensed option that allows a physical standby to be
Active Data Guard open read-only while redo apply continues, plus
related features such as automatic block repair.
Delay between redo generated on the primary and
Apply Lag
redo applied on the standby.
Oracle Data Guard management framework used
Broker
through DGMGRL or Enterprise Manager.
Unplanned role transition when the primary is
Failover
unavailable and a standby is promoted.
Lightweight Data Guard destination that receives
Far Sync
redo from primary and forwards it to standby.
Fast-Start Failover; broker-managed automatic
FSFO
failover using observer monitoring.
Logical Standby Standby database maintained through SQL Apply.
Managed Recovery Process that applies redo on a
MRP
physical standby.
Block-for-block copy of primary database maintained
Physical Standby
by Redo Apply.
Remote File Server process that receives redo on the
RFS
standby.
Recovery Point Objective; maximum acceptable data
RPO
loss.
Recovery Time Objective; maximum acceptable
RTO
recovery duration.
Physical standby temporarily opened read-write, then
Snapshot Standby
converted back with local changes discarded.
Redo log on standby used to receive redo in real
Standby Redo Log
time.
Switchover Planned role transition between primary and standby.

Oracle Data Guard Master Guide | Page 37

 Oracle Data Guard Master Guide

Part 10B: 220 Interview Questions with Short Answers

Use these questions for revision. For senior interviews, expand each answer with a command,
dynamic view, risk, and production example.

Fundamentals
1. What is Oracle Data Guard?
Answer: It is Oracle database HA/DR technology that maintains standby databases by
transporting and applying redo from a primary database.

2. What is the difference between primary and standby role?

Answer: Primary accepts read-write production workload; standby receives redo and can
become primary during role transition.

3. Why is FORCE LOGGING important?

Answer: It reduces risk of unrecoverable operations bypassing redo and causing standby
divergence.

4. What is a standby redo log?

Answer: A redo log on the standby used to receive redo in real time, supporting real-time apply
and faster transitions.

5. What is apply lag?

Answer: The delay between redo generation on primary and redo application on standby.

6. What is transport lag?

Answer: The delay between redo generation on primary and redo receipt on standby.

7. What is Data Guard Broker?

Answer: A management framework for monitoring and operating Data Guard configurations
using DGMGRL or Enterprise Manager.

8. What is switchover?
Answer: A planned role reversal between primary and standby when both are available and
synchronized.

9. What is failover?
Answer: An unplanned promotion of a standby to primary when the original primary is
unavailable.

10. What is FSFO?

Answer: Fast-Start Failover automates failover through broker and observer when configured
conditions are met.

11. In a fundamentals scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

Oracle Data Guard Master Guide | Page 38

 Oracle Data Guard Master Guide
12. In a fundamentals scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

13. In a fundamentals scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

14. In a fundamentals scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

15. In a fundamentals scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

16. In a fundamentals scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

17. In a fundamentals scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

18. In a fundamentals scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

Architecture
19. What is failover?
Answer: An unplanned promotion of a standby to primary when the original primary is
unavailable.

20. What is FSFO?

Answer: Fast-Start Failover automates failover through broker and observer when configured
conditions are met.

21. What is Oracle Data Guard?

Answer: It is Oracle database HA/DR technology that maintains standby databases by
transporting and applying redo from a primary database.

22. What is the difference between primary and standby role?

Answer: Primary accepts read-write production workload; standby receives redo and can
become primary during role transition.

23. Why is FORCE LOGGING important?

Answer: It reduces risk of unrecoverable operations bypassing redo and causing standby
divergence.

Oracle Data Guard Master Guide | Page 39

 Oracle Data Guard Master Guide
24. What is a standby redo log?
Answer: A redo log on the standby used to receive redo in real time, supporting real-time apply
and faster transitions.

25. What is apply lag?

Answer: The delay between redo generation on primary and redo application on standby.

26. What is transport lag?

Answer: The delay between redo generation on primary and redo receipt on standby.

27. What is Data Guard Broker?

Answer: A management framework for monitoring and operating Data Guard configurations
using DGMGRL or Enterprise Manager.

28. What is switchover?

Answer: A planned role reversal between primary and standby when both are available and
synchronized.

29. In a architecture scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

30. In a architecture scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

31. In a architecture scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

32. In a architecture scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

33. In a architecture scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

34. In a architecture scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

35. In a architecture scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

36. In a architecture scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.
Oracle Data Guard Master Guide | Page 40
 Oracle Data Guard Master Guide
Physical Standby
37. What is Data Guard Broker?
Answer: A management framework for monitoring and operating Data Guard configurations
using DGMGRL or Enterprise Manager.

38. What is switchover?

Answer: A planned role reversal between primary and standby when both are available and
synchronized.

39. What is failover?

Answer: An unplanned promotion of a standby to primary when the original primary is
unavailable.

40. What is FSFO?

Answer: Fast-Start Failover automates failover through broker and observer when configured
conditions are met.

41. What is Oracle Data Guard?

Answer: It is Oracle database HA/DR technology that maintains standby databases by
transporting and applying redo from a primary database.

42. What is the difference between primary and standby role?

Answer: Primary accepts read-write production workload; standby receives redo and can
become primary during role transition.

43. Why is FORCE LOGGING important?

Answer: It reduces risk of unrecoverable operations bypassing redo and causing standby
divergence.

44. What is a standby redo log?

Answer: A redo log on the standby used to receive redo in real time, supporting real-time apply
and faster transitions.

45. What is apply lag?

Answer: The delay between redo generation on primary and redo application on standby.

46. What is transport lag?

Answer: The delay between redo generation on primary and redo receipt on standby.

47. In a physical standby scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

48. In a physical standby scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

49. In a physical standby scenario, how would you validate and troubleshoot Data Guard health?

Oracle Data Guard Master Guide | Page 41

 Oracle Data Guard Master Guide
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

50. In a physical standby scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

51. In a physical standby scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

52. In a physical standby scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

53. In a physical standby scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

54. In a physical standby scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

Logical and Snapshot Standby

55. What is apply lag?
Answer: The delay between redo generation on primary and redo application on standby.

56. What is transport lag?

Answer: The delay between redo generation on primary and redo receipt on standby.

57. What is Data Guard Broker?

Answer: A management framework for monitoring and operating Data Guard configurations
using DGMGRL or Enterprise Manager.

58. What is switchover?

Answer: A planned role reversal between primary and standby when both are available and
synchronized.

59. What is failover?

Answer: An unplanned promotion of a standby to primary when the original primary is
unavailable.

60. What is FSFO?

Answer: Fast-Start Failover automates failover through broker and observer when configured
conditions are met.

61. What is Oracle Data Guard?

Answer: It is Oracle database HA/DR technology that maintains standby databases by
transporting and applying redo from a primary database.
Oracle Data Guard Master Guide | Page 42
 Oracle Data Guard Master Guide
62. What is the difference between primary and standby role?
Answer: Primary accepts read-write production workload; standby receives redo and can
become primary during role transition.

63. Why is FORCE LOGGING important?

Answer: It reduces risk of unrecoverable operations bypassing redo and causing standby
divergence.

64. What is a standby redo log?

Answer: A redo log on the standby used to receive redo in real time, supporting real-time apply
and faster transitions.

65. In a logical and snapshot standby scenario, how would you validate and troubleshoot Data
Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

66. In a logical and snapshot standby scenario, how would you validate and troubleshoot Data
Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

67. In a logical and snapshot standby scenario, how would you validate and troubleshoot Data
Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

68. In a logical and snapshot standby scenario, how would you validate and troubleshoot Data
Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

69. In a logical and snapshot standby scenario, how would you validate and troubleshoot Data
Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

70. In a logical and snapshot standby scenario, how would you validate and troubleshoot Data
Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

71. In a logical and snapshot standby scenario, how would you validate and troubleshoot Data
Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

72. In a logical and snapshot standby scenario, how would you validate and troubleshoot Data
Guard health?

Oracle Data Guard Master Guide | Page 43

 Oracle Data Guard Master Guide
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

Redo Transport
73. Why is FORCE LOGGING important?
Answer: It reduces risk of unrecoverable operations bypassing redo and causing standby
divergence.

74. What is a standby redo log?

Answer: A redo log on the standby used to receive redo in real time, supporting real-time apply
and faster transitions.

75. What is apply lag?

Answer: The delay between redo generation on primary and redo application on standby.

76. What is transport lag?

Answer: The delay between redo generation on primary and redo receipt on standby.

77. What is Data Guard Broker?

Answer: A management framework for monitoring and operating Data Guard configurations
using DGMGRL or Enterprise Manager.

78. What is switchover?

Answer: A planned role reversal between primary and standby when both are available and
synchronized.

79. What is failover?

Answer: An unplanned promotion of a standby to primary when the original primary is
unavailable.

80. What is FSFO?

Answer: Fast-Start Failover automates failover through broker and observer when configured
conditions are met.

81. What is Oracle Data Guard?

Answer: It is Oracle database HA/DR technology that maintains standby databases by
transporting and applying redo from a primary database.

82. What is the difference between primary and standby role?

Answer: Primary accepts read-write production workload; standby receives redo and can
become primary during role transition.

83. In a redo transport scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

84. In a redo transport scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.
Oracle Data Guard Master Guide | Page 44
 Oracle Data Guard Master Guide
85. In a redo transport scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

86. In a redo transport scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

87. In a redo transport scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

88. In a redo transport scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

89. In a redo transport scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

90. In a redo transport scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

Protection Modes
91. What is Oracle Data Guard?
Answer: It is Oracle database HA/DR technology that maintains standby databases by
transporting and applying redo from a primary database.

92. What is the difference between primary and standby role?

Answer: Primary accepts read-write production workload; standby receives redo and can
become primary during role transition.

93. Why is FORCE LOGGING important?

Answer: It reduces risk of unrecoverable operations bypassing redo and causing standby
divergence.

94. What is a standby redo log?

Answer: A redo log on the standby used to receive redo in real time, supporting real-time apply
and faster transitions.

95. What is apply lag?

Answer: The delay between redo generation on primary and redo application on standby.

96. What is transport lag?

Answer: The delay between redo generation on primary and redo receipt on standby.

97. What is Data Guard Broker?

Oracle Data Guard Master Guide | Page 45

 Oracle Data Guard Master Guide
Answer: A management framework for monitoring and operating Data Guard configurations
using DGMGRL or Enterprise Manager.

98. What is switchover?

Answer: A planned role reversal between primary and standby when both are available and
synchronized.

99. What is failover?

Answer: An unplanned promotion of a standby to primary when the original primary is
unavailable.

100. What is FSFO?

Answer: Fast-Start Failover automates failover through broker and observer when configured
conditions are met.

101. In a protection modes scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

102. In a protection modes scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

103. In a protection modes scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

104. In a protection modes scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

105. In a protection modes scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

106. In a protection modes scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

107. In a protection modes scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

Oracle Data Guard Master Guide | Page 46

 Oracle Data Guard Master Guide
108. In a protection modes scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

Broker
109. What is failover?
Answer: An unplanned promotion of a standby to primary when the original primary is
unavailable.

110. What is FSFO?

Answer: Fast-Start Failover automates failover through broker and observer when configured
conditions are met.

111. What is Oracle Data Guard?

Answer: It is Oracle database HA/DR technology that maintains standby databases by
transporting and applying redo from a primary database.

112. What is the difference between primary and standby role?

Answer: Primary accepts read-write production workload; standby receives redo and can
become primary during role transition.

113. Why is FORCE LOGGING important?

Answer: It reduces risk of unrecoverable operations bypassing redo and causing standby
divergence.

114. What is a standby redo log?

Answer: A redo log on the standby used to receive redo in real time, supporting real-time apply
and faster transitions.

115. What is apply lag?

Answer: The delay between redo generation on primary and redo application on standby.

116. What is transport lag?

Answer: The delay between redo generation on primary and redo receipt on standby.

117. What is Data Guard Broker?

Answer: A management framework for monitoring and operating Data Guard configurations
using DGMGRL or Enterprise Manager.

118. What is switchover?

Answer: A planned role reversal between primary and standby when both are available and
synchronized.

119. In a broker scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

120. In a broker scenario, how would you validate and troubleshoot Data Guard health?
Oracle Data Guard Master Guide | Page 47
 Oracle Data Guard Master Guide
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

121. In a broker scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

122. In a broker scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

123. In a broker scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

124. In a broker scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

125. In a broker scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

126. In a broker scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

Installation Lab
127. What is Data Guard Broker?
Answer: A management framework for monitoring and operating Data Guard configurations
using DGMGRL or Enterprise Manager.

128. What is switchover?

Answer: A planned role reversal between primary and standby when both are available and
synchronized.

129. What is failover?

Answer: An unplanned promotion of a standby to primary when the original primary is
unavailable.

130. What is FSFO?

Answer: Fast-Start Failover automates failover through broker and observer when configured
conditions are met.

131. What is Oracle Data Guard?

Answer: It is Oracle database HA/DR technology that maintains standby databases by
transporting and applying redo from a primary database.

132. What is the difference between primary and standby role?

Oracle Data Guard Master Guide | Page 48
 Oracle Data Guard Master Guide
Answer: Primary accepts read-write production workload; standby receives redo and can
become primary during role transition.

133. Why is FORCE LOGGING important?

Answer: It reduces risk of unrecoverable operations bypassing redo and causing standby
divergence.

134. What is a standby redo log?

Answer: A redo log on the standby used to receive redo in real time, supporting real-time apply
and faster transitions.

135. What is apply lag?

Answer: The delay between redo generation on primary and redo application on standby.

136. What is transport lag?

Answer: The delay between redo generation on primary and redo receipt on standby.

137. In a installation lab scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

138. In a installation lab scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

139. In a installation lab scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

140. In a installation lab scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

141. In a installation lab scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

142. In a installation lab scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

143. In a installation lab scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

144. In a installation lab scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

Oracle Data Guard Master Guide | Page 49

 Oracle Data Guard Master Guide
RMAN and Monitoring
145. What is apply lag?
Answer: The delay between redo generation on primary and redo application on standby.

146. What is transport lag?

Answer: The delay between redo generation on primary and redo receipt on standby.

147. What is Data Guard Broker?

Answer: A management framework for monitoring and operating Data Guard configurations
using DGMGRL or Enterprise Manager.

148. What is switchover?

Answer: A planned role reversal between primary and standby when both are available and
synchronized.

149. What is failover?

Answer: An unplanned promotion of a standby to primary when the original primary is
unavailable.

150. What is FSFO?

Answer: Fast-Start Failover automates failover through broker and observer when configured
conditions are met.

151. What is Oracle Data Guard?

Answer: It is Oracle database HA/DR technology that maintains standby databases by
transporting and applying redo from a primary database.

152. What is the difference between primary and standby role?

Answer: Primary accepts read-write production workload; standby receives redo and can
become primary during role transition.

153. Why is FORCE LOGGING important?

Answer: It reduces risk of unrecoverable operations bypassing redo and causing standby
divergence.

154. What is a standby redo log?

Answer: A redo log on the standby used to receive redo in real time, supporting real-time apply
and faster transitions.

155. In a rman and monitoring scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

156. In a rman and monitoring scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

Oracle Data Guard Master Guide | Page 50

 Oracle Data Guard Master Guide
157. In a rman and monitoring scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

158. In a rman and monitoring scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

159. In a rman and monitoring scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

160. In a rman and monitoring scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

161. In a rman and monitoring scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

162. In a rman and monitoring scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

Switchover/Failover/FSFO
163. Why is FORCE LOGGING important?
Answer: It reduces risk of unrecoverable operations bypassing redo and causing standby
divergence.

164. What is a standby redo log?

Answer: A redo log on the standby used to receive redo in real time, supporting real-time apply
and faster transitions.

165. What is apply lag?

Answer: The delay between redo generation on primary and redo application on standby.

166. What is transport lag?

Answer: The delay between redo generation on primary and redo receipt on standby.

167. What is Data Guard Broker?

Answer: A management framework for monitoring and operating Data Guard configurations
using DGMGRL or Enterprise Manager.

Oracle Data Guard Master Guide | Page 51

 Oracle Data Guard Master Guide
168. What is switchover?
Answer: A planned role reversal between primary and standby when both are available and
synchronized.

169. What is failover?

Answer: An unplanned promotion of a standby to primary when the original primary is
unavailable.

170. What is FSFO?

Answer: Fast-Start Failover automates failover through broker and observer when configured
conditions are met.

171. What is Oracle Data Guard?

Answer: It is Oracle database HA/DR technology that maintains standby databases by
transporting and applying redo from a primary database.

172. What is the difference between primary and standby role?

Answer: Primary accepts read-write production workload; standby receives redo and can
become primary during role transition.

173. In a switchover/failover/fsfo scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

174. In a switchover/failover/fsfo scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

175. In a switchover/failover/fsfo scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

176. In a switchover/failover/fsfo scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

177. In a switchover/failover/fsfo scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

178. In a switchover/failover/fsfo scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.
Oracle Data Guard Master Guide | Page 52
 Oracle Data Guard Master Guide
179. In a switchover/failover/fsfo scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

180. In a switchover/failover/fsfo scenario, how would you validate and troubleshoot Data Guard
health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

RAC and ASM

181. What is Oracle Data Guard?
Answer: It is Oracle database HA/DR technology that maintains standby databases by
transporting and applying redo from a primary database.

182. What is the difference between primary and standby role?

Answer: Primary accepts read-write production workload; standby receives redo and can
become primary during role transition.

183. Why is FORCE LOGGING important?

Answer: It reduces risk of unrecoverable operations bypassing redo and causing standby
divergence.

184. What is a standby redo log?

Answer: A redo log on the standby used to receive redo in real time, supporting real-time apply
and faster transitions.

185. What is apply lag?

Answer: The delay between redo generation on primary and redo application on standby.

186. What is transport lag?

Answer: The delay between redo generation on primary and redo receipt on standby.

187. What is Data Guard Broker?

Answer: A management framework for monitoring and operating Data Guard configurations
using DGMGRL or Enterprise Manager.

188. What is switchover?

Answer: A planned role reversal between primary and standby when both are available and
synchronized.

189. What is failover?

Answer: An unplanned promotion of a standby to primary when the original primary is
unavailable.

190. What is FSFO?

Answer: Fast-Start Failover automates failover through broker and observer when configured
conditions are met.

Oracle Data Guard Master Guide | Page 53

 Oracle Data Guard Master Guide
191. In a rac and asm scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

192. In a rac and asm scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

193. In a rac and asm scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

194. In a rac and asm scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

195. In a rac and asm scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

196. In a rac and asm scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

197. In a rac and asm scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

198. In a rac and asm scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

Troubleshooting
199. What is failover?
Answer: An unplanned promotion of a standby to primary when the original primary is
unavailable.

200. What is FSFO?

Answer: Fast-Start Failover automates failover through broker and observer when configured
conditions are met.

201. What is Oracle Data Guard?

Answer: It is Oracle database HA/DR technology that maintains standby databases by
transporting and applying redo from a primary database.

202. What is the difference between primary and standby role?

Answer: Primary accepts read-write production workload; standby receives redo and can
become primary during role transition.

Oracle Data Guard Master Guide | Page 54

 Oracle Data Guard Master Guide
203. Why is FORCE LOGGING important?
Answer: It reduces risk of unrecoverable operations bypassing redo and causing standby
divergence.

204. What is a standby redo log?

Answer: A redo log on the standby used to receive redo in real time, supporting real-time apply
and faster transitions.

205. What is apply lag?

Answer: The delay between redo generation on primary and redo application on standby.

206. What is transport lag?

Answer: The delay between redo generation on primary and redo receipt on standby.

207. What is Data Guard Broker?

Answer: A management framework for monitoring and operating Data Guard configurations
using DGMGRL or Enterprise Manager.

208. What is switchover?

Answer: A planned role reversal between primary and standby when both are available and
synchronized.

209. In a troubleshooting scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

210. In a troubleshooting scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

211. In a troubleshooting scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

212. In a troubleshooting scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

213. In a troubleshooting scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

214. In a troubleshooting scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

215. In a troubleshooting scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.
Oracle Data Guard Master Guide | Page 55
 Oracle Data Guard Master Guide
216. In a troubleshooting scenario, how would you validate and troubleshoot Data Guard health?
Answer: Check broker status, database role/open mode, transport and apply lag, archive
destination errors, alert logs, and recent changes. Then fix the root cause and repeat validation.

Oracle Data Guard Master Guide | Page 56

 Oracle Data Guard Master Guide

Index
Index Term Where to Read
Active Data Guard Parts 1, 4, 7, 10
Apply Lag Parts 4, 7, 8
ARCHIVELOG Parts 2, 6
ASM Part 9
Broker Parts 5, 8, 9
DGMGRL Parts 5, 6, 8, Appendix A
Failover Parts 5, 8, 10
Far Sync Part 4
FORCE LOGGING Parts 2, 6
FSFO Parts 5, 8
Logical Standby Part 3
Maximum Availability Part 5
Maximum Performance Part 5
Maximum Protection Part 5
Physical Standby Part 2
RAC Part 9
Redo Transport Part 4
RMAN Parts 6, 7, Appendix A
Snapshot Standby Part 3
Standby Redo Logs Parts 2, 4, 9
Switchover Parts 5, 8, 10
Troubleshooting Part 8

References and Source Baseline

Oracle Database 19c Data Guard Concepts and Administration:
[Link]
Oracle Database 19c Data Guard Broker: [Link]
database/19/dgbkr/
Oracle Database 19c Reference - Data Guard Views:
[Link]
Oracle Real Application Clusters Administration and Deployment Guide 19c:
[Link]
Oracle Maximum Availability Architecture concepts:
[Link]

Oracle Data Guard Master Guide | Page 57