Oracle Data Guard Concept

Posted by Pavan DBA on December 28, 2009

17 Votes

Oracle Data Guard Concept

Oracle Data Guard is one of the most effective and comprehensive data availability,
data protection and disaster recovery solutions available today for enterprise
data.

Oracle Data Guard is the management, monitoring, and automation software

infrastructure that creates, maintains, and monitors one or more standby databases
to protect enterprise data from failures, disasters, errors, and corruptions.

Data Guard maintains these standby databases as transitional consistent copies of

the production database. These standby databases can be located at remote disaster
recovery sites thousands of miles away from the production data center, or they may
be located in the same city, same campus, or even in the same building. If the
production database becomes unavailable because of a planned or an unplanned
outage, Data Guard can switch any standby database to the production role, thus
minimizing the downtime associated with the outage, and preventing any data loss.

Available as a feature of the Enterprise Edition of the Oracle Database, Data Guard
can be used in combination with other Oracle High Availability (HA) solutions such
as Real Application Clusters (RAC), Oracle Flashback and Oracle Recovery Manager
(RMAN), to provide a very high level of data protection and data availability that
is unprecedented in the industry.

The following diagram presents a hi-level overview of Oracle Data Guard.

Overview of Oracle Data Guard Functional Components

Data Guard Configuration:

A Data Guard configuration consists of one production (or primary) database and up
to nine standby databases. The databases in a Data Guard configuration are
connected by Oracle Net and may be dispersed geographically. There are no
restrictions on where the databases are located, provided that they can communicate
with each other. However, for disaster recovery, it is recommended that the standby
databases are hosted at sites that are geographically separated from the primary
site.

Redo Apply and SQL Apply:

A standby database is initially created from a backup copy of the primary database.
Once created, Data Guard automatically maintains the standby database as a
transactional consistent copy of the primary database by transmitting primary
database redo data to the standby system and then applying the redo logs to the
standby database.

Data Guard provides two methods to apply this redo data to the standby database and
keep it transactional consistent with the primary, and these methods correspond to
the two types of standby databases supported by Data Guard.

Redo Apply, used for physical standby databases

SQL Apply, used for logical standby databases
A physical standby database provides a physically identical copy of the primary
database, with on-disk database structures that are identical to the primary
database on a block-for-block basis. The database schemas, including indexes are
the same. The Redo Apply technology applies redoes data on the physical standby
database using standard Oracle media recovery techniques.

A logical standby database contains the same logical information as the production
database, although the physical organization and structure of the data can be
different. The SQL apply technology keeps the logical standby database synchronized
with the primary database by transforming the data in the redo logs received from
the primary database into SQL statements and then executing the SQL statements on
the standby database. This makes it possible for the logical standby database to be
accessed for queries and reporting purposes at the same time the SQL is being
applied to it. Thus, a logical standby database can be used concurrently for data
protection and reporting.

Role Management:

Using Data Guard, the role of a database can be switched from a primary role to a
standby role and vice versa, ensuring no data loss in the process, and minimizing
downtime. There are two kinds of role transitions – a switchover and a failover. A
switchover is a role reversal between the primary database and one of its standby
databases. This is typically done for planned maintenance of the primary system.
During a switchover, the primary database transitions to a standby role and the
standby database transitions to the primary role. The transition occurs without
having to re-create either database. A failover is an irreversible transition of a
standby database to the primary role. This is only done in the event of a
catastrophic failure of the primary database, which is assumed to be lost and to be
used again in the Data Guard configuration, it must be re-instantiated as a standby
from the new primary.

Data Guard Protection Modes:

In some situations, a business cannot afford to lose data at any cost. In other
situations, some applications require maximum database performance and can tolerate
a potential loss of data. Data Guard provides three distinct modes of data
protection to satisfy these varied requirements:

Maximum Protection— This mode offers the highest level of data protection. Data is
synchronously transmitted to the standby database from the primary database and
transactions are not committed on the primary database unless the redo data is
available on at least one standby database configured in this mode. If the last
standby database configured in this mode becomes unavailable, processing stops on
the primary database. This mode ensures no-data-loss.
Maximum Availability— This mode is similar to the maximum protection mode,
including zero data loss. However, if a standby database becomes unavailable (for
example, because of network connectivity problems), processing continues on the
primary database. When the fault is corrected, the standby database is
automatically resynchronized with the primary database.
Maximum Performance— This mode offers slightly less data protection on the primary
database, but higher performance than maximum availability mode. In this mode, as
the primary database processes transactions, redo data is asynchronously shipped to
the standby database. The commit operation of the primary database does not wait
for the standby database to acknowledge receipt of redo data before completing
write operations on the primary database. If any standby destination becomes
unavailable, processing continues on the primary database and there is little
effect on primary database performance.

Data Guard Broker:

The Oracle Data Guard Broker is a distributed management framework that automates
and centralizes the creation, maintenance, and monitoring of Data Guard
configurations. All management operations can be performed either through Oracle
Enterprise Manager, which uses the Broker, or through the Broker’s specialized
command-line interface (DGMGRL).

Data Guard Architecture Diagram

The following diagram shows an overview of the Oracle Data Guard architecture.

What’s New in Oracle Data Guard 10g Release 2?

This section will highlight some of the key new features of Oracle Data Guard 10g
Release 2. For details into these features, please refer to the following:

Fast-Start Failover

This capability allows Data Guard to automatically, and quickly fail over to a
previously chosen, synchronized standby database in the event of loss of the
primary database, without requiring any manual steps to invoke the failover, and
without incurring any data loss. Following a fast-start failover, once the old
primary database is repaired, Data Guard automatically reinstates it to be a
standby database. This act restores high availability to the Data Guard
configuration.

Improved Redo Transmission

Several enhancements have been made in the redo transmission architecture to make
sure redo data generated on the primary database can be transmitted as quickly and
efficiently as possible to the standby database(s).

Easy conversion of a physical standby database to a reporting database

A physical standby database can be activated as a primary database, opened

read/write for reporting purposes, and then flashed back to a point in the past to
be easily converted back to a physical standby database. At this point, Data Guard
automatically synchronizes the standby database with the primary database. This
allows the physical standby database to be utilized for read/write reporting and
cloning activities.
Automatic deletion of applied archived redo log files in logical standby databases

Archived logs, once they are applied on the logical standby database, are
automatically deleted, reducing storage consumption on the logical standby and
improving Data Guard manageability. Physical standby databases have already had
this functionality since Oracle Database 10g Release 1, with Flash Recovery Area.

Fine-grained monitoring of Data Guard configurations

Oracle Enterprise Manager has been enhanced to provide granular, up-to-date

monitoring of Data Guard configurations, so that administrators may make an
informed and expedient decision regarding managing this configuration.

What’s New in Oracle Data Guard 10g Release 1?

This section will highlight some of the key new features of Oracle Data Guard 10g
Release 1. For details into these features, please refer to the following:

General New Features:

Real Time Apply:

With this feature, redo data can be applied on the standby database (whether Redo
Apply or SQL Apply) as soon as they have written to a Standby Redo Log (SRL). Prior
releases of Data Guard require this redo data to be archived at the standby
database in the form of archivelogs before they can be applied.

The Real Time Apply feature allows standby databases to be closely synchronized
with the primary database, enabling up-to-date and real-time reporting (especially
for Data Guard SQL Apply). This also enables faster switchover and failover times,
which in turn reduces planned and unplanned downtime for the business.

The impact of a disaster is often measured in terms of Recovery Point Objective

(RPO – i.e. how much data can a business afford to lose in the event of a disaster)
and Recovery Time Objective (RTO – i.e. how much time a business can afford to be
down in the event of a disaster). With Oracle Data Guard, when Maximum Protection
is used in combination with Real Time Apply, businesses get the benefits of both
zero data loss as well as minimal downtime in the event of a disaster and this
makes Oracle Data Guard the only solution available today with the best RPO and RTO
benefits for a business.

Integration with Flashback Database:

Data Guard in 10g has been integrated with the Flashback family of features to
bring the Flashback feature benefits to a Data Guard configuration.

One such benefit is human error protection. In Oracle9i, administrators may

configure Data Guard with an apply delay to protect standby databases from possible
logical data corruptions that occurred on the primary database. The side-effects of
such delays are that any reporting that gets done on the standby database is done
on old data, and switchover/failover gets delayed because the accumulated logs have
to be applied first. In Data Guard 10g, with the Real Time Apply feature, such
delayed-reporting or delayed-switchover/failover issues do not exist, and – if
logical corruptions do land up affecting both the primary and standby database, the
administrator may decide to use Flashback Database on both the primary and standby
databases to quickly revert the databases to an earlier point-in-time to back out
such user errors.

Another benefit that such integration provides is during failovers. In releases

prior to 10g, following any failover operation, the old primary database must be
recreated (as a new standby database) from a backup of the new primary database, if
the administrator intends to bring it back in the Data Guard configuration. This
may be an issue when the database sizes are fairly large, and the primary/standby
databases are hundreds/thousands of miles away. However, in Data Guard 10g, after
the primary server fault is repaired, the primary database may simply be brought up
in mounted mode, “flashed back” (using flashback database) to the SCN at which the
failover occurred, and then brought back as a standby database in the Data Guard
configuration. No re-instantiation is required.

SQL Apply New Features:

Zero Downtime Instantiation:

Logical standby database can now be created from an online backup of the primary
database, without shutting down or quiescing the primary database, as was the case
in prior releases. No shutdown of the primary system implies production downtime is
eliminated, and no quiesce implies no waiting for quiescing to take effect and no
dependence on Resource Manager.

Rolling Upgrades:

Oracle Database 10g supports database software upgrades (from Oracle Database 10g
Patchset 1 onwards) in a rolling fashion, with near zero database downtime, by
using Data Guard SQL Apply. The steps involve upgrading the logical standby
database to the next release, running in a mixed mode to test and validate the
upgrade, doing a role reversal by switching over to the upgraded database, and then
finally upgrading the old primary database. While running in a mixed mode for
testing purpose, the upgrade can be aborted and the software downgraded, without
data loss. For additional data protection during these steps, a second standby
database may be used.

By supporting rolling upgrades with minimal downtimes, Data Guard reduces the large
maintenance windows typical of many administrative tasks, and enables the 24×7
operation of the business.

Additional Datatypes:

SQL Apply now supports the following additional data types.

NCLOB
LONG
LONG RAW
BINARY_FLOAT
BINARY_DOUBLE
IOT-s (without overflows and without LOB columns)
This support for additional datatypes allows logical standby databases to recover
and protect a wider variety of data, thus increasing the overall database
protection and recovery options for Data Guard.

Enterprise Manager / Data Guard Broker New Features:

RAC Support:

It is now possible to use the Data Guard Broker, and the Broker’s Command Line
Interface (DGMGRL), as well as Enterprise Manager, to create and manage Data Guard
configurations that contain RAC primary and RAC standby databases. In Oracle9i,
such administration is possible only through SQL*Plus. In Data Guard 10g, Data
Guard Broker interfaces with Oracle Clusterware such that it has control over
critical operations during specific Data Guard state transitions, such as
switchovers, failovers, protection mode changes and state changes.

Simplified Browser-based Interface

Administration of a Data Guard configuration can be done through the new

streamlined browser-based HTML interface of Enterprise Manager that enables
complete standby database lifecycle management. The focus of such streamlined
administration is on:

Ease of use.
Management based on best practices.
Pre-built integration with other HA features.