08 DB
DB fasst zusammen, ob die Datenbank Impact-Signale für den SAP-Service liefert.
Was erscheint
- Database health: Spezialisierte Karte mit Engine, Zustand und Score 0–100 zusammen mit ihrem Trend.
- Oracle: Health, drei Schutzstatus und Panels für Archiver, Caches, Redo, Locks, Segmente, Dictionary-Konsistenz und Tablespace-Kapazität/freien Platz. Jede Familie behält ihre Serien; Identitäten werden nicht zusammengeführt.
- MSSQL: Signale geordnet nach Capacity, Performance und Protection in Panel-Paaren, die ihre Variante line, area oder step behalten.
- HANA: Generischer Zustand, wenn dies die verfügbare Engine ist.
- Events bleibt am Ende der Domäne.
Engine-spezifische Blöcke erscheinen nur, wenn sie zutreffen. Enthält ein Abschnitt nur ein anwendbares Panel, nutzt es die gesamte verfügbare Breite.
Jedes Signal behält seine reale Kadenz: Database health wird alle 30 Minuten erfasst und bleibt 90 Minuten frisch; I/O, Hit Ratio, Page Life und Oldest Transaction verwenden 15/45 Minuten; Transaction Log und Log Backup 1/3 Stunden; File Free Percent/Space und Backup Age 24/72 Stunden. SPOT verbindet Punkte nur innerhalb dieses Horizonts und erfindet weder Nullen noch verlängert es einen stale Snapshot.
Ist das globale Fenster kürzer als diese Freshness, fragt Operations mindestens den eigenen Horizont jedes DB-Panels ab. Last 15 min kann zum Beispiel den letzten täglichen Snapshot anzeigen, solange er noch frisch ist, stets mit seiner tatsächlichen SAP-Zeit. Metrics Explorer behält den exakten Zeitraum, wenn Sie prüfen möchten, welche Beobachtungen strikt in diese 15 Minuten fallen.
Database health ist ein Zustandssignal und bietet weder Expected range noch Forecast oder ML scores. Numerische DB-Panels behalten Analysis, wenn ihre kanonische Richtlinie ML unterstützt.
Oracle-Identität
Die Oracle-Metrik database-health verwendet ausschließlich server=Oracle,
group=CCMS_ORA_health_check_run_pfcl, object=Database health check und
metric=Last succ. database check. Es hängt nicht von segment/monitor ab
und wird nie aus Latenz, Tablespaces oder Backups abgeleitet. Tablespaces,
Archive Backup, Full Backup und Optimizer Statistics verwenden eigene exakte
CCMS_ORA_*-Blätter und bleiben unabhängige Signale. Es ist das einzige
sichtbare Health-Panel. Dieser Check und die drei Protection-Zustände lesen
LASTALSTAT; fehlt der Wert oder ist er ungültig, lässt SPOT die Beobachtung
aus und verwendet nie LASTPERVAL als Ersatz. Tablespaces und alle anderen
Gauges behalten ihren numerischen LASTPERVAL-Wert.
SPOT klassifiziert die 48 beobachteten Oracle-Identitäten in elf sichtbare Familien:
- Health: exakter Database health;
- Protection: Archive Backup, Full Backup, Optimizer Statistics und Belegung des Archiver-Ziels;
- Performance: Buffer Cache, Library Cache und Redo Log Buffer;
- Capacity: Alter des exklusiven Locks, Segment-Prüfungen sowie genutzter/ freier Platz pro Tablespace;
- Consistency: inkonsistente, fehlende, optionale oder unbekannte Objekte im Dictionary.
Dynamische Tablespace-Namen werden nur akzeptiert, wenn Objekt und Gruppe exakt
übereinstimmen. Eine nicht erkannte Beobachtung erscheint nicht unter einer
anderen Familie. SPOT erfindet keine Thresholds und ändert keine Einheiten,
wenn die Quellsemantik nicht verifiziert ist. Die acht Raw-Oracle-Familien
zeigen den CCMS-Wert mit Einheit raw, trennen Serien nach object und check,
aggregieren Buckets mit max und bieten weder Thresholds noch ML. Die Werte
werden nicht als Prozent, Sekunden, MB, Count oder Zustand bezeichnet. Diese
Oracle-Erweiterung ändert weder MSSQL-Panels noch -Abfragen oder -Farben.
current zeigt die letzte exakte Beobachtung. Das normalisierte Signal
Database health bewahrt den real schlechtesten Zustand und bleibt ohne
echtes Health-Signal 90 Minuten lang stabil UNKNOWN. Die drei Zustände von
Oracle Protection werden alle 60 Minuten erfasst und bleiben 180 Minuten frisch;
fremde Raw-Gauges können keinen Wechsel von Health zu OK auslösen.
Interpretation
- OK: Das exakte Health-Signal meldet normalen Zustand.
- WARN: Dasselbe Signal meldet eine Warnung.
- KO: Dasselbe Signal meldet einen Fehler.
UNKNOWN: Innerhalb der signalabhängigen Freshness gibt es keine gültige Beobachtung; dies bedeutet nicht, dass der letzte historische Wert null war.
Filter und nächste Bildschirme
Kreuzen Sie Performance, Jobs und Metrics. Bei verbreitetem Impact prüfen Sie Events im gleichen Fenster.
Operative Nutzung
DB trennt Anwendungsdegradation von datenbankbedingter Degradation. Wenn DB request time zusammen mit Dialog response time steigt, öffnen Sie Performance und Metrics mit kurzem Fenster, um punktuellen oder dauerhaften Impact zu unterscheiden.
Konkrete Panels hängen vom verfügbaren DB-Motor ab. Wenn keine motorkonkreten Karten erscheinen, verwenden Sie generische Health- und Request-Time-Signale und suchen danach Events im selben Zeitbereich.