Database Reference
In-Depth Information
An introduction to Oracle Data Guard
Oracle Data Guard is one of the primary means to protect the Oracle database from unplanned outages in the local
data center. Unplanned data center outages, as their name implies, greatly affect the availability of the database
service. Effective planning beforehand is required to minimize the impact of outages, and having a Data Guard
configuration in place is usually great for peace of mind. You can refer to Table
9-1
for a better understanding of where
in the Oracle product portfolio Data Guard is located with regards to protection from unplanned outages.
Table 9-1.
Protecting Oracle from Unplanned Outages
Problem
Technology
Estimated recovery time
Database instance
failure
Migration of the virtual machine
Active/passive clusters
Depends on the technology used
Downtime for the duration of instance
recovery on standby host
No downtime
Real Application Clusters
LUN failure
Automatic Storage Management
No downtime when using ASM built-in
mirroring for disk group
Human error
Flashback Database, Flashback Table,
other Flashback technology
Duration of the Flashback Database command
depends on amount of data changed.
No downtime to recover from dropped tables
if recycle bin is used
Data Guard with delayed redo
application
Very little downtime during failover operation.
Certainly quicker than point-in-time
recovery, but may incur data loss
Data corruption
Data Guard
Very little downtime during failover operation.
Certainly quicker than point-in-time
recovery, but may incur data loss
Site failure
Data Guard
Very little downtime during failover
operation.
Data Guard allows the database administrator to maintain one or more standby databases, which are a copy
of the production database. To be precise, a standby database starts its existence with the RMAN duplication of the
primary database, the main difference between the standby database and production database is a flag in the standby
database's controlfile indicating its role. Changes from the production database are automatically transmitted over
a SQL*Net connection and are constantly applied to the standby database. Standby redo logs (SRL) on the disaster
recovery site act as the counterpart to the primary database's online redo logs (ORL) and allow the remote site to
receive redo more efficiently.
The standby database can either be identical with production down to the individual bit, or it can be a logical
copy. The bitwise identical copy of production is more widespread as it guarantees better business continuity.
The way changes from production are transmitted to the standby database—via an IP network—is an important
differentiator to the storage replication mentioned in the introduction to this chapter which most commonly relies
on the Fiber Channel protocol to keep the remote copies in sync.
Oracle automatically tries to stay in sync with the production database with the help of a set of background
processes. One of these processes ensures that the standby database is constantly in the state of media recovery.
A standby database can temporarily be opened for read-only access. Without the Active Data Guard option
introduced in Oracle 11.1, there is a caveat you need to be aware of: while the database is opened in read-only mode,
it doesn't apply changes received from the primary database.
Search WWH ::
Custom Search