What's New in Oracle Data Guard?

This preface describes the new features added to Oracle Data Guard in release 11.1 and provides links to additional information. The features and enhancements described in this preface were added to Oracle Data Guard in 11g Release 1 (11.1). The new features are described under the following main areas:

• New Features Common to Redo Apply and SQL Apply

• New Features Specific to Redo Apply and Physical Standby Databases

• New Features Specific to SQL Apply and Logical Standby Databases

New Features Common to Redo Apply and SQL Apply

The following enhancements to Oracle Data Guard in 11g Release 1 (11.1) improve ease-of-use, manageability, performance, and include innovations that improve disaster-recovery capabilities:

• Compression of redo traffic over the network in a Data Guard configuration

  This feature improves redo transport performance when resolving redo gaps by compressing redo before it is transmitted over the network.

  See Also:

  "COMPRESSION" attribute

• Redo transport response time histogram

  The V$REDO_DEST_RESP_HISTOGRAM dynamic performance view contains a histogram of response times for each SYNC redo transport destination. The data in this view can be used to assist in the determination of an appropriate value for the LOG_ARCHIVE_DEST_n NET_TIMEOUT attribute.

  See Also:

  "NET_TIMEOUT" attribute.

• Faster role transitions

• Strong authentication for redo transport network sessions

  Redo transport network sessions can now be authenticated using SSL. This provides strong authentication and makes the use of remote login password files optional in a Data Guard configuration.

• Simplified Data Guard management interface

  The SQL statements and initialization parameters used to manage a Data Guard configuration have been simplified through the deprecation of redundant SQL clauses and initialization parameters.

  See Also:

  • Chapter 16, "SQL Statements Relevant to Data Guard" for information about which statements have had clauses deprecated

  • Oracle Database SQL Language Reference for more information about deprecated clauses relevant to the SQL statements discussed in Chapter 16

  • Oracle Database Reference for information about deprecated attributes of the LOG_ARCHIVE_DEST_n parameter

• Enhancements around DB_UNIQUE_NAME

  You can now find the DB_UNIQUE_NAME of the primary database from the standby database by querying the new PRIMARY_DB_UNIQUE_NAME column in the V$DATABASE view. Also, Oracle Data Guard release 11g ensures each database's DB_UNIQUE_NAME is different. After upgrading to 11g, any databases with the same DB_UNIQUE_NAME will not be able to communicate with each other.

• Use of physical standby database for rolling upgrades

  A physical standby database can now take advantage of the rolling upgrade feature provided by a logical standby. Through the use of the new KEEP IDENTITY clause option to the SQL ALTER DATABASE RECOVER TO LOGICAL STANDBY statement, a physical standby database can be temporarily converted into a logical standby database for the rolling upgrade, and then reverted back to the original configuration of a primary database and a physical standby database when the upgrade is done.

  See Also:

  Chapter 12, "Using SQL Apply to Upgrade the Oracle Database"

• Heterogeneous Data Guard Configuration

  This feature allows a mix of Linux and Windows primary and standby databases in the same Data Guard configuration.

New Features Specific to Redo Apply and Physical Standby Databases

The following list summarizes the new features that are specific to Redo Apply and physical standby databases in Oracle Database 11g Release 1 (11.1):

• Real-time query capability of physical standby

  This feature makes it possible to query a physical standby database while Redo Apply is active.

  See Also:

  Section 9.2, "Opening a Physical Standby Database" for more information about how an open physical standby database can continue to receive and apply redo data from a primary database

• Snapshot standby

  A snapshot standby database is new type of updatable standby database that provides full data protection for a primary database.

  See Also:

  Section 9.7, "Managing a Snapshot Standby Database"

• Lost-write detection using a physical standby

  A "lost write" is a serious form of data corruption that can adversely impact a database. It occurs when an I/O subsystem acknowledges the completion of a block write in the database, while in fact the write did not occur in the persistent storage. This feature allows a physical standby database to detect lost writes to a primary or physical standby database.

  See Also:

  Section 13.6, "Recovering From Lost-Write Errors on a Primary Database" for an example of lost-write recovery, and Oracle Database Backup and Recovery User's Guide for information about enabling lost-write detection

• Improved Integration with RMAN

  A number of enhancements in RMAN help to simplify backup and recovery operations across all primary and physical standby databases, when using a catalog. Also, you can use the RMAN DUPLICATE command to create a physical standby database over the network without a need for pre-existing database backups.

  See Also:

  • Section 3.2, "Step-by-Step Instructions for Creating a Physical Standby Database"

  • Chapter 11, "Using RMAN to Back Up and Restore Files"

  • Appendix F, "Creating a Standby Database with Recovery Manager"

New Features Specific to SQL Apply and Logical Standby Databases

The following list summarizes the new features for SQL Apply and logical standby databases in Oracle Database 11g Release 1 (11.1):

• Support for additional object datatypes and PL/SQL package support

  • XML stored as CLOB

  See Also:

  Appendix C, "Data Type and DDL Support on a Logical Standby Database"

• Support for additional PL/SQL Package

  • DBMS_RLS (row level security or Virtual Private Database)

  • DBMS_FGA

  See Also:

  Appendix C, "Data Type and DDL Support on a Logical Standby Database"

• Support Transparent Data Encryption (TDE)

  Data Guard SQL Apply can be used to provide data protection for the primary database with Transparent Data Encryption enabled. This allows a logical standby database to provide data protection for applications with advanced security requirements.

  See Also:

  • Chapter 10, "Managing a Logical Standby Database"

  • Section C.2, "Support for Transparent Data Encryption (TDE)"

• Dynamic setting of Data Guard SQL Apply parameters

  You can now configure specific SQL Apply parameters without requiring SQL Apply to be restarted. Using the DBMS_LOGSTDBY.APPLY_SET package, you can dynamically set initialization parameters, thus improving the manageability, uptime, and automation of a logical standby configuration.

  In addition, the APPLY_SET and APPLY_UNSET subprograms include two new parameters: LOG_AUTO_DEL_RETENTION_TARGET and EVENT_LOG_DEST.

  See Also:

  DBMS_LOGSTDBY PL/SQL package in the Oracle Database PL/SQL Packages and Types Reference

• Enhanced RAC switchover support for logical standby databases

  When switching over to a logical standby database where either the primary database or the standby database is using Oracle RAC, the SWITCHOVER command can be used without having to shut down any instance, either at the primary or at the logical standby database.

• Enhanced DDL handling in Oracle Data Guard SQL Apply

  SQL Apply will execute parallel DDLs in parallel (based on availability of parallel servers).

• Use of the PL/SQL DBMS_SCHEDULER package to create Scheduler jobs on a standby database

  Scheduler Jobs can be created on a standby database using the PL/SQL DBMS_SCHEDULER package and can be associated with an appropriate database role so that they run when intended (for example, when the database is the primary, standby, or both).