Oracle Data Guard
12+ Years of Experience in Oracle, SQLServer Database
Oracle Certified Professional Oracle 8i,9i,10g
Oracle Certified Expert Oracle 10g RAC
Data Guard and its benefits?
Data Guard Architecture
Types of Data guards and Benefits
Advantages with different types of Data guards
Processes and Services
Data Guard Protection Modes
Data Guard Role Transitions
Data Guard Broker Architecture
Data Guard features across versions
Data Guard Setup
Why undertake Disaster Recovery?
Disaster can strike at any time
Unprepared organizations can loose
all the critical data.
Even prepared companies can suffer
financial loss during system down time.
Disasters can be natural calamities or
Impact of Disasters
Customers across the globe will be effected
High Availability Challenges
Down time -- unplanned or planned
Setup and Maintenance cost.
Identifying the Disaster Recovery Site (DR Site)
Why Data Guard ?
Prior to Data Guard:
What is Standby database?
A standby database is a database replica created from a backup of
a primary database. By applying archived redo logs from the primary
database to the standby database, you can keep the two databases
Used for :
Protection against data corruption
Data guard is one of the most effective solutions available today in
terms of High Availability. Why?
Before Data guard…
Oracle Data Guard ensures high availability, data protection,
and disaster recovery for enterprise data. Data Guard
provides a comprehensive set of services that create,
maintain, manage, and monitor one or more standby
databases to enable production Oracle databases to survive
disasters and data corruptions.”
Same Oracle Enterprise Edition must be installed.
primary database must run in ARCHIVELOG mode.
Hardware and Operating System architecture must be same.
Primary and Standby must have its own control file
Can be configured on the same or different systems.
Turn on FORCE LOGGING at the primary.
SYSDBA privileges to user accounts.
Data Guard Benefits
Disaster recovery, data protection, and high availability
Complete data protection
Efficient use of system resources
Flexibility in data protection to balance availability against
Automatic gap detection and resolution
Centralized and simple management
Integration with Oracle Database (no separate installation)
Automatic role transitions
Processes Involved in the Architecture
Below are the main processes in DG configuration:
1) Logwriter (LGWr) Process
2) Archiver (ARCH) Process
3) Logwriter Network Server (LNS)
4) Fetch Archive Logs (FAL) for Client –Server mechanism
5) Remote File Server (RFS)
6) Managed Recovery Process (MRP) for Physical standby
7) Logical Standby Process (LSP) for Logical Standby
If Data Guard Broker is enabled :
8) Data Guard Broker Monitor (DMON) process
Apply Services At High Level
Data Guard comprises of two parts
Redo Apply – For physical standby
SQL Apply - for logical standby
The Physical and logical standby databases utilize the same
redo transport and role management services, only apply
process is different.
Either can be used to offload query and reporting from the
primary database. Either can be used to execute a rolling
All standby databases are first created as physical standby
databases during the standby database instantiation process.
Several additional steps are required to convert a physical
standby database to a logical standby database.
A physical standby database applies redo data received from
the primary using Oracle media recovery.
The Redo Apply uses a specialized process, called the
Managed Recovery Process.
As the RFS process is writing redo data to Standby Redo
Logs (SRLs), MRP reads the redo data and applies it to
the physical standby database.
MRP is started on the physical standby database by
mounting the database and using the following command:
SQL> alter database recover managed standby database
using current logfile disconnect from session;
MRP may also transparently switch to reading from a
standby archived log if the SRL is archived before MRP can
complete reading of the.
SQL Apply uses a collection of background processes that
perform the task of applying changes from the primary
database to the logical standby database.
Types of Dataguards: Physical Standby
Provides a physically identical copy of the primary
Identical to the primary database on a block-for-block
The database schema, including indexes, are the same.
Synchronized with the primary database, through Redo
Data guard :Physical Standby Benefits
Disaster recovery and high availability
Enables a robust and efficient disaster recovery and high
Ensures no data loss, even in the face of unforeseen disasters.
Supports all data types, and all DDL and DML operations
Reduction in primary database workload
Oracle Recovery Manager (RMAN) can use to off-load backups from
the primary database saving valuable CPU and I/O cycles.
The Redo Apply technology applies changes using low-level
recovery mechanisms and is most efficient method for applying
high volumes of redo.
Types of Dataguard :Logical Standby
Contains same logical information
physical organization and structure of the data can be different
Synchronized with the primary database, through SQL Apply
Can be used for queries and reporting at any time.
Logical Standby benefits
Along with disaster recovery, high availability, and data
Efficient use of standby hardware resources
Additional indexes and materialized views can be created to
improve query performance and suit specific business
Reduction in primary database workload
•Log Transport Services
Transmit redo data from the primary system to the standby
systems in the configuration
Enforce the database protection modes
•Log Apply Services
Automatically apply archived redo logs on the standby
Maintains transactional synchronization with the primary
Allows transitionally consistent read-only access to the data.
Redo Apply for Physical standby.
SQL Apply for Logical stand by.
•Role Management Services
An Oracle database operates in one of two roles: primary or
Achieved by Switch over and Fail over operations.
There are Three protection modes
There are 3 ways of shipping redo data to a physical standby:
Maximum Protection Mode
This mode ensures that zero data loss occurs if a primary
fails. The default is Maximum Performance.
In case if standby unavailable then processing stops at
primary. This the highest level of protection
Maximum protection configuration - LGWR SYNC, SRLs
SQL> ALTER DATABASE SET STANDBY TO MAXIMIZE
Maximum Availability Mode
This mode provides highest level of data protection with
out compromising the availability of primary database
If last standby is unavailable, processing continues at
primary. As long as network stys up - Zero Data Loss
Maximum availability configuration - LGWR SYNC, do
not need SRLs
SQL> ALTER DATABASE SET STANDBY TO
Maximum Performance Mode
This mode provides the highest level of data protection that
is possible without affection the performance of a primary
database Highest level of performance
This mode has least impact on system and protects from
failure of any single component
Maximum performance configuration - LGWR ASYNC, or
SQL> ALTER DATABASE SET STANDBY TO MAXIMIZE
A database operates in one of the following mutually exclusive
roles: primary or standby.
Data Guard enables you to change these roles dynamically by
issuing the SQL statements , or by using either of the Data
Guard broker's interfaces.
Oracle Data Guard supports the following role transitions:
Allows the primary database to switch roles with one of its
There is no data loss during a switchover.
After a switchover, each database continues to participate in
the Data Guard configuration with its new role.
A failover is typically used only when the primary database
becomes unavailable, and there is no possibility of restoring it
to service within a reasonable period of time.
The specific actions performed during a failover vary based on
whether a logical or a physical standby database is involved in
the failover, the state of the Data Guard configuration at the
time of the failover, and on the specific SQL statements used
to initiate the failover
Data guard Broker:
The Data Guard broker is a distributed management
framework that automates and centralizes the creation,
maintenance, and monitoring of Data Guard configurations
Can be administered either from Oracle Enterprise Manager
or Broker’s CLI (DGMGRL)
List of operations that Broker automates :
Creating and Enabling DG configurations – both Primary
Managing DG configuration from any site.
Implementing Switchover and Failover operations
DG features in Oracle 9.1:
9i : (9.1)
Oracle 8i Standby renamed as Oracle 9i Data Guard
Oracle9i Data Guard broker
No data loss
Database Switch over
Archive gaps automatically detected
Background managed recovery mode.
Standby redo logs.
Enhancements in 9.2:
9i : (9.2)
Logical Standby Database
Data protection modes (Max
Cascading Redo Log Destinations
Data Guard Broker
Supports up to 9 Physical and Logical Standby databases
For Failover and Switchover operations
New Key words for REMOTE_ARCHIVE_ENABLE
Data guard Enhancements in 10g :
Fast –start Failover
LGWR ASYNC Redo Transport Enhancement
Real Time Apply
Active Data guard
Offload readonly queries to physical standby
Offload increamental backups to physical standby
Rolling Database Upgrades
The Rolling upgrade process involves upgrading the
logical standby database to the next release
The patch set upgrade can be performed with near
zero database downtime.
Setup Overview :
Step 1: Prepare the Primary for Standby
Step 2: Configure Primary parameters
Step 3: Configure Primary listener and tnsnames
Step 4: Copy the necessary files and create Standby controlfile
Step 5: Configure the Standby Parameters
Step 6: Configure Standby listener and tnsnames
Step 7: Startup the Standby Site and Apply redo
Primary Database Req for DataGuard
FORCE LOGGING must be enabled:
SQL> Select name, database_role from v$database;
SQL> select force_logging from v$database;
SQL> alter database force logging;
Database must be in ARCHIVELOG mode and automatic archiving
must be enabled:
SQL> archive log list
Create Standby Controlfile
Shutdown the Primary database and copy the necessary files to
SQL> STATUP MOUNT
SQL>ALTER DATABASE CREATE STANDBY CONTROLFILE AS
Copy the standby control file to standby site
Mount Standby Database and Apply redo
Keep the database in Standby mode
Start Redo Apply
SQL>ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE DISCONNECT FROM SESSION;
The DISCONNECT FROM SESSION option used to run
background session to apply Redo