Skip Headers

Oracle® Data Guard Concepts and Administration
10g Release 1 (10.1)

Part Number B10823-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

2
Getting Started with Data Guard

A Data Guard configuration contains a primary database and up to nine associated standby databases. This chapter describes the following considerations for getting started with Data Guard:

2.1 Standby Database Types

A standby database is a transactionally consistent copy of an Oracle production database that is initially created from a backup copy of the primary database. Once the standby database is created and configured, Data Guard automatically maintains the standby database by transmitting primary database redo data to the standby system, where the redo data is applied to the standby database.

A standby database can be one of two types: a physical standby database or a logical standby database. If needed, either type of standby database can assume the role of the primary database and take over production processing. A Data Guard configuration can include physical standby databases, logical standby databases, or a combination of both types.

The following sections describe standby databases in more detail. See Oracle High Availability Architecture and Best Practices for information that can help you determine which type is most appropriate for your business.

2.1.1 Physical Standby Databases

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 database schema, including indexes, are identical.

Data Guard maintains a physical standby database by performing Redo Apply. When it is not performing recovery, a physical standby database can be open in read-only mode.

Although the physical standby database cannot perform both Redo Apply and be opened in read-only mode at the same time, you can switch between them. For example, you can run a physical standby database to perform Redo Apply, then open it in read-only mode for applications to run reports, and then change it back to perform Redo Apply to apply any outstanding archived redo log files. You can repeat this cycle, alternating between Redo Apply and read-only, as necessary.

In either case, the physical standby database is available to perform backups. Furthermore, the physical standby database will continue to receive redo data even if archived redo log files or standby redo log files are not being applied at that moment.

Benefits of a Physical Standby Database

A physical standby database provides the following benefits:

2.1.2 Logical Standby Databases

A logical standby database is initially created as an identical copy of the primary database, but it later can be altered to have a different structure. The logical standby database is updated by executing SQL statements. This allows users to access the standby database for queries and reporting at any time. Thus, the logical standby database can be used concurrently for data protection and reporting operations.

Data Guard automatically applies information from the archived redo log file or standby redo log file to the logical standby database by transforming the data in the log files into SQL statements and then executing the SQL statements on the logical standby database. Because the logical standby database is updated using SQL statements, it must remain open. Although the logical standby database is opened in read/write mode, its target tables for the regenerated SQL are available only for read-only operations. While those tables are being updated, they 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.

A logical standby database has some restrictions on datatypes, types of tables, and types of DDL and DML operations. Section 4.1.1 describes the unsupported datatypes and storage attributes for tables.

Benefits of a Logical Standby Database

A logical standby database provides similar disaster recovery, high availability, and data protection benefits as a physical standby database. It also provides the following specialized benefits:

2.2 User Interfaces for Administering Data Guard Configurations

You can use the following interfaces to configure, implement, and manage a Data Guard configuration:

Several initialization parameters are used to define the Data Guard environment. See Chapter 11 for a list of the relevant initialization parameters.

The Data Guard broker command-line interface is an alternative to using the Enterprise 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. See Oracle Data Guard Broker for complete information.

2.3 Data Guard Operational Prerequisites

The following sections describe operational requirements for using Data Guard:

2.3.1 Hardware and Operating System Requirements

The following list describes hardware and operating system requirements for using Data Guard:

2.3.2 Oracle Software Requirements

The following list describes Oracle software requirements for using Data Guard:

2.4 Standby Database Directory Structure Considerations

The directory structure of the various standby databases is important because it determines the path names for the standby datafiles, archived redo log files, and standby redo log files. If possible, the datafiles, log files, and control files on the primary and standby systems should have the same names and path names and use Optimal Flexible Architecture (OFA) naming conventions. The archival directories on the standby database should also be identical between sites, including size and structure. This strategy allows other operations such as backups, switchovers, and failovers to execute the same set of steps, reducing the maintenance complexity.

Otherwise, you must set the filename conversion parameters (as shown in Table 2-1) or rename the datafile. Nevertheless, if you need to use a system with a different directory structure or place the standby and primary databases on the same system, you can do so with a minimum of extra administration.

The three basic configuration options are illustrated in Figure 2-1. These include:

Figure 2-1 Possible Standby Configurations

Text description of sbr81097.gif follows.

Text description of the illustration sbr81097.gif

Table 2-1 describes possible configurations of primary and standby databases and the consequences of each. In the table, note that the service name defaults to the global database name, which is a concatenation of the database name (DB_NAME) and domain name (DB_DOMAIN) parameters. If you do not explicitly specify unique service names when the primary and standby databases reside on the same system, the same default global database name will be in effect for both the primary and standby databases.

Table 2-1  Standby Database Location and Directory Options
Standby System Directory Structure Consequences

Same as primary system

Different than primary system (required)

  • You must set the DB_UNIQUE_NAME initialization parameter.
  • You can either manually rename files or set up the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT initialization parameters on the standby database to automatically update the path names for primary database datafiles and archived redo log files and standby redo log files in the standby database control file. (See Section 3.1.3.)
  • You must explicitly set up unique service names for the primary and standby databases with the SERVICE_NAMES initialization parameter.
  • The standby database does not protect against disasters that destroy the system on which the primary and standby databases reside, but it does provide switchover capabilities for planned maintenance.

Separate system

Same as primary system

  • You do not need to rename primary database files, archived redo log files, and standby redo log files in the standby database control file, although you can still do so if you want a new naming scheme (for example, to spread the files among different disks).
  • By locating the standby database on separate physical media, you safeguard the data on the primary database against disasters that destroy the primary system.

Separate system

Different than primary system

  • You can either manually rename files or set up the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT initialization parameters on the standby database to automatically rename the datafiles (see Section 3.1.3).
  • By locating the standby database on separate physical media, you safeguard the data on the primary database against disasters that destroy the primary system.

2.5 Online Redo Logs, Archived Redo Logs, and Standby Redo Logs

The most crucial structures for Data Guard recovery operations are online redo logs, archived redo logs, and standby redo logs. Redo data transmitted from the primary database is received by the remote file server (RFS) process on the standby system where the RFS process writes the redo data to archived log files or standby redo log files. Redo data can be applied either after the redo is written to the archived redo log file or standby redo log file, or, if real-time apply is enabled, directly from the standby redo log file as it is being filled.

This documentation assumes that you already understand the concepts behind online redo logs and archived redo logs. Section 2.5.1 supplements the basic concepts by providing information that is specific to Data Guard configurations. Section 2.5.2 provides detailed information about using standby redo log files.

See Oracle Database Administrator's Guide for more information about redo logs and archive logs, and Section 6.2.1 for information about real-time apply.

2.5.1 Online Redo Logs and Archived Redo Logs

Both online redo logs and archived redo logs are required in a Data Guard environment:

Both the size of the online redo log files and the frequency with which a log switch occurs can affect the generation of the archived redo log files at the primary site. The Oracle High Availability Architecture and Best Practices provides recommendations for log group sizing.

An Oracle database will attempt a checkpoint at each log switch. Therefore, if the size of the online redo log file is too small, frequent log switches lead to frequent checkpointing and negatively affect system performance on the standby database.

2.5.2 Standby Redo Logs

A standby redo log is similar in all ways to an online redo log, except that a standby redo log is used only when the database is running in the standby role to store redo data received from the primary database.

A standby redo log is required to implement:

Configuring standby redo log files is highly recommended on all standby databases in a Data Guard configuration, because they provide a number of advantages:

Section 5.6.2 describes how to configure standby redo log files.