Resources

Oracle Database Anomaly Detection: How Radar Learns What Is Usual

4 November 2026

Anomaly detection for an Oracle database compares each reading with its usual level for that hour and that kind of day, not with a fixed line, and raises only what is far from it and not explained by the usual pattern. Radar Engine in Scops does exactly that for every database: it learns the usual level of every hour from the database's own history, weekdays and weekends apart, and by default a spike must stand 3.5 standard deviations above the usual band before it counts. It uses statistics and rules, not an AI model, so every finding can be checked against its numbers. It needs no agent and no Diagnostics Pack, and Enterprise Manager's adaptive thresholds need exactly that pack.

Why a fixed threshold fails on Oracle

A database has a rhythm. The batch runs at 02:00, the users arrive at 09:00, the month closes on the last day, and the weekend is quiet. A line that fits noon fires all night in the batch window, so the on-call DBA learns to ignore it. A line that fits the night misses the morning. And the problems that matter most cross no line at all: a statement that got three times slower at 11:00 adds load that would be normal at 14:00, and a level that drifts up 5% a day never looks like an alarm on any single day.

Anomaly detection replaces the one line with one usual level per hour, learned from the database itself, and asks a better question: is this reading far from what this database does at this hour?

How Radar learns the usual level

Per hour, per kind of day. Radar learns the usual level of each hour, for weekdays and weekends apart. The usual Monday 10:00 and the usual Sunday 03:00 are different numbers.
From the database's own history. It needs about 10 days of history for weekdays and three weeks for weekends. Until then, the hours without enough history are not graded.
From data Scops collects itself. Session samples every 5 seconds, SQL statistics every 10 minutes and one-minute metrics, kept in the Scops repository, on Standard Edition 2 as on Enterprise Edition.
Visible on every chart. On the Metrics page the usual level is the dashed line, the normal for those hours, and each chart carries a badge: amber when the window average is more than 3.5 standard deviations above normal, "the same test as Radar Engine", and red at twice that distance.

What counts as an anomaly

Radar looks for two shapes, a spike and a lasting change of level, and then removes what the database always does. Every rule is a setting, with these defaults:

Setting	What it does	Default
Spike threshold (K)	How far above the usual band a spike must be.	3.5
Level change threshold	How large a lasting change must be.	3
Repeat spike factor	How much larger a repeat spike must be.	1.5
Minimum values	Radar ignores anomalies below these values.	Empty
Ignore daily patterns	Lowers to Watch a surge at the same time on recent days.	On
Matching days needed	The days of the last 14 that must show the same peak.	3
Repeats before Watch (7 days)	Lowers to Watch a risk that comes and goes this often.	5
Wait trend minimum (active sessions)	Radar ignores new wait events below this value.	0.5

Two more rules keep the findings honest. If a finding comes back at the same hour on two of the last seven days, it becomes Watch, and its title ends with "usual at this hour"; an episode ten times larger than all earlier ones keeps its level. And a live finding becomes Critical only after two cycles in a row, while a severity goes down only after two cycles at the lower level, so one noisy reading neither pages anyone nor clears a real problem.

From anomaly to finding

A reading far from its usual level is a start, not an answer. Radar grades each anomaly by size, duration and cause before it decides how loud to be. For the hourly anomalies of the waits and the CPU load, the rule is explicit: the usual load, many statements, mostly a backup or a database link, or no explanation stays at Watch; Critical needs a named cause, three hours high, or an open blocking chain, stalled executions or slow reads; everything else is Warning at most, and Radar mails at most one such finding for each database. Each finding then names its cause with a grade, from Named, one statement, module, job or session with a change behind it, down to Not found, and shows the numbers against the normal and a chart of when it started.

The anomaly detectors

These come from the Anomaly category of Radar's detector reference, the readings that are judged against their usual level for the hour and the day of the week:

Detector	Clock	When it fires
Unusual User I/O waits (one for each wait class) · Unusual CPU load	Hourly, against the same hour on other days.	By size, duration and cause. Critical only with a named cause, high for 3 hours, while blocking, stalled executions or slow reads are open. Else Warning at most.
Unusual single-block read latency · Unusual rollbacks	Hourly. Read latency with User I/O waits, and the share of rollbacks.	By size and duration.
Unusual waits of a class, Unusual metric (daily)	Daily. A spike of one day, or a lasting change of level.	Watch. A change of level near a plan, parameter or statistics change: Warning.
Unusual database growth	Daily. Growth far above the usual, or a lasting change.	Watch. If the space limit comes within 90 days: Warning.
Slow single-block reads	Live. 9 ms or more and well above the usual, in 3 of 10 minutes.	Watch. With User I/O waits: Warning. Five times the usual without twice the reads: Critical.
Slow commits	Live, at 5 commits a second or more.	Warning. Eight times the usual and 50 ms or more: Critical.
Hard parse storm	Live. 30 hard parses a second, far above the hour before, with shared pool problems.	Warning. Five times the usual and 90 a second: Critical.

The same usual-level test runs through the rest of Radar's 75+ detectors: a database load surge against the usual of the hour, a statement slower per run than at the same hour a day or a week ago, a new wait event that was almost absent in the seven days before.

Test it on your own history

Sensitivity is yours to set, and you can see the result before you change anything. In Radar Settings, Test on History runs the checks over 3 to 30 days of one database with the settings in the dialog, also unsaved ones, and Compare K tries spike thresholds from 2.5 to 5 and shows the findings each would have raised. The test saves and sends nothing. A higher threshold gives fewer findings, and each rated finding feeds the Quality view, where precision per category shows whether a threshold, a mute or an exclusion is the right move.

The usual level, by hand

Oracle keeps the last hour of its system metrics in memory, and that is enough to see the shape of a minute:

SELECT begin_time, ROUND(value, 1) AS avg_active
FROM   v$sysmetric_history
WHERE  metric_name = 'Average Active Sessions'
AND    group_id = 2
ORDER  BY begin_time;

A usual level per hour needs weeks of those minutes. Kept in a table of your own, the band is an average and a standard deviation per hour and kind of day, and a reading is an anomaly when it stands K deviations above it:

SELECT hr, day_kind,
       ROUND(AVG(avg_active), 1)    AS usual,
       ROUND(STDDEV(avg_active), 1) AS spread,
       ROUND(AVG(avg_active) + 3.5 * STDDEV(avg_active), 1) AS spike_at
FROM  (SELECT TO_CHAR(begin_time, 'HH24') AS hr,
              CASE WHEN TO_CHAR(begin_time, 'DY',
                     'NLS_DATE_LANGUAGE=ENGLISH') IN ('SAT', 'SUN')
                   THEN 'weekend' ELSE 'weekday' END AS day_kind,
              avg_active
       FROM   my_load_history
       WHERE  begin_time > SYSDATE - 28)
GROUP  BY hr, day_kind
ORDER  BY day_kind, hr;

That is the first line of anomaly detection, for one metric on one database. Oracle's own version, the dynamic metric baselines and adaptive metric thresholds of Enterprise Manager, is listed in the licensing manual under the Diagnostics Pack. Radar Engine does the whole job, for every reading of every database, with the daily patterns, the repeats, the grading and the cause, on every edition and with no pack.

Questions

What is anomaly detection in Oracle monitoring?
Comparing each reading with its usual level for that hour and kind of day, learned from the database's own history, instead of with a fixed threshold, and raising what is far from it and not explained by the usual pattern.

Is Radar Engine an AI model?
No. Radar uses statistics and rules, so every finding can be explained with its numbers: the reading, the usual level and the distance between them. Scops AI, the assistant, explains findings in plain words and prepares the fix.

How much history does Oracle anomaly detection need?
In Scops, about 10 days for weekday hours and three weeks for weekend hours. Live checks against the hour before work from the first day.

Can I make Radar more or less sensitive?
Yes. The spike threshold K defaults to 3.5 and Test on History with Compare K shows what values from 2.5 to 5 would have found on your own data before you save.

Does anomaly detection need the Diagnostics Pack?
Not in Scops: Radar learns from the data that Scops collects itself, on every edition. Enterprise Manager's dynamic metric baselines and adaptive metric thresholds are part of the Diagnostics Pack.

Sources

Oracle: V$SYSMETRIC, V$SYSMETRIC_HISTORY, Database Licensing Information User Manual
Scops docs: How Radar works, Detector reference, Metrics