Changes in This Release for Oracle Data Guard Concepts and Administration

This preface lists changes in Oracle Data Guard Concepts and Administration.

Changes in Oracle Database 12c Release 1 (12.1.0.2)

The following are changes in Oracle Data Guard Concepts and Administration for Oracle Database 12c Release 1 (12.1.0.2)

  • As of Oracle Database 12c release 1 (12.1.0.2), transport of redo data to a Recovery Appliance is supported in a Data Guard configuration.

New Features Specific to SQL Apply

  • To determine whether any tables involved in a rolling upgrade performed with the DBMS_ROLLING PL/SQL package contain unsupported data types, you can now query the new DBA_ROLLING_UNSUPPORTED view. See Unsupported Tables During Rolling Upgrades for more information.

Changes in Oracle Database 12c Release 1 (12.1.0.1)

The following are changes in Oracle Data Guard Concepts and Administration for Oracle Database 12c Release 1 (12.1.0.1).

New Features

This section lists new features in the following areas:

Features Common to Redo Apply and SQL Apply

  • For better separation of duty, Oracle Database now provides an Oracle Data Guard-specific administration privilege, SYSDG, to handle standard administration duties for Oracle Data Guard. This new privilege is based on the least privilege principle, in which a user is granted only the absolutely necessary privileges required to perform a specific function, and no more. The SYSDBA privilege continues to work as in previous releases.

    See Oracle Database Security Guide for more information about the SYSDG privilege and all the operations it allows.

  • Primary database redo can now be cascaded in real time as it is being written to the standby redo log file at a physical standby or a far sync instance. This feature is known as real-time cascading and it requires a license for the Oracle Active Data Guard option.

    See Cascaded Redo Transport Destinations for more information.

  • A new type of remote Oracle Data Guard destination, called a far sync instance, accepts redo from the primary database and then ships that redo to other members of the Oracle Data Guard configuration. When a far sync instance is included in an Oracle Data Guard configuration, it enables zero data loss failover at any distance and off-host redo transport compression to conserve WAN bandwidth, both without affecting primary database performance. The name of this feature is Oracle Active Data Guard Far Sync. To use it, you must have a license for the Oracle Active Data Guard option.

    See Far Sync .

  • Maximum Availability mode now allows the LOG_ARCHIVE_DEST_n attributes SYNC and NOAFFIRM to be used together. This enables a synchronous standby database to be deployed at a further distance from the primary site without increasing the impact on primary database performance. (In an Oracle Data Guard broker configuration, this is referred to as FASTSYNC mode.)

    See "Maximum Availability" for more information.

  • You can move the location of an online data file from one physical file to another physical file while the database is actively accessing the file. Moves on a primary database do not affect the standby, and vice versa.

    See "Moving the Location of Online Data Files".

  • If an Oracle Data Guard configuration is managed by Oracle Data Guard broker, then Oracle Global Data Services (GDS) is fully supported on the databases in that configuration. (GDS provides Oracle RAC-like service failover and load balancing for a set of replicated databases, within or across data centers.)

    If the configuration is not managed by the broker, then Oracle Global Data Services (GDS) is supported with the exception of role-based services.

    See Also:

Features Specific to Redo Apply

Features Specific to SQL Apply

  • The Extended Datatype Support (EDS) feature allows SQL Apply to replicate changes made to tables that contain data types not natively supported, from one database to another.

    See "Using Extended Datatype Support During Replication".

  • You can create a logical standby of a CDB.

    See "Creating a Logical Standby of a CDB".

  • A logical standby now accept archived logs while a rolling upgrade is taking place. (In prior releases, archived logs that were shipped while the upgrade process was running at the logical standby were rejected.)

    See "Benefits of a Rolling Upgrade Using SQL Apply".

  • The new Rolling Upgrade Using Oracle Active Data Guard feature automates the previous manual processes used to perform database rolling upgrades to new Oracle patchsets or database releases, and to perform other planned maintenance. This feature uses the new DBMS_ROLLING PL/SQL package and requires a license for the Oracle Active Data Guard option.

    See Using DBMS_ROLLING to Perform a Rolling Upgrade .

  • Support for additional data types: XMLType data for all storage models (if compatibility requirements are met), Oracle Spatial, Oracle Multimedia, Oracle Text, Objects and Collections (including VARRAYs and nested collections), Database File System (DBFS), XDB, Oracle SecureFiles (deduplication), and User-defined types.

    See Supported Datatypes in a Logical Standby Database.

  • DBMS_SCHEDULER support for rolling upgrades.

    See Support for DBMS_SCHEDULER

Desupported Features

Some features previously described in this document are desupported in Oracle Database 12c Release 1 (12.1). See Oracle Database Upgrade Guide for a list of desupported features.