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 options.

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:

• The inclusion of a managed recovery mode which automates the process of archived redo log transfers from the primary to a standby site and the application of redo logs on the standby site.  This reduced the number of manual interventions by DBAs.

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 mode.
   

• 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 Database

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 roles.

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 created.

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 primary database.

New data dictionary views and initialization parameters were also added to improve the management of standby database.