What's New in Oracle Data Guard?

This preface describes the new features added to Oracle Data Guard in release 10.2 and provides links to additional information. The features and enhancements described in this preface were added to Oracle Data Guard in 10g Release 2 (10.2). 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 10g Release 2 (10.2) improve ease-of-use, manageability, performance, and include innovations that improve disaster-recovery capabilities:

• Fast-start failover

  Fast-start failover provides the ability to automatically, quickly, and reliably fail over to a designated, synchronized standby database in the event of loss of the primary database, without requiring that you perform complex manual steps to invoke the failover.

  Also, after a fast-start failover occurs, the old primary database is automatically reconfigured as a new standby database upon reconnection to the configuration. This enables Data Guard to restore disaster protection in the configuration easily, without complex manual steps, improving the robustness of the disaster-recovery features of Data Guard, as well as improving Data Guard manageability.

  These new capabilities allow you to maintain uptime and increase the availability, as well the robustness of disaster recovery. Plus, there is less need for manual intervention, thereby reducing management costs.

  See Also:

  Oracle Data Guard Broker

• Flashback Database across Data Guard switchovers

  It is now possible to flash back the primary and standby databases to an SCN or a point in time prior to a switchover operation. When you use this feature of Flashback Database on a physical standby database, the standby role is preserved. On a logical standby database, the role of the standby database is changed to what it was at the target SCN or time.

  This feature extends the flashback window, providing more flexibility to detect and correct human errors.

  See Also:

  Section 7.4, "Using Flashback Database After a Role Transition"

• Asynchronous Redo Transmission

  Asynchronous redo transmission using the log writer process (LGWR ASYNC) has been improved to reduce the performance impact on the primary database. During asynchronous redo transmission, the network server (LNSn) process transmits redo data out of the online redo log files on the primary database and no longer interacts directly with the log writer process.

  This change in behavior allows the log writer process to write redo data to the current online redo log file and continue processing the next request without waiting for interprocess communication or network I/O to complete.

  See Also:

  Section 5.3.2.3, "LGWR ASYNC Archival Processing" and the SYNC and ASYNC attributes in Chapter 14

• New MAX_CONNECTIONS attribute on the LOG_ARCHIVE_DEST_n parameter

  This attribute specifies how the archiver (ARCn) processes on the primary database coordinate when sending redo data to standby databases. If the MAX_CONNECTIONS attribute is set to a nonzero value, redo transport services use multiple network connections to transmit redo data using archiver processes.

  See Also:

  "MAX_CONNECTIONS" attribute

• Data Guard enhancements in Oracle Enterprise Manager

  If you use the Data Guard broker to manage your Data Guard configuration, you can take advantage of the following enhancements in Oracle Enterprise Manager.

  • Estimated Failover Time (seconds)

    The approximate number of seconds required to fail over to this standby database. This accounts for the startup time (if necessary) plus the remaining time it would require to apply all the available redo data on the standby database. If it is not necessary to start the database, this metric shows only the remaining apply time.

  • Apply Lag (seconds)

    The number of seconds that the standby database is behind the primary database in applying redo data.

  • Redo Generation Rate (KB/second)

    Displays the amount of redo generation rate in KB/second on the primary database.

  • Redo Apply Rate (KB/second)

    Displays the Redo Apply Rate in KB/second on this standby database.

  • Transport Lag (seconds)

    The approximate number of seconds of redo data not yet available on this standby database. This may be because the redo has not yet been shipped or there may be a gap.

  • Data Guard Status

    Use the Data Guard Status metric to check the status of each database in the Data Guard configuration.By default, a critical and warning threshold value was set for this metric column. Alerts will be generated when threshold values are reached. You can edit the value for a threshold, as required.

  • Fast-Start Failover Occurred

    When fast-start failover is enabled, this metric generates a critical alert on the new primary database (old standby database) if a fast-start failover occurs. The fast-start failover SCN must be initialized to a value before the metric will alert. This usually takes one collection interval. Once a fast-start failover occurs and the new primary database is ready, the fast-start failover alert is generated. The alert is cleared after one collection interval. A critical alert is configured by default.

    • Both primary and standby databases must be configured with SYSDBA monitoring access.

    • Shows the time when a fast-start failover occurred: the value is zero if fast-start failover has not occurred and one if fast-start failover occurred.

  • Fast-Start Failover SCN

    When fast-start failover is enabled, this metric generates a critical alert on the new primary database (old standby database) if a fast-start failover occurs. The fast-start failover SCN must be initialized to a value before the metric will alert. This usually takes one collection interval. Once a fast-start failover occurs and the new primary database is ready, the fast-start failover alert is generated. The alert is cleared after one collection interval. A critical alert is configured by default.

    • Both primary and standby databases must be configured with SYSDBA monitoring access.

    • Any value indicates the metric is ready to trigger.

  • Fast-Start Failover Time

    When fast-start failover is enabled, this metric will generate a critical alert on the new primary database (old standby database) if a fast-start failover occurs. The fast-start failover SCN must be initialized to a value before the metric will create an alert. This usually takes one collection interval. Once a fast-start failover occurs and the new primary database is ready, the fast-start failover alert fires. It then clears after one collection interval. A critical alert is configured by default.

    • Both primary and standby databases must be configured with SYSDBA monitoring access.

    • A time stamp displays if fast-start failover occurred.

  See Also:

  Oracle Enterprise Manager online Help system

• New support for Change Data Capture and Streams:

  • Distributed (heterogeneous) Asynchronous Change Data Capture

  • Downstream Capture Hot Mining

  See Also:

  Oracle Streams Concepts and Administration and Oracle Database Data Warehousing Guide (for Change Data Capture information)

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 10g Release 2 (10.2):

• Faster Redo Apply failover

  Allows you to transition a physical standby database to the primary database role without doing a database restart, as long as the standby database has not been opened read-only since the last time it was started.

  This enables faster recovery from a failure or outage, increasing the availability of the system.

  See Also:

  Section 7.2.2, "Failovers Involving a Physical Standby Database"

• Easy conversion of a physical standby database to a reporting database

  A physical standby database can be activated as a primary database, opened read/write for reporting purposes, and then flashed back to a point in the past to be easily converted back to a physical standby database. At this point, Data Guard automatically synchronizes the standby database with the primary database. This allows the physical standby database to be utilized for reporting and read/write cloning activities.

  See Also:

  Section 12.6, "Using a Physical Standby Database for Read/Write Testing and Reporting"

• New FORCE keyword on RECOVER MANAGED STANDBY DATABASE FINISH

  The new FORCE option on the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH statement stops active RFS processes on the target standby database so the failover will proceed immediately, as soon as the logs have been applied.

  See Also:

  Section 7.2.2, "Failovers Involving a Physical Standby Database" and the ALTER DATABASE syntax in Oracle Database SQL Reference

• RMAN automatically re-creates tempfiles after recovery

  Temporary datafiles that belong to locally managed temporary tablespaces are automatically created during the recovery operation by RMAN, thus it is no longer necessary to create and associate a tempfile with a temporary tablespace on a physical standby database.

• Miscellaneous changes improve usage and manageability

  By deprecating unnecessary initialization parameters and certain SQL statement clauses and keywords, the usage and manageability of physical standby databases has been improved.

  See Also:

  The SQL statements relevant to Data Guard in Oracle Database SQL Reference and the LOG_ARCHIVE_DEST_n initialization parameter in Oracle Database Reference

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 10g Release 2 (10.2):

• Faster SQL Apply failover

  Failover to a logical standby database can now be completed much faster because it is no longer necessary to restart SQL Apply as a part of the failover operation. This enables the Data Guard configuration to recover from a failure or outage much faster, increasing the availability of the system.

  See Also:

  Section 7.3.2, "Failovers Involving a Logical Standby Database"

• Additional datatype support for Index Organized Tables

  SQL Apply now supports mining of redo records generated by index organized tables containing LOB columns and overflow segments.

  See Also:

  Section 4.1.1, "Determine Support for Data Types and Storage Attributes for Tables"

• Automatic deletion of applied archived redo log files

  Archived log files, once they are applied on the logical standby database, will be automatically deleted by SQL Apply. This reduces storage consumption on the logical standby database and improves Data Guard manageability.

  See Also:

  Section 9.3.2, "Automatic Deletion of Log Files"

• Optimized creation of logical standby database

  Creation of a logical standby database no longer requires the creation of a specialized logical standby control file, which could not be used by RMAN. Logical standby databases can now be created easily from a physical standby database. This reduces the specialized manual operations for creating a logical standby database and improves Data Guard manageability.

  See Also:

  Section 4.2, "Step-by-Step Instructions for Creating a Logical Standby Database"

• Added several enhancements for managing logical standby databases:

  • New views:

    • V$LOGSTDBY_PROCESS (replaces the deprecated V$LOGSTDBY view)

    • V$LOGSTDBY_STATE

    • V$LOGSTDBY_PROGRESS

    • V$LOGSTDBY_TRANSACTION

    • V$DATAGUARD_STATS

  • New DBMS_LOGSTDBY.REBUILD() subprogram on the DBMS_LOGSTDBY PL/SQL package

  • Tracing

    See Also:

    Chapter 9, "Managing a Logical Standby Database"