Changes in This Release for Oracle Data Guard Concepts and Administration

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 Section C.11.1 for more information.

New Features

This section lists new features in the following areas:

• Features Common to Redo Apply and SQL Apply

• Features Specific to Redo Apply

• Features Specific to SQL Apply

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 Section 7.3, "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 Chapter 5, "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:

  • Oracle Data Guard Broker for more information about how the broker supports Global Data Services (GDS)

  • Oracle Database Global Data Services Concepts and Administration Guide for more information about GDS and the GDS command-line interface, GDSCTL

Features Specific to Redo Apply

• The USING CURRENT LOGFILE clause is no longer required to start real-time apply.

  See "Using Real-Time Apply to Apply Redo Data Immediately" for more information about real-time apply.

• You can create a physical standby of a multitenant container database (CDB).

  See "Creating a Physical Standby of a CDB"

• DML operations are allowed on global temporary tables on Oracle Active Data Guard standbys.

  See "DML Operations on Temporary Tables on Oracle Active Data Guard Instances".

• The use of sequences in an Oracle Active Data Guard environment is now supported.

  See "Using Sequences in Oracle Active Data Guard".

• When you perform a switchover from an Oracle RAC primary database to a physical standby database, it is no longer necessary to shut down all but one primary database instance.

  There is also new SQL syntax available for performing switchover and failover operations to a physical standby database.

  See "Role Transitions Involving Physical Standby Databases".

• Application Continuity is supported for Oracle Data Guard switchovers to physical standby databases. It is also supported for fast-start failover to physical standbys in maximum availability data protection mode. Note that primary and standby databases must be licensed for Oracle RAC or Oracle Active Data Guard in order to use Application Continuity. See "Application Continuity."

  See Oracle Database Development Guide for information about Application Continuity.

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 Chapter 14, "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 Appendix C, "Supported Datatypes in a Logical Standby Database".

• DBMS_SCHEDULER support for rolling upgrades.

  See Appendix C, "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.