Data Guard Architecture
As described briefly in the previous chapter, a
Data Guard configuration consists of the primary database and at
least one standby database. The primary database provides the usual
database services. Client applications make changes to the primary
These changes flow between the primary and the
RAC cluster in the form of redo records. Standby databases are
kept in sync with the primary database using these redo records. The
mechanism used for synchronization depends on the data protection
mode and the type of standby database.
The Log Transport Process and Log Apply Process
play an important role how Data Guard works. The log transfer
service is responsible for transmitting the redo records from the
primary to the standby database. The log apply service applies the
redo records; reading from the redo log files onto the standby
On the downside, the Data Guard option is
expensive to set up. To properly configure the environment, it
almost certainly requires extra servers that can be switched over in
case of an outage on the primary database. Also, extra servers will
require some attention from the system administration team and the
database administration team for set up and regular maintenance
A Data Guard installation also requires a SQL*Net connection between the primary
and standby databases because a network connection will be required
between the two sites. Sometimes, the financial implications of
setting up a Data Guard environment outweigh the benefits offered by
Data Guard Architecture
Figure 2.1 illustrates the general working of
Data Guard. The diagram shows the flow of data in a Data Guard
environment. The four main stages are identified as steps A to D:
Step A ? The client application accesses
the primary database and updates data.
Step B ? The archiver process copies the
online redo log file to the local archival destination.
Step C - The log transfer process transfers
the archived redo log file to the standby site.
Step D ? The log apply process on the
standby site synchronizes the RAC cluster by applying the
redo records from the archived log file.
The number and type of processes involved, in
the working of Data Guard, may vary slightly depending on the
specified data protection mode.
Figure 2.1 ? A general overview of a Data Guard configuration.
Data Guard Architectural
In this section, a detailed description of the
processes and other components involved in the workings of Data
Guard are presented. One of the requirements of a Data Guard
configuration is that the primary database run in ARCHIVELOG mode.
This ensures that all the changes made to the primary database are
captured and kept in the archived redo log. The following section
explains the database processes contributing to the Data Guard
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 seconds.
While attempting to maintain this high level of
availability, the importance of data integrity and quality cannot be
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
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 hot backup.
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
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.
Get the Complete
Oracle SQL Tuning Information
The landmark book
SQL Tuning The Definitive Reference" is
filled with valuable information on Oracle SQL Tuning.
This book includes scripts and tools to hypercharge Oracle 11g
performance and you can
for 30% off directly from the publisher.