View the Exhibit to examine the output of the DBA_OUTSTANDING_ALERTS view.
After 30 minutes, you executed the following command:
SQL> SELECT reason,metric_value FROM dba_outstanding_alerts;
REASON METRIC_VALUE
—————————— ———————-
Tablespace [TEST] is [28 perce 28.125 nt] full
What could be the reason for the elimination of the other rows in the output?
A.
An Automatic Workload Repository snapshot has been taken recently.
B.
The non-threshold-based alerts are transferred to DBA_ALERT_HISTORY.
C.
The threshold alerts conditions are cleared and the alerts are transferred to BA_ALERT_HISTORY.
D.
The threshold alerts related to database metrics are permanently stored in DBA_ALERT_HISTORY
but not the threshold alerts related to instance metrics.
Exhibit not showing
The server generates two types of warning: warning threshold and non-threshold warning.
Most server-generated alerts by setting warning thresholds and critical thresholds for database metrics configuration. For more than 120 metric defined thresholds, these measures include:
• Physical reads per second
• the number of submissions per user
• SQL Service Response Time
In addition to space usage metrics database table space associated with, other metrics are relevant examples. Threshold warning also known as “stateful warning” after emptying alarm conditions, these warnings are automatically cleared.
There are warning status is displayed in the The DBA_OUTSTANDING_ALERTS, will go DBA_ALERT_HISTORY after emptied.
Other warning generated by the server corresponds to a specific database events, such as ORA- * error, “snapshot too old” error, “recovery area free space is too small” and “restore session is suspended” and so on.
These are not the threshold-based alerts, also known as “No state warning.”
Stateless warning will go directly to the history table.
Only in Database Control environment, clear warning stateless makes sense, because the Database Control in its repository to store stateless warning.