Data Guard Standby Tips
Donald K. Burleson
December 7, 2015
The work of standby databases is based on
transaction details embedded in redo logs. A primary database serves
the request from database clients. When a piece of information
within the primary database is changed, the change detail is
registered in redo logs.
When a redo log is full, the log writer starts
writing to the new redo log and the old redo log is archived by the
archive process (ARCH). In a standby configuration, archived logs
are transferred to the standby database. If the RAC cluster is
in recovery mode, the archived logs are then applied. This process
ensures that the changes made on the primary database are applied to
the standby database; hence, the two databases remain in sync.
In case of an outage on the primary database,
the RAC cluster can be activated to perform the role of the
primary database to minimize downtime.
History of the
Data Guard Standby Database
Standby databases were first introduced in
Oracle 7.3. At that time, there were more limitations than features
in the standby database; therefore, it was not considered to be a
viable option for disaster recovery. Since then, Oracle has made
many improvements in the functionality of standby databases.
The standby database technology was made very robust and usable in
Oracle8i. The existence of multiple physical standby databases, the
read-only mode, and the managed recovery mode are some of the key
enhancements to RAC cluster technology included in Oracle8i.
In Oracle9i, the new features such as logical
standby databases, multiple physical database, and ease of
administration using the management tool called Oracle Data Guard
Broker made this technology comparable with other disaster recovery
Chronological Development of Standby Technology
In Oracle 7.3, the newly introduced standby
database technology supported only disaster recovery and was
required to operate in recovery mode. Standby databases could not be
opened in read-only mode for query. The transfer of archived redo
logs was a manual process and required the DBA to write operating
system specific scripts to transfer the logs from the primary to a
standby host. In the event of primary database failure, the loss of
the current redo logs would result in the loss of data.
Hence, a more robust redo logs member and group
were required to minimize data loss. Since its introduction, Oracle
Corporation has made improvements in standby technology.
Oracle 8i enhancement to standby database
The enhancements to standby technology that
came with the release of Oracle8i include the following:
Oracle 8i enhancement
The restructuring of the RAC cluster so
that it could be opened for queries and reporting; thus, reducing
some load on the primary database. During this period, the archived
redo logs will be transferred from the primary site to a standby
site and will be applied when the database is put back in recovery
The Recovery MANager (RMAN) could
be used to back up the standby database, which can then be used for
recovery of the primary database using the traditional
backup/recovery method. Up to four standby databases could be
configured in managed recovery mode.
The next section will introduce the Oracle9i
Data Guard feature.
Introduction to Oracle 9i Data Guard Standby
Each of the two Releases of Oracle9i offered
improvements that represented advancements in database technology.
A summary of the changes is presented below.
Standby Database Enhancements in 9i Release 1
In Release 1 of Oracle 9i, RAC cluster technology was renamed to Data Guard technology and Data Guard
Broker was introduced. Data Guard Broker is a distributed management
framework which simplifies the configuration and management of the
Data Guard configuration.
Two new concepts were introduced to safeguard
against data loss: no data loss and no data divergence. In no data
loss mode, a transaction is not committed on the primary database
until it is committed on at least one standby database. In no data
divergence mode, the primary database will shut down if it cannot
distribute the archive log to at least one standby database.
Standby databases could be configured to
automatically detect and resolve gap sequence. In the older
versions, only the failover operation was supported, which required
the recreation of the RAC cluster after the failover operation.
In Oracle 9i, a new switchover operation was introduced, which does
not require the rebuilding of the standby database; therefore, after
a switchover operation, the primary and standby databases swap
Up to nine standby databases could be created
to support one primary database in managed recovery mode. In fact,
Oracle9i does not mention manual recovery mode, but it can still be
Data Guard Standby Database Enhancements in 9i Release 2
New data protection modes were introduced in
Release 2. The new modes are: maximum protection for no data loss;
maximum availability for no data loss; and maximum performance for
minimal data loss.
The logical RAC cluster is another new feature in
Oracle9i Release 2. This feature enables the creation of a RAC cluster that is logically similar to the primary database but does not need
to be structurally exact to the primary database. Logical standby
databases can assist in creating a reporting only system from the
New data dictionary views and initialization
parameters were also added to improve the management of standby