1
Introduction to Oracle Data Guard

Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions. Data Guard maintains these standby databases as transactionally consistent copies of the production database. Then, if the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the production role, thus minimizing the downtime associated with the outage. Data Guard can be used with traditional backup, restoration, and cluster techniques to provide a high level of data protection and data availability.

This chapter includes the following topics that describe the highlights of Oracle Data Guard:

• Data Guard Configurations
• Data Guard Services
• Data Guard Broker
• Data Guard Protection Modes
• Summary of Data Guard Benefits

1.1 Data Guard Configurations

A Data Guard configuration consists of one production database and up to nine standby databases. The databases in a Data Guard configuration are connected by Oracle Net and may be dispersed geographically. There are no restrictions on where the databases are located, provided that they can communicate with each other. For example, you can have a standby database on the same system as the production database, along with two standby databases on another system.

You can manage primary and standby databases using the command-line interface or the Data Guard broker, which includes a graphical user interface called Oracle Data Guard Manager.

1.1.1 Primary Database

A Data Guard configuration contains one production database, also referred to as the primary database, that functions in the primary role. This is the database that is accessed by most of your applications.

The primary database can be either a single-instance Oracle database or an Oracle Real Application Clusters database.

1.1.2 Standby Databases

A standby database is a transactionally consistent copy of the primary database. A standby database is initially created from a backup copy of the primary database. Once created, Data Guard automatically maintains the standby database by transmitting primary database redo data to the standby system and then applying the redo logs to the standby database.

Similar to a primary database, a standby database can be either a single-instance Oracle database or an Oracle Real Application Clusters database.

A standby database can be either a physical standby database or a logical standby database:

• Physical standby database

  Provides a physically identical copy of the primary database, with on-disk database structures that are identical to the primary database on a block-for-block basis. The database schema, including indexes, are the same. A physical standby database is kept synchronized with the primary database by recovering the redo data received from the primary database.

• Logical standby database

  Contains the same logical information as the production database, although the physical organization and structure of the data can be different. It is kept synchronized with the primary database by transforming the data in the redo logs received from the primary database into SQL statements and then executing the SQL statements on the standby database. A logical standby database can be used for other business purposes in addition to disaster recovery requirements. This allows users to access a logical standby database for queries and reporting purposes at any time. Thus, a logical standby database can be used concurrently for data protection and reporting.

1.1.3 Configuration Example

Figure 1-1 shows a Data Guard configuration that contains a primary database instance that transmits redo data to physical and logical standby databases that are both in remote locations from the primary database instance. In this configuration, a physical standby database is configured for disaster recovery and backup operations, and a logical standby database is configured primarily for reporting, but it can also be used for disaster recovery. You could configure either standby database at the same location as the primary database. However, for disaster recovery, Oracle Corporation recommends that you configure standby databases at remote locations.

Figure 1-1 shows a typical Data Guard configuration in which archived redo logs are being applied to both physical and logical standby databases.

Figure 1-1 Typical Data Guard Configuration

Text description of the illustration ls_config.gif

1.2 Data Guard Services

The following sections explain how Data Guard manages the transmission of redo data, the application of redo logs, and changes to the database roles:

• Log Transport Services

  Control the automated transfer of redo data within a Data Guard configuration.

• Log Apply Services

  Apply archived redo logs on the standby database to maintain transactional synchronization with the primary database.

• Role Management Services

  Change the role of a database from a standby database to a primary database, or from a primary database to a standby database using either a switchover or a failover operation.

1.2.1 Log Transport Services

Log transport services control the automated transfer of redo data within a Data Guard configuration.

Log transport services perform the following tasks:

• Transmit redo data from the primary system to the standby systems in the configuration
• Enforce the database protection modes (described in Section 1.4)

1.2.2 Log Apply Services

The redo data transmitted from the primary database is archived on the standby system in the form of archived redo logs. Log apply services automatically apply archived redo logs on the standby database to maintain transactional synchronization with the primary database and to allow transactionally consistent read-only access to the data.

The main difference between physical and logical standby databases is the manner in which log apply services apply the archived redo logs:

• For physical standby databases, Data Guard uses redo apply technology, which applies redo data on the standby database using standard recovery techniques of the Oracle database server.
• For logical standby databases, Data Guard uses SQL apply technology, which first transforms the received redo data into SQL statements and then executes the generated SQL statements on the logical standby database.

Log apply services perform the following tasks:

• Automatic application of archived redo logs on the standby database
• Automatic detection of missing redo logs on a standby system and automatic retrieval of missing redo logs from the primary database or another standby database

1.2.3 Role Management Services

An Oracle database operates in one of two roles: primary or standby. Using Data Guard, you can change the role of a database using either a switchover or a failover operation. The services that control these aspects are called role management services.

A switchover is a role reversal between the primary database and one of its standby databases. A switchover operation guarantees no data loss. This is typically done for planned maintenance of the primary system. During a switchover, the primary database transitions to a standby role and the standby database transitions to the primary role. The transition occurs without having to re-create either database.

A failover is an irreversible transition of a standby database to the primary role. This is only done in the event of a catastrophic failure of the primary database. The database administrator can configure Data Guard to ensure no data loss.

1.3 Data Guard Broker

The Data Guard broker is a distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations. The following list describes some of the operations that the broker automates or simplifies:

• Creating and enabling one or more Data Guard configurations, including setting up log transport services and log apply services.
• Creating a physical or logical standby database from a backup copy of the primary database.
• Adding new or existing standby databases to an existing Data Guard configuration.
• Managing an entire Data Guard configuration from any system in the configuration.
• Monitoring log apply rates, capturing diagnostic information, and detecting problems quickly with centralized monitoring, testing, and performance tools

1.4 Data Guard Protection Modes

In some situations, a business cannot afford to lose data at any cost. In other situations, the availability of the database may be more important than the loss of data. Some applications require maximum database performance and can tolerate a potential loss of data.

Data Guard provides three distinct modes of data protection:

• Maximum protection

  This mode offers the highest level of data protection. Data is synchronously transmitted to the standby database from the primary database, and transactions are not committed on the primary database unless the redo data is available on at least one standby database configured in this mode. If the last standby database configured in this mode becomes unavailable, processing stops on the primary database. This mode guarantees no data loss.

• Maximum availability

  This mode is similar to the maximum protection mode, including the guarantee of no data loss. However, if a standby database becomes unavailable (for example, due to network connectivity problems), processing continues on the primary database. When the fault is corrected, the standby database is resynchronized with the primary database. If there is a need to fail over before the standby database is resynchronized, some data may be lost.

• Maximum performance

  This mode offers slightly less data protection on the primary database, but higher performance than maximum availability mode. In this mode, as the primary database processes transactions, redo data is asynchronously shipped to the standby database. The commit operation on the primary database does not wait for the standby database to acknowledge receipt of redo data before completing write operations on the primary database. If any standby destination becomes unavailable, processing continues on the primary database, and there is little effect on primary database performance.

1.5 Summary of Data Guard Benefits

Data Guard offers many overall benefits, as well as benefits provided by each kind of standby database. Note that you need to consider all benefits, including those specific to each type of standby database, when you design your Data Guard configuration.

Data Guard offers these benefits:

• Disaster recovery, data protection and high availability

  Data Guard provides an efficient and comprehensive disaster recovery, data protection, and high availability solution. Easy-to-manage switchover and failover capabilities allow role reversals between primary and standby databases, minimizing the downtime of the primary database for planned and unplanned outages.

• Complete data protection

  With its standby databases, Data Guard guarantees no data loss, even in the face of unforeseen disasters. A standby database provides a safeguard against data corruption and user errors. Storage level physical corruptions on the primary database do not propagate to the standby database. Similarly, logical corruptions or user errors that cause the primary database to be permanently damaged can be resolved. Finally, the redo data is validated when it is applied to the standby database.

• Efficient use of system resources

  The standby database tables that are updated with redo logs received from the primary database can be used for other tasks such as backup operations, reporting, summations, and queries, thereby reducing the primary database workload necessary to perform these tasks, saving valuable CPU and I/O cycles. With a logical standby database, users can perform normal data manipulation operations on tables in schemas that are not updated from the primary database. A logical standby database can remain open while the tables are updated from the primary database, and the tables are simultaneously available for read-only access. Finally, additional indexes and materialized views can be created on the maintained tables for better query performance and to suit specific business requirements.

• Flexibility in data protection to balance availability against performance requirements

  Oracle Data Guard offers maximum protection, maximum availability, and maximum performance modes to help enterprises balance data availability against system performance requirements.

• Centralized and simple management

  The Data Guard broker provides the Data Guard Manager graphical user interface and the Data Guard command-line interface to automate management and operational tasks across multiple databases in a Data Guard configuration. The broker also monitors all of the systems within a single Data Guard configuration.

• Automatic gap detection and resolution

  If connectivity is lost between the primary and one or more standby databases (for example, due to network problems), redo data being generated on the primary database cannot be sent to those standby databases. Once connectivity is re-established, the missing log sequence (or the gap) is automatically detected by Data Guard, and the necessary redo logs are automatically transmitted to the standby databases. The standby databases are resynchronized with the primary database, with no manual intervention by the DBA.