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:

• Choosing a Standby Database Type
• Choosing a Data Guard User Interface
• Data Guard Operational Prerequisites
• Standby Database Directory Structure Considerations

2.1 Choosing a Standby Database Type

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 archived, and then applying the redo logs 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.

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, must be the same.

Data Guard maintains a physical standby database by performing managed recovery operations. When it is not performing recovery operations, a physical standby database can be open for read-only operations.

• Managed recovery

  The physical standby database is maintained by applying the archived redo logs on the standby system using the Oracle recovery mechanism. The recovery operation applies changes block-for-block using the physical row ID. The database cannot be opened for read or read/write operations while redo data is being applied.

• Open read-only

  The physical standby database can be open for read-only operations so that you can execute queries on the database. While open for read-only operations, the standby database can continue to receive redo logs but application of the data from the logs is deferred until the database resumes managed recovery operations.

Although the physical standby database cannot perform both managed recovery and read-only operations at the same time, you can switch between them. For example, you can run a physical standby database to perform managed recovery operations, then open it so applications can perform read-only operations to run reports, and then change it back to perform managed recovery operations to apply outstanding archived redo logs. You can repeat this cycle, alternating between managed recovery and read-only operations, as necessary.

In either case, the physical standby database is available to perform backup operations. Furthermore, the physical standby database will continue to receive redo logs even if they are not being applied at that moment.

Benefits of a Physical Standby Database

A physical standby database provides the following benefits:

• Disaster recovery and high availability

  A physical standby database enables a robust and efficient disaster recovery and high availability solution. Easy-to-manage switchover and failover capabilities allow easy role reversals between primary and physical standby databases, minimizing the downtime of the primary database for planned and unplanned outages.

• Data protection

  Using a physical standby database, Data Guard can ensure no data loss, even in the face of unforeseen disasters. A physical standby database supports all datatypes, and DDL and DML operations that the primary can support. It also provides safeguard against data corruptions 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.

• Reduction in primary database workload

  Oracle Recovery Manager (RMAN) can use physical standby databases to off-load backups from the primary database saving valuable CPU and I/O cycles. The physical standby database can also be opened in read-only mode to perform reporting and queries.

• Performance

  The redo apply technology used by the physical standby database applies changes using low-level recovery mechanisms, which bypass all SQL level code layers and therefore is the most efficient mechanism for applying changes. This makes the redo apply technology a highly efficient mechanism to propagate changes among databases.

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 applying SQL statements. This allows users to access the standby database for queries and reporting purposes at any time. Thus, the logical standby database can be used concurrently for data protection and reporting operations.

Data Guard automatically applies archived redo log information to the logical standby database by transforming data in the redo logs 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 open for read/write operations, 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 data definition language (DDL) and data manipulation language (DML) operations. Unsupported datatypes and tables are described in more detail in Section 4.1.4.

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:

• Efficient use of standby hardware resources

  A logical standby database can be used for other business purposes in addition to disaster recovery requirements. It can host additional databases schemas beyond the ones that are protected in a Data Guard configuration, and users can perform normal DDL or DML operations on those schemas any time. Because the logical standby tables that are protected by Data Guard can be stored in a different physical layout than on the primary database, additional indexes and materialized views can be created to improve query performance and suit specific business requirements.

• Reduction in primary database workload

  A logical standby database can remain open at the same time its tables are updated from the primary database, and those tables are simultaneously available for read access. This makes a logical standby database an excellent choice to do queries, summations, and reporting activities, thereby off-loading the primary database from those tasks and saving valuable CPU and I/O cycles.

2.2 Choosing a Data Guard User Interface

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

• Command-line interface:
  • SQL*Plus

    Several SQL*Plus 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.

    See Also: Chapter 13 describes the relevant statements

• Data Guard broker command-line interface

• Oracle Data Guard Manager

  The Oracle Data Guard Manager is the GUI that automates many of the tasks involved in creating, 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 discussions and examples in this manual use the Data Guard broker command-line interface.

2.3 Data Guard Operational Prerequisites

The following are operational requirements for using Data Guard:

• The same edition of Oracle Enterprise Edition must be installed on all systems in a Data Guard configuration.
• The primary database must run in ARCHIVELOG mode.
• The same Oracle software release must be used on both the primary and standby databases. The operating system running on the primary and standby locations must be the same, but the operating system release does not need to be the same. In addition, the standby database can use a different directory structure from the primary database.
• The hardware and operating system architecture on the primary and standby locations must be the same. For example, this means a Data Guard configuration with a primary database on a 32-bit Sun system must have a standby database that is configured on a 32-bit Sun system. Similarly, a primary database on a 64-bit HP-UX system must be configured with a standby database on a 64-bit HP-UX system, and a primary database on a 32-bit Linux on Intel system must be configured with a standby database on a 32-bit Linux on Intel system, and so forth.
• The primary database can be a single instance database or a multi-instance Real Application Clusters database. The standby databases can be single instance databases or multi-instance Real Application Clusters databases, and these standby databases can be a mix of both physical and logical types.
• The hardware (for example, the number of CPUs, memory size, storage configuration) can be different between the primary and standby systems. If the standby system is smaller than the primary system, you may have to restrict the work that can be done on the standby system after a switchover or failover operation. Also, the standby system must have enough resources available to receive and apply all redo data from the primary database. The logical standby database requires additional resources to translate the redo data to SQL statements and then execute the SQL on the logical standby database.
• Each primary database and standby database must have its own control file.
• If you place your primary and standby databases on the same system, you must adjust the initialization parameters correctly.
• To protect against unlogged direct writes in the primary database that cannot be propagated to the standby database, turn on FORCE LOGGING at the primary database before performing datafile backup operations for standby creation. Keep the database in FORCE LOGGING mode as long as the standby database is required.
• If you are currently running Oracle Data Guard on Oracle8i database software, see Oracle9i Database Migration for complete information on upgrading to Oracle Data Guard on Oracle9i database software.
• The user accounts you use to manage the primary and standby database instances must have SYSDBA system privileges.

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 and redo logs. If you have a standby database on the same system as the primary database, you must use a different directory structure; otherwise, the standby database attempts to overwrite the primary database files.

For standby databases, use the same path names for the standby files if possible. Otherwise, you will need to set filename conversion parameters (as shown in Table 2-1). 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:

• A standby database on the same system as the primary database that uses a different directory structure than the primary system (Standby1).
• A standby database on a separate system that uses the same directory structure as the primary system (Standby2). This is the recommended method.
• A standby database on a separate system that uses a different directory structure than the primary system (Standby3).

Figure 2-1 Possible Standby Configurations

Text description of the illustration sbr81097.gif

Table 2-1 describes possible configurations of primary and standby databases and the consequences of each.

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 LOCK_NAME_SPACE initialization parameter. You must manually rename primary database datafiles and redo logs in the standby database control file (see Appendix B). For physical standby databases, you could alternatively 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 6.2.4). The standby database does not protect against disasters that destroy the system on which both 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 and redo logs 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). Using separate physical media for your databases safeguards your primary data.
Separate system	Different than primary system	You must manually rename primary database datafiles and redo logs in the standby database control file (see Appendix B). For physical standby databases, you could alternatively 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 6.2.4). Using separate physical media for your databases safeguards your primary data.