# Vom Alarm zur Hypothese
Typ: Checkliste
Herkunft: database-administration-basics / monitoring-basics / database-monitoring-signal-sequence
Version: database-monitoring-signal-sequence-2026-09-12
Geprüft: 2026-09-12

ACHTUNG: Dieses Dokument ist ein Lernartefakt aus einer Schulungssequenz. Es ist kein produktives Runbook. Vor jeder Anwendung in einer realen Umgebung müssen die Schritte gegen lokale Dokumentation, Runbooks und Freigabestatus geprüft werden.

## Szenario
Um 09:40 Uhr meldet die Überwachung eine ungewöhnlich hohe Wartezeit auf einer Datenbankinstanz. Gleichzeitig gehen zwei Tickets über langsame Masken ein. Die Instanz läuft, nichts ist ausgefallen.

## Schritte
1. Bestätigen, welche Anwendung und welche Anwender tatsächlich betroffen sind
2. Das Zeitfenster eingrenzen und den Bezugszeitraum der aufgelaufenen Zähler mitlesen
3. Eine Momentaufnahme der Sitzungen nehmen und auf Wartetyp und Zustand achten
4. Prüfen, ob die Wartevorgänge auf eine Sperre und damit auf eine andere Sitzung zeigen
5. Eine Hypothese formulieren, die Befund und Nutzerwirkung verbindet
6. Die Hypothese gegen eine zweite Quelle prüfen, etwa das Serverprotokoll

## Begründung
Warum: Die Wirkung kommt vor der Kennzahl, weil sie entscheidet, ob überhaupt ein Vorfall vorliegt und welcher Ausschnitt zählt. Eine Hypothese, die nur Messwerte verbindet und keine beobachtete Wirkung, lässt sich weder widerlegen noch priorisieren.
Folgen: **+** Das Vorgehen trennt Messwert von Vorfall und liefert am Ende eine Aussage, die sich prüfen lässt. **−** Es kostet die ersten Minuten mit Fragen statt mit Eingriffen — unter Druck fühlt sich das nach Untätigkeit an, und wer die Wirkung schon kennt, darf die erste Stufe abkürzen.

## Quellen
1. https://www.postgresql.org/docs/current/monitoring-stats.html
2. https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-exec-requests-transact-sql