On the Second Day of 12.2, my DBA gave to me… Data Guard New Features

Multiple Observers

Oracle added the functionality for up to three observers to monitor and support a single Oracle Data Guard Broker configuration. Each observer must be assigned a name. The name assigned to the observer must be unique in the configuration. The name of the observer is also case sensitive. When we start the observers with DGMGRL, the START OBSERVER command is enhanced to accept the name of the observer. In a three observer configuration, we have a concept of the master observer and two backup observers. When fast-start failover (FSFO) is initiated, the primary and the standby database randomly choose from the list of registered observers and designates a master observer. If there is no observer registered, then the first observer that is started becomes the master observer. The subsequent observers that join the FSFO configuration become the backup observers. Only the master observer has the privilege of coordinating the FSFO with the Data Guard broker. Other registered observers serve the role of backup observers until the master observer is not available. Observer placement continues to be a critical component to the Data Guard topology. Oracle has always recommended to place the observer in another data center. With multiple observers in play, the same recommendation still holds true. Now, with additional observers, there are other factors to consider. We should never place the observers on the same server or the same virtual server. We should also consider placing one or more of the observers in separate data centers. The v$database view introduces two additional columns FS_FAILOVER_OBSERVER_HOST and FS_FAILOVER_OBSERVER_PRESENT. The FS_FAILOVER_OBSERVER_HOST displays the name of the host where the master observer is running from. The FS_FAILOVER_OBSERVER_PRESENT column designates if the master observer is associated with the local database and displays a value of either YES or NO. The view V$FS_FAILOVER_OBSERVERS displays all the observers in the FSFO configuration. (Image available in Download) This view also displays the following information: • observer name • the host that it resides on, • if the observer is the master observer • when the master observer became the master observer • if the master observers is connected to the primary and/or physical standby database For additional information, please visit the following URL: http://docs.oracle.com/database/122/DGBKR/using-data-guard-broker-to-manage-switchovers-failovers.htm#DGBKR394

Simplified Observer Management

With a single DGMGRL broker session, we can now monitor and manage multiple Observers from fast-start failover configurations. This increases the operational efficiencies and thus reduces cost of managing multiple Data Guard databases that have fast-start failover configurations.

Multiple Instance Redo Apply (MIRA) in RAC

Starting in Oracle 12.2, we can run Redo Apply all or on some standby instances. With this concept of multiple instance redo apply (MIRA), Redo Apply performance can scale as wide as the target RAC configuration allows. This feature is crucial for Exadata and RAC customers with demanding high workloads on the primary database. For Active Data Guard customers, they can have real-time access to the data being churned on the primary database. The ALTER DATABASE RECOVER MANAGED STANDBY DATABASE command now accepts a new INSTANCES [ ALL | integer] clause to start Redo Apply on multiple instances. The ALL option starts redo apply on all the RAC standby instances that are in open or mount mode. All the instances must be in the same mounted or open mode. One instance cannot be in open mode (Active Data Guard or read-only mode) while others are in mounted mode. The integer option specifies the number of RAC standby instances that will perform redo apply. We cannot specify which RAC instance(s) will perform the redo apply. Starting redo apply on multiple instances has the following restrictions: • In-Memory column store is not supported • Block Change tracking (BCT) is not supported. Redo stream is shipped to multiple RAC standby instances, redo apply performance is directly correlated to network bandwidth and latency between the primary and standby database environments. With the DGMGRL command line interface, we can configure which RAC instances in the physical standby environment apply processes should be executed to use the new Oracle Active Data Guard multiple instance Redo Apply feature.

Subset Standbys

When the Multi-tenant option was introduced in Oracle Database 12c Release 1 (12.1), the physical standby was at the container level and all pluggable databases (PDBs) had to participate in the physical standby configuration. As of Oracle Database 12c Release 2, Oracle added a new feature to allow number of PDBs to be… 


To receive a full version emailed copy of this document, including 3 more pages of Data Guard New Features, please complete the form provided.

Complete this form for an auto-emailed full version copy:

Full Name (required)

Your Email (required)

Company (required)

Phone number (required)

Job Title (required)