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

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

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

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 this technology.

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 Components

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

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

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.

 

Get the Complete Oracle SQL Tuning Information  The landmark book "Advanced Oracle 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 buy it for 30% off directly from the publisher.