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, 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.
With Data Guard, administrators can optionally improve production database performance by offloading resource-intensive backup and reporting operations to standby systems.
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
  
• Data Guard and Complementary Technologies
  
• Summary of Data Guard Benefits
  

1.1 Data Guard Configurations

A Data Guard configuration consists of one production database and one or more 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 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 other systems at remote locations.
You can manage primary and standby databases using the SQL command-line interfaces or the Data Guard broker interfaces, including a command-line interface (DGMGRL) and a graphical user interface that is integrated in Oracle Enterprise 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. Using a backup copy of the primary database, you can create up to nine standby databases and incorporate them in a Data Guard configuration. Once created, Data Guard automatically maintains each standby database by transmitting redo data from the primary database and then applying the redo 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, though Redo Apply, which recovers the redo data received from the primary database and applies the redo to the physical standby database.
  A physical standby database can be used for business purposes other than disaster recovery on a limited basis.
  
• Logical standby database
  Contains the same logical information as the production database, although the physical organization and structure of the data can be different. The logical standby database is kept synchronized with the primary database though SQL Apply, which transforms the data in the redo 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. Also, using a logical standby database, you can upgrade Oracle Database software and patch sets with almost no downtime. Thus, a logical standby database can be used concurrently for data protection, reporting, and database upgrades.
  

1.1.3 Configuration Example

Figure 1-1 shows a typical Data Guard configuration that contains a primary database that transmits redo data to a standby database. The standby database is remotely located from the primary database for disaster recovery and backup operations. You can configure the standby database at the same location as the primary database. However, for disaster recovery purposes, Oracle recommends you configure standby databases at remote locations.
Figure 1-1 shows a typical Data Guard configuration in which redo is being applied out of standby redo log files to a standby database.

Figure 1-1 Typical Data Guard Configuration

Description of "Figure 1-1 Typical Data Guard Configuration"

1.2 Data Guard Services

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

• Redo Transport Services
  Control the automated transfer of redo data from the production database to one or more archival destinations.
  
• Log Apply Services
  Apply redo data on the standby database to maintain transactional synchronization with the primary database. Redo data can be applied either from archived redo log files, or, if real-time apply is enabled, directly from the standby redo log files as they are being filled, without requiring the redo data to be archived first at the standby database.
  
• Role Transitions
  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 Redo Transport Services

Redo transport services control the automated transfer of redo data from the production database to one or more archival destinations.
Redo transport services perform the following tasks:

• Transmit redo data from the primary system to the standby systems in the configuration
  
• Manage the process of resolving any gaps in the archived redo log files due to a network failure
  
• Enforce the database protection modes (described in Section 1.4)
  
• Automatically detect missing or corrupted archived redo log files on a standby system and automatically retrieve replacement archived redo log files from the primary database or another standby database
  

1.2.2 Log Apply Services

The redo data transmitted from the primary database is written on the standby system into standby redo log files, if configured, and then archived into archived redo log files. Log apply services automatically apply the redo data on the standby database to maintain consistency with the primary database. It also allows 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 data:

• For physical standby databases, Data Guard uses Redo Apply technology, which applies redo data on the standby database using standard recovery techniques of an Oracle database, as shown in Figure 1-2.
  

Figure 1-2 Automatic Updating of a Physical Standby Database

Description of "Figure 1-2 Automatic Updating of a Physical Standby Database "

• 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, as shown in Figure 1-3.
  

Figure 1-3 Automatic Updating of a Logical Standby Database

Description of "Figure 1-3 Automatic Updating of a Logical Standby Database"

1.2.3 Role Transitions

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.
A switchover is a role reversal between the primary database and one of its standby databases. A switchover ensures 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 when the primary database is unavailable. Failover is performed only in the event of a catastrophic failure of the primary database, and the failover results in a transition of a standby database to the primary role. The database administrator can configure Data Guard to ensure no data loss.
The role transitions described in this documentation are invoked manually using SQL statements. You can also use the Oracle Data Guard broker to simplify role transitions and automate failovers using Oracle Enterprise Manager or the DGMGRL command-line interface, as described in Section 1.3.

1.3 Data Guard Broker

The Data Guard broker is a distributed management framework that automates the creation, maintenance, and monitoring of Data Guard configurations. You can use either the Oracle Enterprise Manager graphical user interface (GUI) or the Data Guard command-line interface (DGMGRL) to:

• Create and enable Data Guard configurations, including setting up redo transport services and log apply services
  
• Manage an entire Data Guard configuration from any system in the configuration
  
• Manage and monitor Data Guard configurations that contain Real Application Clusters primary or standby databases
  
• Simplify switchovers and failovers by allowing you to invoke them using either a single key click in Oracle Enterprise Manager or a single command in the DGMGRL command-line interface.
  
• Enable fast-start failover to fail over automatically when the primary database becomes unavailable. When fast-start failover is enabled, the Data Guard broker determines if a failover is necessary and initiates the failover to the specified target standby database automatically, with no need for DBA intervention and with no loss of data.
  

In addition, Oracle Enterprise Manager automates and simplifies:

• 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
  
• Monitoring log apply rates, capturing diagnostic information, and detecting problems quickly with centralized monitoring, testing, and performance tools
  

See Also:

Oracle Data Guard Broker for more information

1.3.1 Using Oracle Enterprise Manager

Oracle Enterprise Manager, also referred to as Enterprise Manager, provides a web-based interface for viewing, monitoring, and administering primary and standby databases in a Data Guard configuration. Enterprise Manager's easy-to-use interfaces combined with the broker's centralized management and monitoring of the Data Guard configuration enhance the Data Guard solution for high availability, site protection, and data protection of an enterprise.
From the Enterprise Manager Central Console, all management operations can be performed locally or remotely. You can view home pages for Oracle databases, including primary and standby databases and instances, create or add existing standby databases, start and stop instances, monitor instance performance, view events, schedule jobs, and perform backup and recovery operations. See Oracle Data Guard Broker and the Oracle Enterprise Manager online help system.
Figure 1-4 shows the Data Guard management overview page in Enterprise Manager.

Figure 1-4 Data Guard Overview Page in Oracle Enterprise Manager

Description of "Figure 1-4 Data Guard Overview Page in Oracle Enterprise Manager"

1.3.2 Using the Data Guard Command-Line Interface

The Data Guard command-line interface (DGMGRL) enables you to control and monitor a Data Guard configuration from the DGMGRL prompt or within scripts. You can perform most of the activities required to manage and monitor the databases in the configuration using DGMGRL. See Oracle Data Guard Broker for complete DGMGRL reference information and examples.

1.4 Data Guard Protection Modes

In some situations, a business cannot afford to lose data. 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 some small amount of data loss. The following descriptions summarize the three distinct modes of data protection.
Maximum protection This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover each transaction must be written to both the local online redo log and to the standby redo log on at least one standby database before the transaction commits. To ensure data loss cannot occur, the primary database shuts down if a fault prevents it from writing its redo stream to the standby redo log of at least one transactionally consistent standby database.
Maximum availability This protection mode provides the highest level of data protection that is possible without compromising the availability of the primary database. Like maximum protection mode, a transaction will not commit until the redo needed to recover that transaction is written to the local online redo log and to the standby redo log of at least one transactionally consistent standby database. Unlike maximum protection mode, the primary database does not shut down if a fault prevents it from writing its redo stream to a remote standby redo log. Instead, the primary database operates in maximum performance mode until the fault is corrected, and all gaps in redo log files are resolved. When all gaps are resolved, the primary database automatically resumes operating in maximum availability mode.
This mode ensures that no data loss will occur if the primary database fails, but only if a second fault does not prevent a complete set of redo data from being sent from the primary database to at least one standby database.
Maximum performance This protection mode (the default) provides the highest level of data protection that is possible without affecting the performance of the primary database. This is accomplished by allowing a transaction to commit as soon as the redo data needed to recover that transaction is written to the local online redo log. The primary database's redo data stream is also written to at least one standby database, but that redo stream is written asynchronously with respect to the transactions that create the redo data.
When network links with sufficient bandwidth are used, this mode provides a level of data protection that approaches that of maximum availability mode with minimal impact on primary database performance.
The maximum protection and maximum availability modes require that standby redo log files are configured on at least one standby database in the configuration. All three protection modes require that specific log transport attributes be specified on the LOG_ARCHIVE_DEST_n initialization parameter to send redo data to at least one standby database. See Section 5.6 for complete information about the data protection modes.

1.5 Data Guard and Complementary Technologies

Oracle Database provides several unique technologies that complement Data Guard to help keep business critical systems running with greater levels of availability and data protection than when using any one solution by itself. The following list summarizes some Oracle high-availability technologies:

• Oracle Real Application Clusters (RAC)
  RAC enables multiple independent servers that are linked by an interconnect to share access to an Oracle database, providing high availability, scalability, and redundancy during failures. RAC and Data Guard together provide the benefits of both system-level, site-level, and data-level protection, resulting in high levels of availability and disaster recovery without loss of data:
  
  • RAC addresses system failures by providing rapid and automatic recovery from failures, such as node failures and instance crashes. It also provides increased scalability for applications.
    
  • Data Guard addresses site failures and data protection through transactionally consistent primary and standby databases that do not share disks, enabling recovery from site disasters and data corruption.
    
  Many different architectures using RAC and Data Guard are possible depending on the use of local and remote sites and the use of nodes and a combination of logical and physical standby databases. See Appendix D, "Data Guard and Real Application Clusters" and Oracle Database High Availability Overview for RAC and Data Guard integration.
  
• Flashback Database
  The Flashback Database feature provides fast recovery from logical data corruption and user errors. By allowing you to flash back in time, previous versions of business information that might have been erroneously changed or deleted can be accessed once again. This feature:
  
  • Eliminates the need to restore a backup and roll forward changes up to the time of the error or corruption. Instead, Flashback Database can roll back an Oracle database to a previous point-in-time, without restoring datafiles.
    
  • Provides an alternative to delaying the application of redo to protect against user errors or logical corruptions. Therefore, standby databases can be more closely synchronized with the primary database, thus reducing failover and switchover times.
    
  • Avoids the need to completely re-create the original primary database after a failover. The failed primary database can be flashed back to a point in time before the failover and converted to be a standby database for the new primary database.
    
  See Oracle Database Backup and Recovery Advanced User's Guide for information about Flashback Database, and Section 6.2.2 for information delaying the application of redo data.
  
• Recovery Manager (RMAN)
  RMAN is an Oracle utility that simplifies backing up, restoring, and recovering database files. Like Data Guard, RMAN is a feature of the Oracle database and does not require separate installation. Data Guard is well integrated with RMAN, allowing you to:
  
  • Use the Recovery Manager DUPLICATE command to create a standby database from backups of your primary database.
    
  • Take backups on a physical standby database instead of the production database, relieving the load on the production database and enabling efficient use of system resources on the standby site. Moreover, backups can be taken while the physical standby database is applying redo.
    
  • Help manage archived redo log files by automatically deleting the archived redo log files used for input after performing a backup.
    
  See Appendix F, "Creating a Standby Database with Recovery Manager" and Oracle Database Backup and Recovery Basics.
  

1.6 Summary of Data Guard Benefits

Data Guard offers these benefits:

• Disaster recovery, data protection, and high availability
  Data Guard provides an efficient and comprehensive disaster recovery 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
  Data Guard can ensure 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 data received from the primary database can be used for other tasks such as backups, 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 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.
  
• 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 a connection is reestablished, the missing archived redo log files (referred to as a gap) are automatically detected by Data Guard, which then automatically transmits the missing archived redo log files to the standby databases. The standby databases are synchronized with the primary database, without manual intervention by the DBA.
  
• Centralized and simple management
  The Data Guard broker provides a graphical user interface and a 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.
  
• Integration with Oracle Database
  Data Guard is a feature of Oracle Database Enterprise Edition and does not require separate installation.
  
• Automatic role transitions
  When fast-start failover is enabled, the Data Guard broker automatically fails over to a synchronized standby site in the event of a disaster at the primary site, requiring no intervention by the DBA. In addition, applications are automatically notified of the role transition.
  

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:

• Standby Database Types
  
• User Interfaces for Administering Data Guard Configurations
  
• Data Guard Operational Prerequisites
  
• Standby Database Directory Structure Considerations
  
• Online Redo Logs, Archived Redo Logs, and Standby Redo Logs
  

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.

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, or it can be opened temporarily in read/write mode if Flashback Database is enabled.

• Redo Apply
  The physical standby database is maintained by applying redo data from the archived redo log files or directly from standby redo log files on the standby system using the Oracle recovery mechanism. The recovery operation applies changes in redo blocks to data block using the data-block address. The database cannot be opened while redo is being applied.
  
• Open read-only
  A physical standby database can be open in read-only mode so that you can execute queries on the database. While opened in read-only mode, the standby database can continue to receive redo data, but application of the redo data from the log files is deferred until the database resumes Redo Apply.
  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 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.
  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.
  
• Open read/write
  A physical standby database can also be opened for read/write access for purposes such as creating a clone database or for read/write reporting. While opened in read/write mode, the standby database does not receive redo data from the primary database and cannot provide disaster protection.
  The physical standby database can be opened temporarily in read/write mode for development, reporting, or testing purposes, and then flashed back to a point in the past to be reverted back to a physical standby database. When the database is flashed back, Data Guard automatically synchronizes the standby database with the primary database, without the need to re-create the physical standby database from a backup copy of the primary database.
  
  See Also:

  Section 12.6 for usage examples

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 all DDL and DML operations that the primary database can support. It also provides a 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 for 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; therefore, it is the most efficient mechanism for applying high volumes of redo data.
  

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:

• 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 database 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 User Interfaces for Administering Data Guard Configurations

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

• Oracle Enterprise Manager
  Enterprise Manager provides a GUI interface for the Data Guard broker that automates many of the tasks involved in creating, configuring, and monitoring a Data Guard environment. See Oracle Data Guard Broker and the Oracle Enterprise Manager online Help for information about the GUI and its wizards.
  
• SQL*Plus Command-line interface
  Several SQL*Plus statements use the STANDBY keyword to specify operations on a standby database. Other SQL statements do not include standby-specific syntax, but they are useful for performing operations on a standby database. See Chapter 15 for a list of the relevant statements.
  
• Initialization parameters
  Several initialization parameters are used to define the Data Guard environment. See Chapter 13 for a list of the relevant initialization parameters.
  

• Data Guard broker command-line interface (DGMGRL)
  The DGMGRL command-line interface is an alternative to using Oracle Enterprise Manager. The DGMGRL 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:

• Hardware and Operating System Requirements
  
• Oracle Software Requirements
  

2.3.1 Hardware and Operating System Requirements

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

• All members of a Data Guard configuration must run an Oracle image that is built for the same platform.
  For example, this means a Data Guard configuration with a primary database on a 32-bit Linux on Intel system can have a standby database that is configured on a 32-bit Linux on Intel system. However, a primary database on a 64-bit HP-UX system can also be configured with a standby database on a 32-bit HP-UX system, as long as both servers are running 32-bit images.
  
• 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. 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 into SQL statements and then execute the SQL on the logical standby database.
  
• 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.
  

2.3.2 Oracle Software Requirements

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

• Oracle Data Guard is available only as a feature of Oracle Database Enterprise Edition. It is not available with Oracle Database Standard Edition. This means the same release of Oracle Database Enterprise Edition must be installed on the primary database and all standby databases in a Data Guard configuration.
  
  Note:

  It is possible to simulate a standby database environment with databases running Oracle Database Standard Edition. You can do this by manually transferring archived redo log files using an operating system copy utility or using custom scripts that periodically send archived redo log files from one database to the other. The consequence is that this configuration does not provide the ease-of-use, manageability, performance, and disaster-recovery capabilities available with Data Guard.
• Using Data Guard SQL Apply, you will be able to perform a rolling upgrade of the Oracle database software from patch set release n (minimally, this must be release 10.1.0.3) to the next database 10.1.0.(n+1) patch set release. During a rolling upgrade, you can run different releases of the Oracle database on the primary and logical standby databases while you upgrade them, one at a time. For complete information, see Chapter 11, "Using SQL Apply to Upgrade the Oracle Database" and the ReadMe file for the applicable Oracle Database 10g patch set release.
  
• The COMPATIBLE initialization parameter must be set to the same value on all databases in a Data Guard configuration.
  
• If you are currently running Oracle Data Guard on Oracle8i database software, see Oracle Database Upgrade Guide for complete information about upgrading to Oracle Data Guard.
  

• The primary database must run in ARCHIVELOG mode. See Oracle Database Administrator's Guide for more information.
  
• 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 (RAC) databases, and these standby databases can be a mix of both physical and logical types. See Oracle Database High Availability Overview for more information about configuring and using Oracle Data Guard with RAC.
  
• Each primary database and standby database must have its own control file.
  
• If a standby database is located on the same system as the primary database, the archival directories for the standby database must use a different directory structure than the primary database. Otherwise, the standby database may overwrite the primary database files.
  
• 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 backups for standby creation. Keep the database in FORCE LOGGING mode as long as the standby database is required.
  
• The user accounts you use to manage the primary and standby database instances must have SYSDBA system privileges.
  
• Oracle recommends that when you set up Oracle Automatic Storage Management (ASM) and Oracle Managed Files (OMF) in a Data Guard configuration, set it up symmetrically on the primary and standby database. That is, if any database in the Data Guard configuration uses ASM, OMF, or both, then every database in the configuration should use ASM, OMF, or both, respectively. See the scenario in Section 12.12 for more information.
  
  Note:

  Because some applications that perform updates involving time-based data cannot handle data entered from multiple time zones, consider setting the time zone for the primary and remote standby systems to be the same to ensure the chronological ordering of records is maintained after a role transition.

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:

• A standby database on the same system as the primary database that uses a different directory structure than the primary system. This is illustrated in Figure 2-1 as Standby1.
  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.
  
• A standby database on a separate system that uses the same directory structure as the primary system. This is illustrated in Figure 2-1 as Standby2. This is the recommended method.
  
• A standby database on a separate system that uses a different directory structure than the primary system. This is illustrated in Figure 2-1 as Standby3.
  
  Note:

  if any database in the Data Guard configuration uses ASM, OMF, or both, then every database in the configuration should use ASM, OMF, or both, respectively. See Chapter 12 for a scenario describing how to set up OMF in a Data Guard configuration.

Figure 2-1 Possible Standby Configurations

Description of "Figure 2-1 Possible Standby Configurations"

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 concatenation of the DB_UNIQUE_NAME and DB_DOMAIN initialization parameters. You must specify a unique value for the DB_UNIQUE_NAME initialization parameter when more than one member of a Data Guard configuration resides on the same system. Oracle recommends that the value of the DB_UNIQUE_NAME initialization parameter always be unique, even if each database is located on a separate system.

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.4.) 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.4). 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

The transmission of redo is integral to maintaining the transactional consistency of the primary and standby databases. Both online redo logs and archived redo logs are required in a Data Guard environment:

• Online redo logs
  Every instance of an Oracle primary database and logical standby database has an online redo log to protect the database in case of an instance failure. Physical standby databases do not use an online redo log, because physical standby databases are not opened for read/write I/O. Changes are not made to the physical standby database and new redo data is not generated.
  
• Archived redo logs
  An archived redo log is required because archiving is the method used to keep standby databases transactionally consistent with the primary database. Primary databases, and both physical and logical standby databases all use an archived redo log. Oracle databases are set up, by default, to run in ARCHIVELOG mode so that the archiver (ARCn) process automatically copies each filled online redo log file to one or more archived redo log files.
  Unlike physical standby databases, logical standby databases are open databases that generate redo data and have multiple log files, including online redo log files, archived redo log files, and standby redo log files (if configured).
  

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 Database High Availability Overview 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.

See Also:

Oracle Database Administrator's Guide for more details about configuring redo logs, archive logs, and log groups

2.5.2 Standby Redo Logs

A standby redo log is similar to an online redo log, except that a standby redo log is used to store redo data received from another database.
A standby redo log is required if you want to implement:

• The maximum protection and maximum availability levels of data protection (described in Section 1.4 and in more detail in Section 5.6)
  
• Real-time apply (described in Section 6.2)
  
• Cascaded destinations (described in Appendix E)
  

A standby redo log provides a number of advantages:

• Standby redo log files can reside on raw devices, which may be important if either or both the primary and standby databases reside in a Real Application Clusters environment.
  
• Standby redo log files can be multiplexed using multiple members, improving reliability over archived log files.
  
• During a failover, Data Guard can recover and apply more redo data from standby redo log files than from the archived log files alone.
  
• The archiver (ARCn) process or the log writer (LGWR) process on the primary database can transmit redo data directly to remote standby redo log files, potentially eliminating the need to register a partial archived log file (for example, to recover after a standby database crashes). See Chapter 5 for more information.
  

Section 3.1.3 describes how to configure standby redo log files.

Creating a Standby Database with Recovery Manager

This appendix describes how to use Oracle Recovery Manager to create a standby database. This appendix contains the following topics:

• Prerequisites
• Overview of Standby Database Creation with RMAN
• Using the DUPLICATE Command to Create a Standby Database

F.1 Prerequisites

This appendix assumes that you have read the chapter on database duplication in Oracle Database Backup and Recovery User's Guide. Because you use the DUPLICATE command to create a standby database with RMAN, you should familiarize yourself with the DUPLICATE command entry in Oracle Database Backup and Recovery Reference.
Familiarize yourself with how to create a standby database in Chapter 3, "Creating a Physical Standby Database" and Chapter 4, "Creating a Logical Standby Database" before you attempt the RMAN creation procedures described in this chapter.

F.2 Overview of Standby Database Creation with RMAN

This section explains the purpose and basic concepts involved in standby database creation with RMAN.

F.2.1 Purpose of Standby Database Creation with RMAN

You can use either manual techniques or the RMAN DUPLICATE command to create a standby database from backups of your primary database. Creating a standby database with RMAN has the following advantages over manual techniques:

• RMAN can create a standby database by copying the files currently in use by the primary database. No backups are required.
  
• RMAN can create a standby database by restoring backups of the primary database to the standby site. Thus, the primary database is not affected during the creation of the standby database.
  
• RMAN automates renaming of files, including Oracle Managed Files (OMF) and directory structures.
  
• RMAN restores archived redo log files from backups and performs media recovery so that the standby and primary databases are synchronized.
  

F.2.2 Basic Concepts of Standby Creation with RMAN

The procedure for creating a standby database with RMAN is almost the same as for creating a duplicate database. You need to amend the duplication procedures described in Oracle Database Backup and Recovery User's Guide to account for issues specific to a standby database.
To create a standby database with the DUPLICATE command you must connect as target to the primary database and specify the FOR STANDBY option. You cannot connect to a standby database and create an additional standby database. RMAN creates the standby database by restoring and mounting a control file. RMAN can use an existing backup of the primary database control file, so you do not need to create a control file backup especially for the standby database.
A standby database, unlike a duplicate database created by DUPLICATE without the FOR STANDBY OPTION, does not get a new DBID. Thus, you should not register the standby database with your recovery catalog.

F.2.2.1 Active Database and Backup-Based Duplication

You must choose between active and backup-based duplication. If you specify FROM ACTIVE DATABASE, then RMAN copies the datafiles directly from the primary database to the standby database. The primary database must be mounted or open.
If you not specify FROM ACTIVE DATABASE, then RMAN performs backup-based duplication. RMAN restores backups of the primary datafiles to the standby database. All backups and archived redo log files needed for creating and recovering the standby database must be accessible by the server session on the standby host. RMAN restores the most recent datafiles unless you execute the SET UNTIL command.

F.2.2.2 DB_UNIQUE_NAME Values in an RMAN Environment

A standby database, unlike a duplicate database created by DUPLICATE without the FOR STANDBY option, does not get a new DBID. When using RMAN in a Data Guard environment, you should always connect it to a recovery catalog. The recovery catalog can store the metadata for all primary and standby databases in the environment. You should not explicitly register the standby database in the recovery catalog.
A database in a Data Guard environment is uniquely identified by means of the DB_UNIQUE_NAME parameter in the initialization parameter file. The DB_UNIQUE_NAME must be unique across all the databases with the same DBID for RMAN to work correctly in a Data Guard environment.

See Also:

Oracle Database Backup and Recovery User's Guide for a conceptual overview of RMAN operation in a Data Guard environment

F.2.2.3 Recovery of a Standby Database

By default, RMAN does not recover the standby database after creating it. RMAN leaves the standby database mounted, but does not place the standby database in manual or managed recovery mode. RMAN disconnects and does not perform media recovery of the standby database.
If you want RMAN to recover the standby database after creating it, then the standby control file must be usable for the recovery. The following conditions must be met:

• The end recovery time of the standby database must be greater than or equal to the checkpoint SCN of the standby control file.
  
• An archived redo log file containing the checkpoint SCN of the standby control file must be available at the standby site for recovery.
  

One way to ensure these conditions are met is to issue the ALTER SYSTEM ARCHIVE LOG CURRENT statement after backing up the control file on the primary database. This statement archives the online redo log files of the primary database. Then, either back up the most recent archived redo log file with RMAN or move the archived redo log file to the standby site.
Use the DORECOVER option of the DUPLICATE command to specify that RMAN should recover the standby database. RMAN performs the following steps after creating the standby database files:

1. RMAN begins media recovery. If recovery requires archived redo log files, and if the log files are not already on disk, then RMAN attempts to restore backups.
   
2. RMAN recovers the standby database to the specified time, system change number (SCN), or log file sequence number, or to the latest archived redo log file generated if none of the preceding are specified.
   
3. RMAN leaves the standby database mounted after media recovery is complete, but does not place the standby database in manual or managed recovery mode.
   

F.2.2.4 Standby Database Redo Log Files

RMAN automatically creates the standby redo log files on the standby database. After the log files are created, the standby database maintains and archives them according to the normal rules for log files.
If you use backup-based duplication, then the only option when naming the standby redo log files on the standby database is the file names for the log files, as specified in the standby control file. If the log file names on the standby must be different from the primary file names, then one option is to specify file names for the standby redo logs by setting LOG_FILE_NAME_CONVERT in the standby initialization parameter file.
Note the following restrictions when specifying file names for the standby redo log files on the standby database:

• You must use the LOG_FILE_NAME_CONVERT parameter to name the standby redo log files if the primary and standby databases use different naming conventions for the log files.
  
• You cannot use the SET NEWNAME or CONFIGURE AUXNAME commands to rename the standby redo log files.
  
• You cannot use the LOGFILE clause of the DUPLICATE command to specify file names for the standby redo log files.
  
• If you want the standby redo log file names on the standby database to be the same as the primary redo log file names, then you must specify the NOFILENAMECHECK clause of the DUPLICATE command. Otherwise, RMAN signals an error even if the standby database is created on a different host.
  

F.2.2.5 Password Files for the Standby Database

If you are using active database duplication, then RMAN always copies the password file to the standby host because the password file on the standby database must be an exact copy of the password file on the target database. In this case, the PASSWORD FILE clause is not necessary. RMAN overwrites any existing password file for the auxiliary instance. With backup-based duplication you must copy the password file used on the primary to the standby, for Data Guard to ship logs.

F.3 Using the DUPLICATE Command to Create a Standby Database

The procedure for creating a standby database is basically identical to the duplication procedure described in Oracle Database Backup and Recovery User's Guide.

F.3.1 Creating a Standby Database with Active Database Duplication

To create a standby database from files that are active in the primary database, specify both FOR STANDBY and FROM ACTIVE DATABASE. Optionally, specify the DORECOVER option to recover the database after standby creation.
This scenario assumes that the standby host and primary database host have the same directory structure.
To create a standby database from active database files:

1. Prepare the auxiliary database instance as explained in Oracle Database Backup and Recovery User's Guide.
   Because you are using active database duplication, you must create a password file for the auxiliary instance and establish Oracle Net connectivity. This is a temporary password file as it will be overwritten during the duplicate operation.
   
2. Decide how to provide names for the standby control files, datafiles, online redo logs, and tempfiles. This step is explained in Oracle Database Backup and Recovery User's Guide.
   In this scenario, the standby database files will be named the same as the primary database files.
   
3. Start and configure RMAN as explained in Oracle Database Backup and Recovery User's Guide.
   
4. Execute the DUPLICATE command.
   The following example illustrates how to use DUPLICATE for active duplication. This example requires the NOFILENAMECHECK option because the primary database files have the same names as the standby database files. The SET clauses for SPFILE are required for log shipping to work properly. The db_unique_name must be set to ensure that the catalog and Data Guard can identify this database as being different from the primary.
   

   
   DUPLICATE TARGET DATABASE
     FOR STANDBY
     FROM ACTIVE DATABASE
     DORECOVER
     SPFILE
       SET "db_unique_name"="foou" COMMENT ''Is a duplicate''
       SET LOG_ARCHIVE_DEST_2="service=inst3 ASYNC REGISTER
        VALID_FOR=(online_logfile,primary_role)"
       SET FAL_CLIENT="inst3" COMMENT "Is standby"
       SET FAL_SERVER="inst1" COMMENT "Is primary"
     NOFILENAMECHECK;
   

   RMAN automatically copies the server parameter file to the standby host, starts the auxiliary instance with the server parameter file, restores a backup control file, and copies all necessary database files and archived redo logs over the network to the standby host. RMAN recovers the standby database, but does not place it in manual or managed recovery mode.
   

F.3.2 Creating a Standby Database with Backup-Based Duplication

To create a standby database from backups, specify FOR STANDBY but do not specify FROM ACTIVE DATABASE. Optionally, specify the DORECOVER option to recover the database after standby creation.
This scenario assumes that the standby host and primary database host have the same directory structure.
To create a standby database from backups:

1. Make database backups and archived redo logs available to the auxiliary instance on the duplicate host as explained in Oracle Database Backup and Recovery User's Guide.
   
2. Prepare the auxiliary database instance as explained in Oracle Database Backup and Recovery User's Guide.
   
3. Decide how to provide names for the standby control files, datafiles, online redo logs, and tempfiles. This step is explained in Oracle Database Backup and Recovery User's Guide.
   In this scenario, the standby database files will be named the same as the primary database files.
   
4. Start and configure RMAN as explained in Oracle Database Backup and Recovery User's Guide.
   
5. Execute the DUPLICATE command.
   The following example illustrates how to use DUPLICATE for backup-based duplication. This example requires the NOFILENAMECHECK option because the primary database files have the same names as the standby database files.
   

   
   DUPLICATE TARGET DATABASE
     FOR STANDBY
     DORECOVER
     SPFILE
       SET "db_unique_name"="foou" COMMENT ''Is a duplicate''
       SET LOG_ARCHIVE_DEST_2="service=inst3 ASYNC REGISTER
        VALID_FOR=(online_logfile,primary_role)"
       SET FAL_CLIENT="inst3" COMMENT "Is standby"
       SET FAL_SERVER="inst1" COMMENT "Is primary"
     NOFILENAMECHECK;
   

   RMAN automatically copies the server parameter file to the standby host, starts the auxiliary instance with the server parameter file, and restores all necessary database files and archived redo logs to the standby host. RMAN recovers the standby database, but does not place it in manual or managed recovery mode.