Data Guard for Disaster Recovery
Donald K. Burleson
If a database requires 99.99% availability, how
much downtime does that leave the DBA for both planned and unplanned
outages in one year? The answer is a mere 52 minutes and 33
While attempting to maintain this high level of
availability, the importance of data integrity and quality cannot be
compromised. Should something go wrong with a database, most if not
all, businesses want the database to be recovered without the loss
of a single byte of information. This adds a new dimension of
disaster recovery to the realm of database administration.
When combining the two paradigms of "24X7" with
regard to availability and "disaster recovery", there are not many
downtime solutions left to the DBA. Thus, when high performance is
added to this paradigm, it becomes the straw that breaks the DBA's
back. This dilemma presents itself fully when there is a need to
create a backup without shutting down the database. The problem is
that the only remaining solution is for the DBA to create an online
Online hot backup on a moderate to large size
database will have significant performance implications. As a
result, the savvy DBA will quickly realize that the online hot
backup may not be the most suitable solution to the problem, which
combines the demands of "24X7", "full protection of database" and
Archive Log Repository
Sometimes, the Oracle instance
is used only as an archive log repository. In this case, the benefit
is the storage of the archived redo logs on another server for a
small period of time. The transfers of archived redo logs are
maintained by Oracle processes using SQL*Net . For an archive log
repository configuration, data files are not required; therefore, it
cannot be used for data recovery.
Drawbacks of Data Guard for Disaster Recovery
Like any technology, Data Guard has advantages
and disadvantages. Data Guard configuration has following
Geographic Disaster Recovery with Data Guard
A Data Guard configuration consists of several
standby databases connected to the primary database using Oracle
SQL*Net. These standby databases can be used for failover operation if
the primary database is not available thereby minimizing the loss of
service. Data Guard configuration provides a safeguard against
physical corruption as well as prevention of user errors on the
primary database. The physical corruptions of data blocks due to
device failure will not be propagated via archived redo logs.
Since the information between the primary and
the Oracle instance
flows in the form of redo logs, a delay can be
built into the redo log application mechanism on the standby
database. This built-in delay in log application service can be used
to prevent propagation of user errors to the Oracle instance
long as the errors are detected on the primary database before the
application of the logs on the standby database.
Disaster Protection: Maximum Performance vs.
Moreover, a Data Guard environment can be
configured in three different modes: maximum protection, maximum
availability and maximum performance. The DBA must evaluate the
requirements of their enterprise to configure Data Guard in one of
these modes to suit the chosen disaster recovery strategy.
In addition to disaster protection, standby
databases can be used for database services during the planned
outage of the primary database for maintenance work. Once the role
of the Oracle instance
is switched and it starts serving as the
primary database, the DBA must update the Oracle Net configuration
to route the application requests to the new primary database. The
details about changes in Oracle Net and alternative approach using
Transparent Application Failover are described later in this book.
Data Guard Disaster Recovery with for High Performance
To address this problem, database vendors
started to explore the area of high availability (HA) solutions.
Oracle Corporation has made significant advances in the Parallel
Server configuration called Real Application Cluster (RAC) in Oracle
9i, Advanced Replication and Data Guard technology.
Data Guard was introduced as the Standby
Database in Oracle 7.3, and has evolved significantly since then.
Ideally, Data Guard provides a combined solution for the problem of
high availability and disaster recovery without compromising
This chapter provides an overview of Oracle
Data Guard technology. It includes basic information on standby
databases. This information will help DBAs decide if Oracle Data
Guard is the appropriate solution, in the realm of disaster
protection and high availability, for their enterprise.
There are four methods for achieving failover
technology within the Oracle software. Each failover option has its
own costs, advantages and disadvantages (Figure 1-1).
When choosing a failover option, the DBA must
consider their tolerance for unplanned downtime as well as the cost
per minute for downtime.