What could be the reason for the elimination of the other rows in the output?

View the Exhibit to examine the output of the DBA_OUTSTANDING_ALERTS view.
After 30 minutes, you executed the following command:

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.

Explanation:
Alert Types and Clearing Alerts
There are two kinds of server-generated alerts: threshold and nonthreshold.
Most server-generated alerts are configured by setting a warning and critical threshold values on
database metrics. You can define thresholds for more than 120 metrics, including the following:
Physical Reads Per Sec
User Commits Per Sec
SQL Service Response Time
Except for the Tablespace Space Usage metric, which is database related, the other metrics are
instance related. Threshold alerts are also referred to as stateful alerts, which are automatically
cleared when an alert condition clears. Stateful alerts appear in DBA_OUTSTANDING_ALERTS
and. when cleared, go to DBA_ALERT_HISTORY.
Other server-generated alerts correspond to specific database events such as ORA- * errors,
“Snapshot too old” errors, Recovery Area Low On Free Space, and Resumable Session
Suspended. These are non-threshold-based alerts, also referred to as stateless alerts. Stateless
alerts go directly to the history table. Clearing a stateless alert makes sense only in the Database
Control environment because Database Control stores stateless alerts in its own repository.