Release 2 (9.2)
Part Number A96653-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Data Guard Concepts and Administration Release 2 (9.2) Part Number A96653-01 |
|
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:
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:
A physical standby database is physically identical to the primary database, with on-disk database structures that are identical to the primary database on a block-for-block basis. The physical standby database is updated by performing recovery. It can either be recovering data or open for read-only reporting.
A logical standby database is logically identical to the primary database. The logical standby database is updated using SQL statements. The tables in a logical standby database can be used simultaneously for recovery and for other tasks such as reporting, summations, and queries.
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.
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.
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.
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:
An Oracle9i Data Guard configuration is a collection of loosely connected systems that combine the primary database and the standby databases into a single, easily managed disaster recovery solution. The databases in a Data Guard configuration are connected by Oracle Net and may be dispersed geographically.
The Data Guard broker distributed management framework provides the Data Guard Manager graphical user interface and the Data Guard command-line interface to automate the management and operational tasks across the multiple databases in a Data Guard configuration. The broker also monitors all of the systems within a single standby database configuration.
These failover and switchover capabilities allow you to perform planned and unplanned role reversals between primary and standby databases.
For standby databases, the risk of physical corruptions is reduced. Primary-side physical corruptions, due to device failure, are unlikely to propagate through the archived redo logs that are transported to the standby database.
You can resolve user errors or perform a failover operation when the primary database is permanently damaged. For example, if a critical table is accidentally dropped from the primary database and the change has not yet been applied to the standby database, you can fail over to a standby database or use it to transport the relevant tablespaces back to the primary database.
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.
Text description of the illustration odg_new.gif
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.
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.
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:
In managed recovery mode, the primary database archives redo logs to the standby database and log apply services automatically apply the redo logs to the standby database.
To use the standby database for reporting purposes, open it in read-only mode. Log apply services cannot apply redo logs to the standby database when it is in this mode, but you can execute queries on the database. The primary database continues to archive to the standby site so long as the standby instance is mounted.
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:
A physical standby database provides data protection and disaster recovery capabilities for all Oracle databases, with no restrictions on datatypes, types of tables, or types of data definition language (DDL) and data manipulation language (DML) operations.
A physical standby database provides better apply performance than logical standby databases, especially when there are a large number of updates on the primary system and a high rate of redo data is generated. Log apply services are better able to keep physical standby databases up-to-date because the process of translating the redo data to SQL statements and reexecuting the SQL on a logical standby database takes more time and uses more system resources (memory and I/O operations) than using media recovery to apply the changes to a physical standby database.
A physical standby database can off-load backup operations from the primary system. Backup copies from physical standby databases can be recovered on the primary database.
A physical standby database can be used to run reports while the standby database is in read-only mode.
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:
A logical standby database is an open production database and can be used concurrently for both data protection and reporting.
Because the data in a logical standby database can be presented with a different physical layout, you can create additional indexes and materialized views to suit your reporting and query requirements.
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:
This type of destination allows off-site archiving of redo logs. An archive log repository is created by using a standby control file, starting the instance, and mounting the database. This database contains no datafiles and cannot be used for primary database recovery.
A cross-instance archival database environment is possible on both the primary and standby databases. Within a Real Application Clusters environment, each instance directs its archived redo logs to a single instance of the cluster. This instance, known as the recovery instance, is typically the instance where managed recovery is performed. The recovery instance typically has a tape drive available for RMAN backup and restore support.
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:
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:
Switchover operations provide the means to transition database roles from a primary role to a standby role and from a standby role to a primary role.
A no-data-loss failover is possible if the corresponding primary database is operating in either the maximum protection or maximum availability data protection mode.
Minimal-data-loss failover occurs when primary database modifications are not yet available on the standby site at the time the failover operation occurs. Minimal data loss is possible when operating in a data protection mode such as maximum performance mode, when the failover operation occurs.
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.
Oracle9i Data Guard uses several processes to achieve the automation necessary for disaster recovery and high availability.
The log writer process (LGWR) collects transaction redo and updates the online redo logs.
The archiver process (ARCn) creates a copy of the online redo logs, either locally or remotely, for standby databases.
The fetch archive log (FAL) process provides a client/server mechanism for resolving gaps detected in the range of archived redo logs generated at the primary database and received at the standby database. The FAL client requests the transfer of archived redo log files automatically when it detects a gap in the redo logs received by the standby database. The FAL server typically runs on the primary database and services the FAL requests coming from the FAL client. The FAL client and server are configured using the FAL_CLIENT and FAL_SERVER initialization parameters that are set on the standby location.
For physical standby databases only, the MRP applies archived redo log information to the physical standby database.
For logical standby databases only, the LSP applies archived redo log information to the logical standby database, using SQL interfaces.
The DMON processes work cooperatively to manage the primary and standby databases as a unified configuration. The DMON processes work together to execute switchover and failover operations, monitor the status of the databases, and manage log transport services and log apply services.
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.
Text description of the illustration procarch.gif
You can use the following interfaces to configure, implement, and manage a standby database:
Several SQL statements use a STANDBY keyword to specify operations on a standby database. Other SQL statements do not include standby-specific syntax, but are useful for performing operations on a standby database. Chapter 13 describes the relevant statements.
Several initialization parameters are used to define the Data Guard environment. Table 11-1 describes relevant initialization parameters.
The Oracle9i Data Guard Manager graphical user interface (GUI) is a broker interface that you can use to automate many of the tasks involved in configuring and monitoring a Data Guard environment.
| See Also:
Oracle9i Data Guard Broker and the Oracle9i Data Guard Manager online help for information on the Data Guard Manager GUI and the Oracle9i Data Guard Manager Wizard |
The Data Guard command-line interface is an alternative to using the Oracle9i Data Guard Manager GUI. The command-line interface is useful if you want to use the broker to manage a Data Guard configuration from batch programs or scripts.
You can use Recovery Manager (RMAN) to create and back up 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.
Note the following operational requirements for maintaining a standby database:
FORCE LOGGING at the primary database before taking datafile backups for standby creation. Keep the database in FORCE LOGGING mode as long as the standby database is required.
|
 Copyright © 1999, 2002 Oracle Corporation. All Rights Reserved. |
|