There are two properties in the Failover Properties section; they are set to 30 seconds by default, but can be changed. The Failover Threshold property is the amount of time that the primary database must be unreachable to initiate the failover, and Lag Limit is the maximum lag between the primary and standby databases, beyond which a fast-start failover will not be allowed. Now click on Edit next to User Configurable Failover Conditions. We're able to specify conditions that should cause a fast-start failover if detected on the primary database in this page. Click on OK to apply any changes and go back to the fast-start failover configuration page.
We've seen which properties of Data Guard can be changed with the Enterprise Manager Cloud Control interface. We've also examined the steps and options for enabling a fast-start failover using Cloud Control.
Now enable and disable the real-time query (Active Data Guard) option on the physical standby database using Cloud Control. At the same time, check the standby alert log file to track the statements run on the database.
Enterprise Manager Cloud Control offers a separate screen to monitor Data Guard performance. We can access this screen by clicking on Availability and then on Data Guard Performance on the database home page. Here's a screenshot of the Data Guard Performance page:
We will see the following information on the performance page:
The redo generation rate of the primary database and the Redo Apply rates of the standby database are important information for Data Guard management. We can use this information to calculate how much time it takes for resynchronization when there's a lag. Also, we can use this information to calculate Recovery Time Objective (RTO) when a physical standby is opened as a snapshot standby or when we stop synchronization for maintenance operations.
Note that the apply rate on this screen is not the Redo Apply capacity of the standby database. It shows the current state of Redo Apply. So if the load on the database is low, we'll see lower apply rates than its actual capacity. We can determine the Redo Apply capacity of a standby database when the Redo Apply process does not wait for a new redo to arrive. So we can achieve this by stopping Redo Apply for a while and starting it again or increasing the redo generation rate on the primary database to a higher value.
On the Data Guard Performance screen, we can click on the charts to reach the historical information.
The Data Guard Performance screen of Cloud Control has another part named Test Application. We can see the Start and Stop buttons here. When we start a test application, it generates a load on the primary database. Then we can pause or stop it at any time. This is useful if you want to see the behavior of a low-load Data Guard configuration under heavy load.
Enterprise Manager Cloud Control 12c provides a centralized incident management console called Incident Manager. This console is an advanced interface to track, diagnose, and resolve default and user-defined incidents. Additionally, it provides features to help rectify the root causes of recurring incidents. Incident Manager also provides lifecycle operations for incidents. It's possible to assign the ownership of an incident to a specific user, set the priority for an incident, escalate it or suppress it for a later time, and track an incident's status.
From the Data Guard management perspective, Incident Manager can help administrators be informed about the issues related to Data Guard, and help track and resolve them. We can define thresholds to default Data Guard metrics and also create user-defined metrics using SQL statements. When the current state of a metric reaches its threshold, an incident is created automatically.
To access the default metrics of Data Guard on the database home page, perform the following steps:
It's possible to define the thresholds of some of these metrics. We can define two values: the Warning and Critical thresholds. However, some of them are not editable because they're simple 0/1 controls such as Observer Status or Failover Occurred.
These metrics produce incidents; we can see the details of an incident on the Incident Manager page, which is accessible from the Enterprise menu, select Monitoring, and then Incident Manager. It's also possible to monitor incidents for a specific database by clicking on the Oracle Database menu and then going to Monitoring | Incident Manager on the database home page.