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

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 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 "high performance".

Archive Log Repository

Sometimes, the Oracle instance configuration 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.

Benefits and Drawbacks of Data Guard for Disaster Recovery

Like any technology, Data Guard has advantages and disadvantages. Data Guard configuration has following advantages:

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 as 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. Maximum availability

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

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.

Oracle Failover Options

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.