# Freitagnachmittag
Typ: Checkliste
Herkunft: database-administration-basics / database-expert-capstone / database-capstone-incident-sequence
Version: database-capstone-incident-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
Eine Fachanwendung reagiert träge. Vor zwei Stunden lief eine Auslieferung mit einer Schemaänderung. Die Wartezeiten sind erhöht, die CPU ist niedrig. Mehrere Personen schauen zu, und es ist 16:40 Uhr.

## Schritte
1. Bestätigen, welche Anwendung und welche Anwender betroffen sind
2. Wartetyp ansehen: zeigt er auf eine Sperre oder auf eine Ressource?
3. Das Zeitfenster mit der Auslieferung von vor zwei Stunden abgleichen
4. Den Verursacher bestimmen: die Sitzung, auf die gewartet wird und die selbst nicht wartet
5. Sitzungsliste, Wartebeziehungen und Abfragetext sichern
6. Den engsten wirksamen Eingriff wählen — abbrechen vor beenden
7. In der Sitzungsübersicht nachsehen, ob die Wirkung eingetreten ist

## Begründung
Warum: Die wahrscheinlichste Ursache steht oft schon nach drei Schritten fest — und sagt trotzdem nur, **wo** man sucht, nicht **was** man beendet. Die Schritte dazwischen sind kein Formalismus, sondern der Unterschied zwischen einem begründeten und einem geratenen Eingriff.
Folgen: **+** Am Ende steht ein gezielter Eingriff mit belegter Wirkung und eine Spur, die am Montag noch auswertbar ist. **−** Fünf der sieben Schritte verändern nichts, und das sieht für Zuschauende am Freitagnachmittag nach Zögern aus — das auszuhalten ist der eigentliche Preis.

## Quellen
1. https://www.postgresql.org/docs/current/monitoring-stats.html
2. https://www.postgresql.org/docs/current/functions-admin.html
3. https://www.postgresql.org/docs/current/explicit-locking.html