What's New in Oracle Data Guard?

The features and enhancements described in this preface were added to Oracle Data Guard in Release 10.1. The new features are described under the following main areas:

• New Features Common to Physical and Logical Standby Databases
• New Features Specific to Physical Standby Databases
• New Features Specific to Logical Standby Databases

New Features Common to Physical and Logical Standby Databases

The following enhancements to Oracle Data Guard in Release 10.1 improve ease-of-use, manageability, performance, and include innovations that improve disaster recovery capabilities:

• Real-Time Apply

  Data Guard log apply services can now apply redo data as it is received on the logical or physical standby database, without waiting for the current standby online redo log file to be archived. This allows reporting on more up-to-date data, quicker failovers and switchovers, and reduces planned and unplanned downtime.

  See Also: Chapter 6, "Log Apply Services"

• Recovery Through Open Resetlogs

  Data Guard supports recovery through open resetlogs by allowing recovery on a standby database to react appropriately to a RESETLOGS operation, instead of requiring the standby database to be re-created. Because an ALTER DATABASE OPEN RESETLOGS statement is always issued after a point-in-time recovery or a Flashback Database operation, the recovery through resetlogs feature allows the standby database to resume.

  See Also: Section 10.4, "Using Flashback Database After Issuing an Open Resetlogs Statement"

• Flashback Database Support

  Data Guard supports the new Flashback Database feature that allows a standby database to be quickly and easily flashed back to an arbitrary point in time. This feature provides the following benefits when used with Data Guard:

  • Flashback Database removes the need to re-create the primary database after a failover. After a failover, the original primary database can now be flashed back to a point in time before the failover and converted into a standby database. Once all of the logs have been applied, the original primary database can be switched back to the primary role.
  • Provides an alternative to delaying the application of redo data to protect against user errors or logical corruptions. Therefore, standby databases can be more closely synchronized with the primary database, reducing failover and switchover times.

    See Also: See Section 6.2.2 and the Oracle Database Backup and Recovery Advanced User's Guide for more information about using Flashback Database

• Improved Redo Data Transmission Security

  Data Guard log transport services now use authenticated network sessions to transfer redo data among the members of a Data Guard configuration. If the Oracle Advanced Security option is installed, security can be increased still further by using encryption and integrity checksums on network transmission of redo data.

  See Also: Section 5.3.3, "Providing for Secure Redo Data Transmission", Chapter 12, "LOG_ARCHIVE_DEST_n Parameter Attributes", and Oracle Advanced Security Administrator's Guide

• Improved Data Guard Support for Real Application Clusters

  The Data Guard broker can now be used to manage Data Guard configurations that contain Real Application Clusters primary or standby databases.

  See Also: Oracle Data Guard Broker

• Dynamically Add Standby Databases to Real Applications Clusters

  It is now possible to dynamically add a standby database to a Data Guard configuration that contains a Real Applications Clusters primary database, when that primary database is operating in either the maximum protection or the maximum availability level of protection, without shutting down the primary database.

  This enhancement requires using initialization parameters that are new in Oracle Database 10g Release 1:

  • DB_UNIQUE_NAME
  • LOG_ARCHIVE_CONFIG

    See Also: Chapter 5, "Log Transport Services" and Chapter 12, "LOG_ARCHIVE_DEST_n Parameter Attributes"

• Simplified Data Guard Configuration Management

  The new VALID_FOR attribute of the LOG_ARCHIVE_DEST_n initialization parameter can be used to create initialization parameter files that are role independent. This simplifies switchovers and failovers because it is no longer necessary to enable and disable role-specific archiving destinations after a performing a database role transition. This feature makes it possible to use the same parameter file whether the database is running in the primary or the standby role.

  See Also: Chapter 5, "Log Transport Services" and Chapter 12, "LOG_ARCHIVE_DEST_n Parameter Attributes"

• Automated Disk-Based Backup and Flashback Recovery

  Managing files needed for backup and recovery is simplified when these files are stored in a flash recovery area. If a flash recovery area is configured, Data Guard will implicitly set the LOG_ARCHIVE_DEST_10 initialization parameter to point to the flash recovery area and will use this destination for local archiving unless you explicitly configure another local archive destination.

  See Also: Chapter 5, "Log Transport Services" and Oracle Database Backup and Recovery Basics

• Archiver Process Supports Remote Standby Redo Log Files

  The archiver process (ARCn) can now transmit redo data to remote destinations that are configured to use standby redo log files. Failovers are simplified when this feature is used, because partially filled archived redo log files no longer have to be registered before performing a failover.

  See Also: Chapter 5, "Log Transport Services"

• Change In Default Archival Behavior

  The default archival processing in a Data Guard configuration has changed so that archiver processes (ARCn) on the primary database will completely and successfully archive the local online redo log files before transmitting the redo data to remote standby destinations. Before release 10.1, the default behavior was to transmit redo data to the standby destination at the same time the online redo log file was being archived to the local online redo log files. This change allows the redo log groups to be reused faster and reduces the likelihood of a database hang due to lack of available redo log groups.

  See Also: Section 5.3.1, "Using Archiver Processes (ARCn) to Archive Redo Data"

• Simplified Management of Redo Log Archiving

  Automatic archiving is now enabled by default when a database is put into archivelog mode.

  See Also: Chapter 5, "Log Transport Services" and Oracle Database Administrator's Guide

• Secure Redo Transmission

  Log transport services now use authenticated network sessions to transfer redo data. These sessions are authenticated using the SYS user password contained in the password file. All databases in the Data Guard configuration must use a password file, and the SYS password contained in this password file must be identical on all systems. This authentication can be performed even if Oracle Advanced Security is not installed, and provides some level of security when shipping redo.

  See Also: Section 5.3.3, "Providing for Secure Redo Data Transmission" and the Oracle Advanced Security Administrator's Guide

New Features Specific to Physical Standby Databases

The following list summarizes the new features that are specific to physical standby databases in Oracle Database 10g:

• New Default Behavior for the STARTUP, MOUNT, and OPEN Statements

  The STARTUP, MOUNT, and OPEN statements have new default behaviors that simplify their use with a physical standby database:

  • The STARTUP command will now start, mount and open a physical standby database in read-only mode in a single step.
  • The STANDBY DATABASE keywords are now optional when using the ALTER DATABASE MOUNT statement to mount a physical standby database.
  • The READ ONLY keywords are now optional when using the ALTER DATABASE OPEN statement to open a physical standby database.

    See Also: Chapter 13, "SQL Statements Relevant to Data Guard" and the Oracle Database SQL Reference

New Features Specific to Logical Standby Databases

Logical standby databases, first released with Oracle Database in Release 9.2, were enhanced in this release to allow rolling upgrades, improve the overall ease-of-use and manageability, expand the disaster recovery capabilities, and simplify the steps to create a logical standby database. The following list summarizes the new features for logical standby databases in Oracle Database 10g:

• Zero Downtime Instantiation

  It is now possible to create a logical standby database without having to shut down or quiesce the primary database. This is achieved by using an online backup of the primary database and creating a logical standby control file.

  See Also: Chapter 4, "Creating a Logical Standby Database"

• Rolling Database Upgrades with SQL Apply

  In a future patchset release of Oracle Database 10g, it will be possible to do a rolling upgrade using logical standby databases. The foundation for rolling upgrades is now implemented into the SQL Apply technology so that the primary database incurs minimal downtime when you upgrade Oracle Database software on each database in the Data Guard configuration. For example, using SQL Apply and logical standby databases, you will be able to upgrade the Oracle Database software from patchset release 10.1.0.n to the next database 10.1.0.(n+1) patchset release.

  See Also: Section 9.2 and the ReadMe file for the applicable Oracle Database 10g patchset release

• Support for Maximum Protection Mode

  With the introduction of support for standby redo log files, it is now possible to have a logical standby database be part of a Data Guard configuration running in maximum protection mode.

  See Also: Section 5.6, "Setting Up a Data Protection Mode"

• Support for Additional Datatypes

  Logical standby databases now include support for LONG, LONG RAW, and NCLOB data types. Also, support for index organized tables was added provided the index organized table does not contain either an overflow segment or any LOB column.

  See Also: Section 4.1.1, "Determine Support for Datatypes and Storage Attributes for Tables"