Scops Docs
Docs Download

Detector reference

This page lists every Radar Engine detector by category: what it finds, when it fires, and its key.

How to read this page

  • Key identifies the detector, with the object at the end in capitals, for example capacity|tablespace|X. Wait events and log codes are in lower case.
  • Live detectors compare the last 10 minutes with the hour before and always run. The Checks switch of a category sets its hourly and daily detectors on or off.
  • General horizons are the three horizons in Radar Settings: 14, 45 and 90 days by default. Short horizons are fixed: 2, 7 and 21 days.
  • A reading is one live check. Radar makes one every 5 minutes.

What usual means

Radar learns the activity of each database: all active sessions, and the sessions that wait for each other (Application, Commit, Concurrency, Configuration and Other waits). It learns three things for each 5 minutes of the day:

  • The usual of these 5 minutes, on days of the same kind (weekdays or weekends).
  • What the activity reaches around this time on most days: the highest 5 minutes of the half hour before and after.
  • What it reaches around this time on the same weekday. At least two of the last four weeks must reach it.

A reading is unusual only when it is above all three. The finding then says which usual it is above. If a reading is not above all three, the check says which usual explains it, for example on Wednesdays it reaches 40 around this time. Until Radar has learned a database, the size lines decide alone.

Watch or Warning

A Watch shows on the Radar page and on the Dashboard only. A Warning also shows on Databases > Issues. A finding is Watch, not Warning, when:

  • It is a routine of this database. It was there at this hour on 2 of the last 7 days, or on 4 of the last 7 days at any hour, or it came and went often in the last 7 days. Its title says which, for example usual at this hour.
  • It is on a CDB root, and a PDB of that root tells the same finding on its own registration.
  • It is not a material part of the activity of the database. For most live findings, that is at least 2 sessions and a tenth of the active sessions (now, or usually at this time when that is more).

A routine keeps its level when it is clearly worse than before: 1.5 times the largest earlier episode, or open twice as long as the longest one. Where the size is the harm (sessions blocked, Data Guard, space), a higher level than before is also worse. Backup findings measure their own schedule and are never lowered as a routine.

A finding that was shown as a Warning stays a Warning until its condition ends, also when its share of the activity becomes smaller.

For about eight days after an upgrade, Radar does not know the size of the older episodes. In that time it can lower a finding as a routine without the size test. Findings that measure a harm still go up and send mail.

When Radar sends a mail

Radar sends a mail for a finding at or above the Minimum level of E-mail. The default is Critical: a Warning shows on Databases > Issues and is not mailed. Set the level to Warning to get a mail for a Warning also.

  • A Critical finding needs a harm that Radar measures: sessions that are blocked, work that stops, a log switch or a disk that stops the database, a limit or a space that runs out, redo that is at risk on a standby.
  • A level alone is never Critical. A load surge, a sudden wait event and a deadlock storm show at Warning at most. Radar does not mail them, also when the Minimum level is Warning.
  • A finding that must stay, such as a lock queue or a CPU shortage, needs three readings in a row. With the confirmation check, the mail goes on the fourth check in a row, a quarter of an hour after the first reading on the line.

Capacity

Space and CPU that run out. Switch: Capacity.

Finding and keyWhat it findsWhen it fires
Tablespace X filling up
capacity|tablespace|X		Hourly forecast, above 30% of the maximum size, after three days of readings.General horizons. 90% and not growing for 24 hours: Watch. 90% with 5 GB or less left: at least Warning.
Tablespace X filling fast
pulse|tbs_fill|X		Live. 70% or more, with steady growth for 90 minutes.Full within 1 hour: Critical. Within 6 hours: Warning. Else, or the usual night load: Watch.
Temp tablespace X nearly full
capacity|temp|X		Hourly, over 24 hours.Average 75%, or three hours at 90%: Watch. Three hours at 90%, rising, under 5 GB free: Warning.
Temp space X filling
pulse|temp_burst|X		Live.98%, or sessions wait for TEMP space: Critical. 95% and rising: Watch.
Undo tablespace X nearly full
capacity|undo|X		Hourly, over 24 hours.High and held by an open transaction: Warning. Unexpired undo only: no finding.
FRA filling up
capacity|fra		Hourly forecast and level.80% and full within 6 hours, or 92%: Critical. Full within 24 hours: Warning. Daily trend: short horizons. Not below 85% for 24 hours, or the same peak on earlier days: Watch.
ASM disk group X running low
capacity|asm|X		Hourly forecast and level.Trend: general horizons. Under 1% headroom and 50 GB usable: Critical. Under 2% and 100 GB: Warning. Under 5%: Watch.
ASM space running out
capacity|asm		Daily forecast for all disk groups.General horizons.
Datafile space running out
capacity|db_alloc		Daily forecast: datafiles to their maximum size, then ASM.General horizons on the date when ASM is full. Else Watch.
PDB storage filling up
capacity|pdb_storage		Hourly forecast against MAX_PDB_STORAGE.As for a tablespace.
User X quota on T / User quotas on T
capacity|ts_quota|X.T		Hourly. Three or more users on one tablespace give one finding.90% of quota: Watch. Full within 7 days at its measured growth, or full while it grows: Warning. A quota near its limit that does not grow stays Watch.
CPU capacity running out
capacity|cpu		Forecast of the busiest hour of each day over 14 days, against 85% of the CPU threads.General horizons. Above 85% on three of the last seven days: Watch. With sessions in the queue: Warning. Busiest hour at 95%: Critical.
CPU saturated
pulse|cpu_saturation		Live. Sessions on CPU or in the queue, against the usable CPUs. The CPUs are short when the demand is above them and the sessions on CPU use 85% of them or more. Sessions that the resource manager holds back (resmgr:cpu quantum) then count as sessions in the queue. This includes an instance that cpu_count limits.The CPUs short on three readings in a row: Critical. Rising toward them: Warning, with an ETA. Over the CPUs only because the resource plan holds sessions back: Warning at most, and the finding says so. On a CDB root, a PDB that shows CPU saturated with at least half of the busy CPUs tells it, and the root shows Watch.

Limits

Parameters and pools that run out. Switch: Limits.

Finding and keyWhat it findsWhen it fires
Processes near the limit
resource|processes		Hourly level and forecast, against processes (ORA-00020).90%: Critical. 80%: Warning. 70%: Watch. Repeated peaks at 97%: Critical, at 90%: Warning. Trend: short horizons.
Sessions near the limit
resource|sessions		Hourly, against sessions (ORA-00018).As for processes.
Datafiles near the limit
resource|db_files		Hourly, against db_files.85%: Watch. Also full within 30 days: Warning. Under 3 left at 98%, or full within 2 days: Critical.
Parallel server pool full
resource|px_servers		Hourly. Full in 3 of 6 hours, with downgraded statements.Warning. With ORA-12827: Critical. Usual at this hour: Watch.
Connection leak from M
resource|conn_leak|M		Hourly. The sessions of one module rise for days.Watch. Session use at 60%: Warning.
Open cursors climbing
resource|cursor_leak		Hourly. Open cursors rise for days, sessions do not.Watch. Doubled: Warning.
Processes running out
pulse|process_runway		Live. The limit within 90 minutes.Warning. Within 20 minutes, or 90% used: Critical.
Session surge
pulse|session_surge		Live, against the hour before.75% of the limit: Critical. 50%, or three times the usual and rising: Warning. Else Watch.
Logon storm
pulse|logon_storm		Live. 5 logons a second or more, against the hour before. Parallel servers are not logons: when most active sessions are parallel servers, there is no logon storm.Only when process use is at 80%, or rose 10 points in 30 minutes: Warning. Five times the usual and 15 a second: Critical. Process limit not read: Watch. On a PDB, the CDB root must be in Scops for a Warning, because the process limit is the instance's.
PGA near its limit
pulse|pga_pressure		Live, against pga_aggregate_limit.85%, or the limit within the hour: Warning. 95%: Critical.
Host CPU busy
pulse|host_cpu		Live. 85% or more, less than half of it from the database.Warning, when this database runs at least 2 active sessions now or usually at this hour. Else Watch: the host is busy with other work. 95% with a run queue of twice the cores: Critical, whatever the database runs.
Shared pool draining
pulse|shared_pool_drain		Live. Free memory decreases.Warning. 3% or less: Critical.
Redo log switches wait for archiving, Redo log switches wait for a checkpoint, Sessions wait for free buffers, Sessions wait for writes to complete
pulse|event_watch|EVENT		Live. log file switch (archiving needed), log file switch (checkpoint incomplete), free buffer waits, write complete waits. Named from 0.3 active sessions (archiving) or 1 (the others).The two log switch waits stop every session that writes: Warning from 2 sessions held, at any share. Free buffer waits and write complete waits, held for 3 minutes: Warning at 2 sessions and a tenth of the activity. A Warning stays until the wait drains. 20 sessions and half of the sessions active now, with the newest minute still stalled, on two checks in a row: Critical, mailed at once. A log switch that waits for archiving is never lowered as a routine. Other stalls are lowered to Warning at most.

Wait trend

Waits that surge or appear. Switch: Wait trends.

Finding and keyWhat it findsWhen it fires
New wait event: E
ash|emerging|EVENT		Hourly. 10% of the waits of six hours, almost absent in the seven days before.Watch, above Wait trend minimum (active sessions).
Concurrency waits surging (also Application, Commit, Configuration, Other)
pulse|wave|CLASS		Live. The sessions that wait for each other (Application, Commit, Concurrency, Configuration and Other waits together) are 5 or more, and a quarter or more of all active sessions. They must also be more than this database usually has, or usually reaches, at this time (see What usual means). The row names the class with the most. RMAN's own sessions, the sessions of Scops and the excluded wait events are not counted. When it is shown, the wave stays while it stays at or above the usual it rose over.Warning. Lock waits (row and table locks, user locks, library cache locks and pins, row cache locks) of 20 or more sessions and half or more of all active sessions on three readings in a row, with half of them measured blocked: Critical. Any other wave: Warning at most. When the work of the database stops, Executions stalled is Critical and shows on the row of the wave. A wave on a CDB root in another class than the wave on its PDB is a finding of its own.
Database load surge
pulse|load_surge		Live, against the usual of this hour. Three times the usual or more, and 15 active sessions or more above it, on two readings in a row. It must also be more than this database usually has, or usually reaches, at this time. Sessions that wait for another database or a client, and the sessions of Scops, are not counted.Warning. Never Critical: a load alone is not a harm. Also when other rows fold under it, a Critical row of the same incident owns the incident.
Sessions blocked
pulse|blocking_pileup		Live. Sessions that wait for an application lock that another session holds: a row lock (enq: TX), a table lock (enq: TM), a user lock (enq: UL), or a library cache lock or pin or a row cache lock of a DDL. Other enqueues and queues on a buffer or block are not counted. The wait event and wave rules tell them. A queue behind RMAN's own session is the backup's: Watch.10 sessions blocked for 3 minutes: Warning. 20 sessions or more, and half or more of the sessions active now, on three readings in a row: Critical. A lock queue under 5 sessions gives no finding.
Waits on E
pulse|event|EVENT		Live. A wait event that was almost absent in the hour before and now carries a large share of the waits. RMAN's own sessions and the sessions of Scops are not counted.Watch. Warning when the event is large enough for this database: 5 sessions for an event that holds sessions up (Application, Commit, Concurrency, Configuration and Other waits), 15 sessions for any other event (reads, the cluster, the scheduler), and a tenth of the activity. An event that is not a stall (a lock, a latch or mutex, a hot block, a log switch) also needs the database busier than usual at this hour, unless it holds a quarter of the activity and 15 sessions. Sessions that wait for another database or a client (Network waits) are Watch at most. Never Critical. A Warning stays until the event drains. Of the new events of one incident, only the largest becomes a Warning.

Ignore daily patterns lowers waves, session surges, CPU saturation, sudden wait events and the watched waits to Watch when they occur at the same time each day. It never lowers a log switch that waits for archiving. It also sets on or off the routine test "at this hour on 2 of the last 7 days" of all findings (see Watch or Warning).

A database that waits on a hung remote database over a database link shows a Watch, not a Warning. The remote database tells the problem on its own findings. If the local work stops, Executions stalled tells it.

SQL

Statements that became slower on a new plan or take most of the database. Switch: SQL. A SQL finding needs 15 minutes of database time an hour, from the SQL of your applications. A statement that is slower on the plan it had is not a finding.

Finding and keyWhat it findsWhen it fires
SQL S slower on a new plan
sql|plan_regression_days|SQL_ID		Daily. 1.5 times slower per run for several days, at 100 ms and 30 runs or more, and its plan changed when it became slower (from the day before its first slow day to the end of that day). A later plan change is a finding only when it makes the statement 1.5 times slower again.Warning.
SQL S slower on a new plan
sql|plan_regression|SQL_ID		Hourly. The last hour 1.5 times slower than the five before, on a new plan: the plan changed in the last six hours, or came in the last 7 days. Not if the statement only moves between plans that it ran before. Not if it was as slow at this hour a day or a week ago, or only waits on another session.Warning.
SQL S on a new plan
pulse|new_plan|SQL_ID		Live. A new plan.Warning. Three times slower, and it adds a full active session: Critical.
SQL S taking most of the load
pulse|sql_hog|SQL_ID		Live. Half or more of the active sessions, and active sessions of at least a tenth of the CPUs of the host (when the CPU count is known).Above the usual of this hour: Warning. More sessions than CPUs: Critical. Always so at this hour: Watch. A Warning stays until the statement stops.

Operations

Backups, Data Guard, jobs, accounts and schema objects. Switch: Operations.

A physical standby skips the dictionary checks when Radar also checks its primary. A PDB shares the backup findings of its container: without the container in Scops, a PDB has no backup findings. When a primary sends redo to a standby that is not in Scops, its backup findings give the name of that standby.

Finding and keyWhat it findsWhen it fires
Backup late
ops|backup_age		The last full or incremental backup, against the usual interval.Overdue: Watch. 1.5 times the interval (3 days at least): Warning. 2.5 times (7 to 21 days): Critical. Too few backups left to count the interval: Warning at 3 days, Critical at 7. No backup schedule ever measured (one backup time or none on record): Warning at most. Never lowered as a routine.
ARCHIVELOG backup missed
ops|backup_missed|ARCHIVELOG		The archivelog backup, also on a standby, against its own interval. Both lines are at least 1.5 times the longest usual gap of a day, so a nightly pause is not a missed backup.Three times the interval (at least 6 hours more): Warning. Six times (12 hours at least): Critical. Never lowered as a routine.
Backup smaller than usual
ops|backup_size|K		New. The size of a completed full or level 0 backup, against its own earlier runs and the database size at those runs. A level 1 against the level 0 before it. Only where the backup list has five earlier runs of the kind.Under two thirds of its usual and outside its spread: Warning. A level 1 as large as the level 0, where the earlier level 1 backups were smaller: Watch. Never Critical.
K backup failing
ops|backup_failures		Failed runs in a row.Warning. No success for 48 hours or six intervals: Critical.
K backup running long
ops|backup_overrun|K		A run far longer than usual, or with no progress.Long: Watch. No progress for three hours: Warning. A stuck archivelog backup while the FRA fills: Critical.
K backup getting slower
ops|backup_duration|K		Runs that take longer day by day.Watch.
Standby falling behind
ops|dg_gap		Archived logs not on the standby, above the usual gap. Redo is at risk when, on any thread, logs have not reached the standby and there are more of them than an hour before, or when the standby reports a gap and the gap grows.Growing: Watch. 10 behind and steady: Warning. 20 and growing with redo at risk: Critical. Logs that arrived but are not applied: Warning, and the finding says no redo is at risk. Apply more than one day behind and 1.5 times its usual daily lag (from the days before this episode): Critical. Late against its usual catch-up time by less than half of its usual drain: Watch. In its nightly window, a gap under 1.5 times its typical peak is the routine of the standby. The window never lowers a gap with redo at risk. While its destination fails and shows its own finding, and while it drains after that: Watch.
Standby transport lag · Standby apply lag
ops|dg_transport_lag ops|dg_apply_lag		A lag above the usual lag.3 minutes above: Watch. 10 minutes: Warning. One hour: Critical.
Apply stopped on standby S
ops|dg_apply_stopped|DEST		Redo apply idle for hours.Warning. Critical only when redo is at risk (logs not on the standby, and more of them than at the last apply, or a gap that the standby reports while the gap grows), or when the standby is more than one day behind and 1.5 times its usual daily lag. The usual is from the days before this episode: a standby that stays behind does not become its own usual. With every log on the standby: Warning, however long, and the finding says so. A planned deferral stays Warning.
Data Guard dest D not applying
ops|dg_unapplied|DEST		No applied archived log for a destination.3 hours: Warning. 12 hours: Critical.
Data Guard dest D failing
ops|dg_dest|DEST		A standby destination in error.Warning. Four readings in a row, or a fatal error: Critical.
Archive destination D failing
ops|archive_dest|DEST		A local archive destination in error.Warning.
NOLOGGING changes
ops|dg_nologging		NOLOGGING changes in 7 days, with a standby.Warning.
Old guaranteed restore point
ops|grp		The oldest one, and its FRA space.Watch. 14 days old, or 10% of a 70%-full FRA: Warning. 20% of an 80%-full FRA: Critical.
Long-running transaction
ops|runaway_txn		The largest open transaction: 3 hours, 2 GB of undo, and growing.Warning. The undo tablespace cannot hold it: at its growth, the free undo space lasts less than 8 hours, or it holds half of the undo: Critical. Undo not measured: Warning, and the finding says so. Usual at this hour: Watch.
Shared pool low on memory
ops|shared_pool		Free memory on the worst instance.Under 3%: Watch. Under 1% and well under its usual: Warning.
Executions stalled
pulse|throughput_collapse		Live. Executions fall while sessions wait on one event or a blocker.Warning. 10% of normal for 5 minutes on a named stall (a log switch, a lock, a latch or mutex, a hot block, the resource manager's queue), or 30 sessions behind one blocker: Critical. A stop on any other wait is Warning at most: it shows on the Issues page, with no mail.
Job J
ops|job_failures|JOB		Hourly. Failed, broken, stalled or overdue scheduler and legacy jobs.Failing: Warning 6 hours after the last success, Critical after 24. Broken, or a stalled chain: Critical. Overdue: Watch, one day: Warning.
Password of U
ops|pwd_expiry|USER		Daily. Accounts that are not Oracle-maintained or permanently locked, and the account of Scops.30 days left: Watch. 14: Warning. 3: Critical. An expired password stays a finding for 30 days.
Partitions of T running out
ops|partition|TABLE		Daily. The last range partition of a table that is not kept ahead.21 days: Warning. 7 days, or passed with ORA-14400: Critical. Else Watch.
MAXVALUE partition of T in use
ops|partition_max|TABLE		Daily.Watch. For 7 to 31 days and growing: Warning.
Sequence S running out
ops|sequence|SEQUENCE		Daily, at the current daily use.60 days: Watch. 21: Warning. 7: Critical.
Identity column C running out
ops|identity|COLUMN		Daily. As for sequences.As for sequences.
Invalid objects
ops|invalid_objects		Daily. A rise against the highest day of the 14 before: more than 10 objects (5 that do not compile), and more than a tenth of that day. Twice as many is a rise too. A standing pile of hundreds is a finding only when it grows by a material part of itself.Watch. More that do not compile this week: Warning.
Unusable indexes
ops|unusable_idx		Daily. Also index partitions.Watch. Rising, and 10 or more: Warning.
Alert A firing more often
ops|alert_recurrence|ALERT		An alert that fires four times or more this week, twice as often as the week before.Watch.
Instance restarted
ops|instance_restart		New. The start time of the instance, or the open time of a PDB, against the database clock. On a cluster, one finding for each instance (|N). The finding says when, how long the instance was up, and if it started twice in 24 hours. When Scops collects the alert log, the finding names the last ORA- error of the half hour before the start. After Scops itself restarts, the open finding keeps what Scops knew. A start in the last 21 hours 20 minutes is told when Scops first sees the database.A start in the last 21 hours 20 minutes: Warning. A second start on the same patch level within 24 hours: Warning. Planned maintenance: Watch. Scops counts as one maintenance the starts that come each within one hour of the one before. The maintenance is planned when the patch level after it differs from the level before it, however many starts it has. Databases of one host that start within one hour: one finding tells it, and the others are Watch. On a PDB, the CDB root tells it. Never Critical. On a PDB, Scops reads the open time of the PDB: it tells PDB opened at HH:MM also when only the PDB was closed and opened.
Parameter changed
ops|param_change|NAME		New. A parameter that a person changed, from the change log.Watch. The finding stays on the Radar page for 24 hours, and its mark stays on the chart for its first hour. Not on the Issues page. No mail. A change that the CDB root also shows is told on the root.

Logs

Errors in the alert, ASM, Grid and listener logs of each node. Switch: Logs. These detectors need the OS credential of the database (see Add a database).

Finding and keyWhat it findsWhen it fires
The error code or pattern, for example ORA-04031 or Cluster node evicted
oslog|CODE		Serious errors: an internal error, a corrupt block, an evicted node, a stuck archiver. Codes that often come before failures, such as ORA-04031, ORA-01555, ORA-00060, ORA-01652 and ORA-00020. Patterns such as lost global cache blocks or heavy swapping.A serious error for the first time in 24 hours: Critical. A code repeated over three days: Warning, five times: Critical. Listener codes: Critical only near the process or session limit. Steady network timeouts: only when they triple.
OS log errors rising
oslog|acceleration		The last 24 hours against the days before.Watch. A sharp rise of serious codes: Warning.

Anomaly

Readings far from their usual level for the hour and the day of the week. Switch: Anomalies. Settings: Spike threshold (K), Level change threshold, Repeat spike factor and Minimum values.

Finding and keyWhat it findsWhen it fires
Unusual User I/O waits (one for each wait class) · Unusual CPU load
anomaly|live|ash|CLASS		Hourly, against the same hour on other days. A class must matter for this database: a lock, latch or commit class 5 sessions or more, any other class 15 sessions or more over its normal, and a quarter of the active sessions of the hour (or of the usual of that hour, when that is more).By size, duration and cause. Watch: too small for this database, the usual load, many statements, mostly a backup or a database link, or no explanation. Critical only with a named cause, high for 3 hours, and a live harm of its own kind open in the hour at Warning or more: sessions blocked for lock and commit classes, slow reads for User I/O and System I/O, a full CPU for CPU and Scheduler, and stopped work for every class. A load surge or a sudden wait event is not a harm. Else Warning at most. A class that the size test admitted keeps its level for the rest of the episode. After an upgrade, Radar judges again the rows that the earlier version opened. On a CDB root, a PDB whose row reads now at least half of the root's reading tells it, and the root shows Watch. A new row on a CDB root with PDBs in Scops is Watch on its first check, and Radar decides it on the next check, five minutes later. Radar mails one such finding at most for each database.
Unusual single-block read latency · Unusual rollbacks
anomaly|live|metric|METRIC		Hourly. Read latency with User I/O waits, and the share of rollbacks.By size and duration. The hourly read latency is always Watch: one slow minute can make the mean of an hour high. Slow single-block reads judges the minutes. As for other Watch findings, the mark stays on the Dashboard chart for its first hour only.
Unusual M (record hour)
anomaly|live|record|METRIC		New. Hourly. A load or resource metric (executions, calls, reads, writes, redo, parses, cursors, sessions, CPU and similar) at 1.5 times or more of its highest hour in the month of hourly history before. The finding names the active sessions of the hour against their usual, and the wait class or live load findings of the same hour.Always Watch. It shows in the findings of the Metrics page and as a mark on the Dashboard chart for the month. Not on the Issues page. No mail. One finding for each database and run of high hours (it names the other metrics at a record), told for one day from its first record hour. If that metric is no longer high while another metric of the same event is still at a record, the other metric opens a record finding of its own: two marks on the chart. Only record findings keep their mark on the chart for the month. It needs a month of hourly history: a database in its first month gets none. On a PDB, read requests, write requests and table scans are not measured.
Unusual waits of a class, Unusual metric (daily)
anomaly|ash|CLASS anomaly|metric|METRIC		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, only when what it adds matters (sessions: 2 sessions and a tenth of the load; CPU: 2 cores and a tenth of the CPUs). Other daily metrics (reads, writes, redo, executions, open cursors and similar) stay Watch.
Unusual database growth
anomaly|dbsize		Daily. Growth far above the usual, or a lasting change.Watch. If the space limit comes within 90 days: Warning.
Slow single-block reads
pulse|io_latency		Live. Well above the usual, in 3 of 10 minutes. On flash storage from 2 ms, else from 9 ms.Watch. 9 ms or more, on any storage, with sessions that wait more on reads: Warning. Five times the usual without twice the reads: Critical.
Slow commits
pulse|commit_latency		Live, at 5 commits a second or more. Its size is the sessions that wait on commits.Warning at 2 sessions and a tenth of the activity. A Warning stays until it drains. Eight times the usual and 50 ms or more, with a quarter of the sessions active now waiting: Critical. When commits stop and fewer than 2 sessions wait on log file sync, the finding ends.
RAC interconnect trouble
pulse|rac_gc		Live, RAC only. Lost blocks, or transfer times three times the usual, for 10 minutes.Lost blocks: Warning, only while the sessions on Cluster waits are a material part of the activity. Lost blocks and slow transfer times: Critical.
Hard parse storm
pulse|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.
Deadlocks
pulse|deadlock_storm		Live. A burst is 5 deadlocks or more in 3 minutes.Watch. Bursts that keep arriving on three readings in a row: Warning. After a background of deadlocks in the hour before, a Warning also needs more deadlocks in these 10 minutes than in that whole hour. A Warning stays until the storm drains. Never Critical, and not mailed by default.

Use the keys

In Radar Settings, type a key in Exclusions to hide a detector, or in Minimum level by risk type to set its mail level. * matches any object.

GoalPattern
Never report a scratch tablespacecapacity|tablespace|SCRATCH_DATA in Exclusions. It also hides pulse|tbs_fill|SCRATCH_DATA.
Ignore password expiryops|pwd_expiry|* in Exclusions
Mail hourly metric anomalies only when Criticalanomaly|live|metric|=CRITICAL in Minimum level by risk type
Mail new SQL plans only when Criticalpulse|new_plan|=CRITICAL in Minimum level by risk type

To stop one risk on one database only, mute it.

How Radar worksSettings, severity, causes and mail. Alert policiesAlert rules, built-in alerts and your own SQL alerts.

Updated November 10, 2026