Skip to main content

08 DB

DB summarizes whether the database contributes impact signals to SAP service.

Operations DB with anonymized data
DB domain with panels according to the available engine.

What appears​

  • Database health: a specialized card with engine, state, and 0–100 score, together with its trend.
  • Oracle: health, three protection statuses, and panels for archiver, caches, redo, locks, segments, dictionary consistency, and tablespace capacity/free space. Each family retains its series; identities are not merged.
  • MSSQL: signals ordered into Capacity, Performance, and Protection, in panel pairs that retain their line, area, or step variant.
  • HANA: generic health when it is the available engine.
  • Events remains at the end of the domain.

Engine-specific blocks appear only when applicable. When a section has only one applicable panel, it uses the full available width.

Each signal retains its real cadence: Database health is collected every 30 minutes and stays fresh for 90; I/O, hit ratio, page life, and oldest transaction use 15/45 minutes; transaction log and log backup use 1/3 hours; file free percent/space and backup age use 24/72 hours. SPOT connects samples only inside that horizon and never invents zeroes or extends a stale snapshot.

When the global window is shorter than that freshness, Operations queries at least each DB panel's own horizon. For example, Last 15 min can show the latest daily snapshot while it is still fresh, always with its real SAP time. Metrics Explorer keeps the exact range when you need to verify which observations fell strictly inside those 15 minutes.

Database health is a state signal and does not offer Expected range, Forecast, or ML scores. Numeric DB panels keep Analysis when their canonical policy supports ML.

Oracle identity​

The Oracle database-health metric uses only server=Oracle, group=CCMS_ORA_health_check_run_pfcl, object=Database health check, and metric=Last succ. database check. It does not depend on segment/monitor and is never inferred from latency, tablespaces, or backups. Tablespaces, archive backup, full backup, and optimizer statistics use their own exact CCMS_ORA_* leaves and remain independent signals. It is the only visible health panel. This check and the three protection states read LASTALSTAT; when it is absent or invalid, SPOT omits the observation and never reuses LASTPERVAL. Tablespaces and all other gauges keep their numeric LASTPERVAL value.

SPOT classifies the 48 observed Oracle identities into eleven visible families:

  • Health: the exact database health signal;
  • Protection: archive backup, full backup, optimizer statistics, and archiver destination usage;
  • Performance: buffer cache, library cache, and redo log buffer;
  • Capacity: exclusive-lock age, segment checks, and used/free space by tablespace;
  • Consistency: inconsistent, missing, optional, or unknown objects in the dictionary.

Dynamic tablespace names are accepted only when object and group match exactly. An unrecognized observation is not shown under another family. SPOT does not invent thresholds or change units when source semantics have not been verified. The eight raw Oracle families show the CCMS number with unit raw, split series by object and check, aggregate each bucket with max, and do not offer thresholds or ML. They are not labelled as percent, seconds, MB, count, or state. This Oracle expansion does not change MSSQL panels, queries, or colors.

current shows the latest exact observation. The normalized Database health signal retains the real worst state and, without genuine health for 90 minutes, remains stably UNKNOWN. The three Oracle Protection states are collected every 60 minutes and remain fresh for 180 minutes; unrelated raw gauges cannot make health alternate with OK.

How to interpret it​

  • OK: the exact health signal reports a normal state.
  • WARN: that same signal reports a warning.
  • KO: that same signal reports a failure.
  • UNKNOWN: no valid observation exists within that signal's own freshness; it does not mean that its last historical value was zero.

Do not read DB in isolation. A DB warning with normal dialog response may be a background trend; a DB warning together with Work Process saturation, canceled jobs, or high dialog response time is usually more actionable.

Filters and next screens​

Use the same time range as the user-visible incident. Cross-check Performance for dialog and DB request time, Jobs for batch impact, Metrics for raw series, and Events for database or system messages in the same interval.