Skip Headers

Oracle9i Data Guard Concepts and Administration
Release 2 (9.2)

Part Number A96653-01
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index


Go to previous page Go to next page

Oracle9i Data Guard Concepts

Oracle9i Data Guard provides an extensive set of data protection and disaster recovery features to help you to survive disasters, human errors, and corruptions that can incapacitate a database. Based on business requirements, these features can be advantageously combined with other Oracle9i high-availability and disaster recovery features for enhanced levels of high availability and disaster protection.

This chapter explains Oracle9i Data Guard concepts. It includes the following topics:

1.1 Oracle9i Data Guard Overview

Oracle9i Data Guard is the management, monitoring, and automation software that works with a production database and one or more standby databases to protect your data against failures, errors, and corruptions that might otherwise destroy your database. It protects critical data by automating the creation, management, and monitoring of the databases and other components in a Data Guard configuration. It automates the otherwise manual process of maintaining a transactionally consistent copy of an Oracle production database, called a standby database, that can be used if the production database is taken offline for routine maintenance or becomes damaged.

In a Data Guard configuration, a production database is referred to as a primary database. Using a backup copy of the primary database, you can create from one to nine physical and logical standby databases and incorporate them in a Data Guard configuration. Primary and standby databases can be running on a single node or in a Real Application Clusters environment. Every standby database is associated with only one primary database. However, a single primary database can support multiple physical standby databases, logical standby databases, or a mix of both in the same configuration:

Oracle9i Data Guard maintains each standby database as a transactionally consistent copy of the primary database using standard Oracle online redo logs. As transactions add data or change information stored in the primary database, the changes are also written to the online redo logs. The redo logs associated with the primary database are archived to standby destinations by log transport services and applied to the standby database by log apply services.

Figure 1-1 shows logs being applied to both physical and logical standby databases in the same Data Guard configuration.

Figure 1-1 Log Apply Services for Physical and Logical Standby Databases

Text description of ls_config.gif follows.

Text description of the illustration ls_config.gif

Role management services work with log transport services and log apply services to reduce downtime of the primary database for planned outages, such as operating system or hardware upgrades, by performing a switchover operation that is a graceful role reversal between the primary database and one of its standby databases. Role management services also minimize downtime from an unplanned failure of the primary database by facilitating the quick fail over to one of the standby databases through a graceful failover or forced failover operation.

Because the first priority of Data Guard is to ensure that copies of the data are elsewhere, usable, and correct when any data-destroying condition occurs on a primary database, you can use Oracle Net services to locate the standby databases on a geographically remote location (sometimes referred to as a site) over a wide area network (WAN), as well as making standby databases locally accessible on a local area network (LAN). By locating standby databases remotely from the primary system, you ensure that an event that disables the primary database will be unlikely to also disable the standby database. However, it can also be beneficial to locate standby databases on a LAN as another failover option to protect against user errors, system problems, and data corruptions.


The primary purpose of Oracle9i Data Guard is to keep your data highly available against any event, including disasters; it is complementary to traditional backup, restore, and clustering techniques.

Finally, Data Guard allows you to configure and manage a Data Guard configuration through any of several interfaces, including SQL statements, initialization parameters, a PL/SQL package, and the Oracle9i Data Guard broker. The broker is a distributed management framework that automates the creation and management of Data Guard configurations through the Data Guard Manager graphical user interface or its command-line interface.

1.2 Benefits of Oracle9i Data Guard

Oracle9i Data Guard automates the tasks involved in setting up and managing the Data Guard environment, including one or more standby databases, the log transport services, log apply services, and role management services. Oracle9i Data Guard helps you survive events that might otherwise make your database unavailable by:

Figure 1-2 shows an example of a Data Guard configuration that allows failover to occur to either a physical standby database or a logical standby database. If the primary database becomes unavailable, the workload can fail over to either standby database.

Figure 1-2 Oracle9i Data Guard Configuration

Text description of odg_new.gif follows.

Text description of the illustration odg_new.gif

1.3 Physical and Logical Standby Databases

The Data Guard configuration shown in Figure 1-2 consists of loosely connected systems, including a single primary database, a logical standby database, and a physical standby database. A configuration can include multiple (up to nine) standby databases, which can be all physical standby databases, all logical standby databases, or a mix of both.

1.3.1 Configuring Local and Remote Standby Databases

In Figure 1-2, the logical and physical standby databases are geographically distant from the primary database, connected by Oracle Net over a WAN. While configuring remote standby databases is the best strategy for disaster protection, there are many good reasons for configuring both local and remote standby databases:

When a primary database is open and active, both the local and remote standby databases are sent redo log data generated as transactions are made to the primary database. In a Data Guard environment, a physical standby database can be either recovering data or open for reporting access, and it can also be performing backup operations in either mode. However, because SQL is used to apply the changes to a logical standby database, users can access it for queries and reporting purposes at any time. This section describes the operational characteristics of physical and logical standby databases.

1.3.2 Physical Standby Databases

Oracle Corporation began shipping the standby database feature with Oracle release 8.0.4. Subsequent releases incorporated technical enhancements and user feedback that helped standby databases evolve as automated standby databases, managed standby databases, and the physical standby database disaster recovery feature available today with the Oracle9i Data Guard.

A physical standby database has its roots in media recovery. A physical standby database must be physically identical to the primary database. Put another way, standby on-disk database structures must be identical to the primary database on a block-for-block basis, because a recovery operation applies changes block-for-block using the physical row ID. The database schema, including indexes, must be the same, and the database cannot be opened for updates. If opened for updates, the standby database would have different row IDs, making continued recovery impossible.

You can operate a physical standby database in either of the following modes:

Although the standby database cannot be in more than one mode at the same time, you can change between the modes. For example, you can run in managed recovery mode, open in read-only mode to run reports, and then return to managed recovery mode to apply outstanding archived redo logs. You can repeat this cycle, alternating between reporting and recovery, as necessary.

In addition, you can perform online backup operations in either mode. Only backup copies from physical standby databases can be recovered to the primary database.

Physical standby databases provide the following benefits:

1.3.3 Logical Standby Databases

Oracle9i introduces logical standby databases, which answers Oracle users' requests for a standby database that provides data protection while simultaneously satisfying additional reporting requirements.

A logical standby database is logically identical to the primary database and can be used as a production database if the primary database is taken offline for routine maintenance or is damaged through human error, corruption, or a disaster.

Synchronization of a logical standby database with a primary database is done in SQL apply mode using standard Oracle archived redo logs. Log apply services automatically apply archived redo log information to the logical standby database by transforming transaction information into SQL statements (using LogMiner technology) and applying the SQL statements to the logical standby database.

Because the logical standby database is updated using SQL statements (unlike a physical standby database), it must remain open, and the tables that are maintained can be used simultaneously for other tasks such as reporting, summations, and queries. Moreover, these tasks can be optimized by creating additional indexes and materialized views on the maintained tables to those used on the primary database. Even though a logical standby database may have a different physical layout than its primary database, the logical standby database will support failover and switchover from the primary database.

The logical standby database is open in read/write mode, but the target tables for the regenerated SQL are available only in read-only mode for reporting purposes.

In addition to off-loading reporting and query processing from the primary database, logical standby databases provide the following benefits:

1.4 Log Transport Services and Log Apply Services

The log transport services component of Oracle9i Data Guard controls the automated transmission of archived redo logs from the primary database to one or more standby locations. In addition, you can use log transport services to set up the following:

Prior to Oracle9i, redo logs were transferred from the primary database to the standby database as they were archived. However, you can customize log transport services and log apply services for a variety of standby database configurations. Oracle9i Data Guard provides the DBA with great flexibility when defining archive destinations, archive completion requirements, I/O failure handling, and automated transmission restart capability.

For example:

1.5 Role Management Services

A database operates in one of two mutually exclusive roles: primary or standby. Role management services operate in conjunction with the log transport services and log apply services to change these roles dynamically as a planned transition called a switchover operation, or as a result of a database failure through either a graceful failover or a forced failover operation:

You should not fail over to a standby database except in an emergency, because the failover operation is an unplanned transition that may result in data loss. If you need to fail over before the primary and standby databases are resynchronized, and if the standby database becomes inaccessible, data on the primary database may diverge from data on standby databases. You can prevent this by using forced logging (to force the generation of redo records of changes against the database), standby redo logs, and the maximum protection mode with physical standby databases. Data loss may occur when you fail over to a standby database whose corresponding primary database is not in the maximum protection or maximum availability mode.

The amount of data differences or data loss you incur during a failover operation is directly related to how you configure the overall Data Guard configuration and log transport services, and can be prevented entirely by using maximum protection mode.

See Also:

Chapter 7, "Role Management Services"

1.6 Data Guard Architecture

Oracle9i Data Guard uses several processes to achieve the automation necessary for disaster recovery and high availability.

Figure 1-3 identifies the relationships of these processes to the operations they perform and the database objects on which they operate in the absence of the Data Guard broker. In the following figure, the standby redo logs are optionally configured for physical standby databases, except when running in maximum protection mode, which requires physical standby databases and standby redo logs. Logical standby databases do not use standby redo logs.

Figure 1-3 Data Guard Architecture

Text description of procarch.gif follows.

Text description of the illustration procarch.gif

1.7 Data Guard Interfaces

You can use the following interfaces to configure, implement, and manage a standby database:

See Chapter 3 for information on creating a physical standby database, Chapter 4 for information on creating a logical standby database, and Chapter 10 for scenarios.

1.8 Operational Requirements

Note the following operational requirements for maintaining a standby database:

Go to previous page Go to next page
Copyright © 1999, 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index