The broker computes the highest applied system change number (SCN) and uses its value to find the last continuous log that was archived to the standby database. The size of redo data in all subsequent log files are counted as data not applied. If the primary database goes down at this point, redo from these log files can be applied on the standby database. If there is a gap in the log files received on the standby database, any log files received after the gap cannot be applied.
For example, if log files 1, 2, 3, 6, 7, and 9 are received on the standby database and log apply services is currently applying log 1, log apply services can continue to apply up to log 3. Log apply services cannot apply any more log files because log 4 is missing. Even though log files 6, 7, and 9 are received, they cannot be applied and they will not be counted as data not applied. In this case, the total size of log files 1, 2, and 3 is the size of Data Not Applied.
If all the archived log files on the standby database are continuous, and standby redo log files are used, the standby redo log files are also counted as data not applied, unless real-time apply is turned on and log apply services is already working on the standby redo log files. The size of an archived log file is its file size. However, the size of a standby redo log is the size of the actual redo in the log and not the file size.
If the standby redo log files are multithreaded, the broker computes the highest applied SCN for every thread and totals the numbers. If there are multiple incarnations and the standby database is in a different incarnation from the primary database, each incarnation is computed separately and the results are then totaled.
The rest of the information in this section is only valid for this metric when it appears in either the Enterprise Manager Grid Control or the Enterprise Manager Database Control (if applicable).
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version |
Evaluation and Collection Frequency |
Upload Frequency |
Operator |
Default Warning Threshold |
Default Critical Threshold |
Consecutive Number of Occurrences Preceding Notification |
Alert Text |
10.1.0.x |
Every 5 Minutes |
After Every Sample |
> |
Not Defined |
Not Defined |
1 |
Standby database %dg_name% has not applied the last %value% megabytes of data received. |
For this metric you can set different warning and critical threshold values for each "Name" object.
If warning or critical threshold values are currently set for any "Name" object, those thresholds can be viewed on the Metric Detail page for this metric.
To specify or change warning or critical threshold values for each "Name" object, use the Edit Thresholds page. See Editing Thresholds for information on accessing the Edit Thresholds page.
Not available
No user action is required.
Related Topics
About Alerts
About the Metric Detail Page
Editing Thresholds
Understanding Line Charts
Copyright © 1996, 2009, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.