Capstone: vier Muster, fünf Fragen und die Reihenfolge unter Druck

Zwölf Module, aber nur vier Muster: die leise Voreinstellung, die Bestätigung, die weniger zusagt, die Einstellung ohne Gegenstück und die Maßnahme, die genau dann fehlt, wenn man sie ruft. Dieses Modul lehrt nichts Neues — es ordnet das Gelernte nach diesen Mustern und prüft, ob die Zuordnung unter Druck gelingt. Am Ende steht die Frage, die keine technische ist: Wer entscheidet, wenn jemand etwas verliert?

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-12

Vier Muster, die in jedem Modul wiederkehrten

Dieser Track hat zwölf Themen behandelt, von den Ebenen einer Instanz bis zum Versionswechsel. Wer sie nebeneinanderlegt, findet nicht zwölf unabhängige Wissensgebiete, sondern vier Muster, die in jedem einzelnen auftauchten. Sie sind der eigentliche Ertrag, weil sie auch auf Systeme übertragbar sind, die hier nicht vorkamen.

Die leise Voreinstellung. Das gefährlichere Verhalten ist oft das, das weiterläuft und Erfolg meldet.
Die Bestätigung, die weniger zusagt. Rückgabewerte und Erfolgsmeldungen bestätigen häufig einen Teilschritt, nicht das Ergebnis.
Die Einstellung ohne Gegenstück. Viele Zusagen bestehen aus zwei Einstellungen; eine allein wird angenommen und bewirkt nichts.
Die Maßnahme, die genau dann fehlt. Mehrere Rettungswege brauchen ausgerechnet die Ressource, deren Mangel sie beheben sollen.

Wozu dieses Modul dientEs lehrt nichts Neues. Es ordnet das Gelernte nach diesen vier Mustern und prüft, ob die Zuordnung unter Druck gelingt — also dann, wenn ein Dienst steht und mehrere Personen auf eine Entscheidung warten.

Muster 1: die leise Voreinstellung

An mehreren Stellen im Track stand die Wahl zwischen einem lauten Abbruch und einem leisen Weiterlaufen — und die Voreinstellung war nicht immer die sichere.

XACT_ABORT bei SQL Server: Voreingestellt OFF für T-SQL: Ein Laufzeitfehler rollt in manchen Fällen nur die fehlerhafte Anweisung zurück, die Transaktion läuft weiter und der COMMIT greift. PostgreSQL bricht dagegen den ganzen Block ab.
log_min_duration_statement: Voreingestellt -1, also aus. Langsame Abfragen hinterlassen ohne Zutun keine Spur.
log_lock_waits: Voreingestellt aus. Eine Sperrblockade von vorletzter Woche ist danach nicht rekonstruierbar.
lock_timeout: Voreingestellt 0, also unbegrenztes Warten. Eine Migration wartet damit still, statt zu scheitern.
idle_in_transaction_session_timeout: Voreingestellt aus. Eine abgerissene Verbindung hält ihre Sperren auf unbestimmte Zeit.

Die Frage, die dieses Muster erledigtWas tut das System, wenn niemand etwas einstellt — und ist das das gewünschte Verhalten? Bei vier der fünf Zeilen oben lautet die Antwort nein, sobald es um einen Produktionsbetrieb geht. Das ist keine Nachlässigkeit der Hersteller: Jede dieser Voreinstellungen ist für eine frische Installation ohne Last vernünftig. Sie passt nur nicht zu dem, wofür das System dann verwendet wird.

Muster 2: die Bestätigung, die weniger zusagt

Der zweite wiederkehrende Fall: Etwas meldet Erfolg, und die Meldung bezieht sich auf einen schmaleren Sachverhalt, als der Empfänger annimmt.

pg_terminate_backend liefert true: Bestätigt ohne Zeitgrenze nur den Versand des Signals, nicht dass der Prozess endet.
Der nächtliche Sicherungsauftrag meldet Erfolg: Bestätigt, dass die Sicherung lief — nicht, dass sich daraus etwas wiederherstellen lässt.
Das Archivkommando liefert null: Der Server nimmt daraufhin an, das Segment sei sicher abgelegt, und entfernt oder recycelt es. Eine fälschlich gemeldete Null löscht das Original.
Die Sitzungsübersicht zeigt ein DELETE: Zeigt bei idle die zuletzt gelaufene Abfrage, nicht eine laufende.
EXPLAIN ANALYZE heißt „Analyse“: Führt die Anweisung tatsächlich aus; nur die Ausgabe eines SELECT wird verworfen.

Die Frage, die dieses Muster erledigtWas genau sagt diese Bestätigung zu — und wie prüfe ich das Ergebnis unabhängig davon? In fast allen Fällen oben lautet die unabhängige Prüfung: hinsehen. In die Sitzungsliste, in den Wiederherstellungstest, in das Archivverzeichnis.

Muster 3: die Einstellung ohne Gegenstück

Der dritte Fall ist der heimtückischste, weil eine Konfigurationsprüfung ihn nicht findet: Eine Einstellung wird angenommen, ist syntaktisch richtig, und bewirkt ohne ihr Gegenstück nichts.

synchronous_commit = remote_apply: Ohne gefüllte Liste synchroner Sekundärknoten liefert es dieselbe rein lokale Stufe wie on. Keine Transaktion wartet auf einen zweiten Knoten.
archive_mode = on: Ohne funktionierendes Archivkommando füllt sich pg_wal/, bis das Dateisystem voll ist — und dann schaltet sich die Instanz ab.
READ UNCOMMITTED in PostgreSQL: Wird angenommen und verhält sich wie READ COMMITTED. Die Zeile im Code behauptet eine Absicht, die das System nicht umsetzt.
Synchroner Commit nur am Sekundärknoten: Ist der Primärknoten asynchron, bestätigt er für alle Sekundärknoten asynchron — unabhängig von deren Einstellung.
host statt hostssl: Erlaubt Verschlüsselung, verlangt sie nicht. Ein Client ohne kommt durch, und nichts schlägt fehl.

Die Frage, die dieses Muster erledigtWelche zweite Einstellung muss stimmen, damit diese hier wirkt — und ist die Zusage gemessen oder gelesen? Gelesen wird eine Konfiguration; gemessen wird eine Zusage. Bei allen fünf Zeilen oben gibt es einen Test, der Sekunden dauert und die Frage beantwortet.

Muster 4: die Maßnahme, die genau dann fehlt

Das vierte Muster ist das unbequemste, weil es sich nicht durch bessere Konfiguration lösen lässt, sondern nur durch Vorsorge.

VACUUM FULL gegen volle Platten: Braucht zusätzlich Platz etwa in Größe der Tabelle — also genau dann nicht verfügbar, wenn man ihn ruft.
Eine Sitzung beenden, um eine Blockade zu lösen: Das Zurücknehmen dauert so lange wie die bisherige Arbeit, und die Sperren bleiben währenddessen. Der Eingriff kann die Blockade verlängern.
Die Sicherung nach einem Verschlüsselungsvorfall: Ohne gesichertes Zertifikat lässt sich die Datenbank auf einer neuen Maschine nicht öffnen.
Die physische Sicherung beim Hauptversionswechsel: Taugt nicht als Rückweg auf die neue Version — sie ist an das alte Format gebunden.
Statistiken und Vergleichswerte nach einem Vorfall: Nach Start aus einer Grundsicherung oder nach Point-in-Time-Recovery sind alle Zähler zurückgesetzt. Die Vergleichsgrundlage fehlt genau dann, wenn man sie braucht.

Die Frage, die dieses Muster erledigtSetzt diese Maßnahme etwas voraus, das im Ernstfall knapp ist? Wenn ja, gehört die Voraussetzung vorher beschafft — Platzreserve, gesicherter Schlüssel, ein zweiter Weg auf die alte Version. Das ist der Unterschied zwischen einem Plan und einer Hoffnung.

Jede richtige Wahl hatte einen Preis

Ein Muster durchzieht diesen Track, das keines der vier oben ist, weil es keine Fehlerquelle beschreibt, sondern eine Haltung: Jede empfohlene Vorgehensweise hatte einen benannten Nachteil. Das war kein Beiwerk — wer nur den Gewinn nennt, schreibt Werbung, und Werbung trägt keine Entscheidung.

Sperr-Zeitgrenze in der Migration: + Aus einem stillen Ausfall wird ein sichtbarer Fehlschlag. − Die Auslieferung schlägt öfter fehl und kann auf einer belebten Instanz mehrfach hintereinander scheitern.
Rollentrennung für Anwendung, Auslieferung und Sicherung: + Ein Fehler unter einer Rolle kann die anderen Bereiche nicht beschädigen. − Drei Identitäten sind drei Geheimnisse, drei Ablaufdaten und drei vergessbare Rotationen.
Erweitern, umstellen, zusammenziehen: + Kein Stillstand, und bis zum letzten Schritt ist alles zurücknehmbar. − Mehrere Releases lang trägt das Schema beides, und der letzte Schritt bleibt gern liegen, weil er nichts Sichtbares bringt.
Wiederherstellungstest auf getrennter Instanz: + Verwandelt eine Vermutung in eine geprüfte Zusage und findet die Umfangslücken. − Kostet eine zweite Instanz, Rechenzeit und einen Menschen mit Fachkenntnis — wiederkehrend.
Synchrone Replikation wirklich einschalten: + Die zugesagte Verlustgrenze gilt tatsächlich. − Jeder Commit wartet auf den zweiten Knoten, und dessen Ausfall blockiert die Schreibseite.
Clientseitige Verschlüsselung: + Die einzige Variante, die auch den Serveradministrator ausschließt. − Was der Server nie im Klartext sieht, kann er nicht durchsuchen, sortieren oder indizieren.

Warum das im Gespräch mit der Fachseite zähltWer eine Maßnahme nur mit ihrem Gewinn vorträgt, bekommt entweder ein schnelles Ja und später den Vorwurf, die Folgen verschwiegen zu haben — oder ein Nein, weil die Gegenseite die Kosten ahnt und dem Vortrag nicht traut. Beide Seiten zu nennen kostet im Moment Zustimmung und gewinnt Glaubwürdigkeit, die beim nächsten Mal trägt.

Daraus folgt die Form, in der eine Empfehlung aus diesem Track vorgetragen gehört: Maßnahme, Gewinn, Preis, und wer den Preis trägt. Der letzte Teil ist der, der am häufigsten fehlt — und er entscheidet darüber, ob die Entscheidung an der richtigen Stelle fällt.

Die Reihenfolge, die alle zwölf Module teilen

Jedes Modul dieses Tracks endete mit einer Abfolge, und alle sahen einander ähnlich. Zusammengefasst ergibt sich eine Reihenfolge, die unter Druck trägt.

Wirkung bestätigen — gibt es überhaupt einen Vorfall?→Ebene und Art bestimmen, bevor ein Werkzeug gewählt wird→Beobachten und Beweise sichern, bevor eingegriffen wird→Den engsten wirksamen Eingriff wählen→Wirkung unabhängig von der Rückmeldung prüfen

Beobachtung vor Eingriff

Der zweite Schritt ist der, der die meisten Fehlgriffe verhindert, und er heißt in jedem Modul anders: Volume gegen Datenbank gegen Tabelle. Blockierung gegen allgemeine Langsamkeit. Aufblähung gegen echtes Wachstum. Anmeldung gegen Berechtigung. Leser, die auf Schreiber warten, gegen Schreiber, die aufeinander warten. Es ist immer dieselbe Bewegung: erst einordnen, dann handeln.

Und der Preis dieser Reihenfolge, ehrlich benanntSie kostet Minuten, und zwar die teuersten — die, in denen der Dienst steht und jemand danebensteht. Sie sieht nach Zögern aus. Sie ist trotzdem richtig, weil der falsche Eingriff bei Daten nicht nur wirkungslos ist, sondern die Lage verschlechtert: durch ein Zurücknehmen, das länger dauert als das Problem, durch eine unbeteiligte beendete Sitzung, oder durch eine Maßnahme, die die letzte freie Ressource verbraucht.

Ein Vorfall, durchgespielt

Freitag, 16:40 Uhr: „Die Anwendung ist langsam“

Szenario

Eine Fachanwendung reagiert träge. Vor zwei Stunden lief eine Auslieferung mit einer Schemaänderung. Die Überwachung zeigt erhöhte Wartezeiten, die CPU ist niedrig. Der Bereitschaftskollege will die längste Sitzung beenden.

Anforderungen

Lesezugriff auf die Statistik- und Sperrsichten
Die Auslieferung ist dokumentiert, ihr Inhalt bekannt
Noch kein Eingriff erfolgt

Schritte

Wirkung bestätigen. Wer ist betroffen — alle Masken oder eine? Ohne betroffenen Anwender ist die erhöhte Wartezeit ein Messwert, kein Vorfall.
Art bestimmen. Niedrige CPU bei hohen Wartezeiten spricht gegen Ressourcenknappheit. Zeigt der Wartetyp auf eine Sperre, gibt es einen Verursacher; zeigt er auf Speicher, gibt es keinen, den man beenden könnte.
Zeitfenster mit der Änderung abgleichen. Die Auslieferung vor zwei Stunden ist die naheliegendste Hypothese — aber eine Hypothese, kein Befund. Ein neuer Index kann Schreibvorgänge verteuert haben; eine Migration kann ihre Sperre noch halten.
Verursacher bestimmen, nicht die Wartenden. Gesucht ist die Sitzung, auf die gewartet wird und die selbst nicht wartet — und ihr Zustand entscheidet: active arbeitet, idle in transaction hält nur.
Beweise sichern. Sitzungsliste, Wartebeziehungen, Abfragetext. Nach dem Eingriff ist die Zeile weg und die Montags-Analyse findet nichts.
Engsten Eingriff wählen. Abbrechen vor Beenden. Und danach in der Sitzungsliste nachsehen, ob es gewirkt hat — der Rückgabewert sagt es nicht.

Merksatz: Sechs Schritte, von denen fünf nichts verändern. Genau deshalb ist der sechste zu verantworten.

Was an diesem Beispiel typisch istDie wahrscheinlichste Ursache — die Auslieferung — steht schon nach Schritt drei fest. Trotzdem folgen noch drei Schritte, bevor jemand eingreift. Das ist kein Formalismus: Die Hypothese sagt, wo man sucht; sie sagt nicht, was man beendet.

Wo die eigene Zuständigkeit endet

Dieser Track richtet sich an Leute, die Server betreiben und die Datenbank mitbekommen haben. Aus zwölf Modulen ergibt sich eine ziemlich klare Linie, wo die eigene Entscheidung endet — und sie verläuft nicht dort, wo man sie vermutet.

Technische Entscheidung: Welche Sicht beantwortet die Frage. Welcher Eingriff ist der engste. Welche Betriebsart eines Werkzeugs lässt den Rückweg offen. Ob eine Maßnahme eine knappe Ressource voraussetzt.
Fachliche Entscheidung: Welche Wiederherstellungszusage gilt. Ob eine laufende Stunde Arbeit verworfen wird. Welcher von zwei auseinandergelaufenen Beständen gültig ist. Wie lange Sicherungen aufbewahrt werden.

Die rechte Spalte enthält keine technisch schwierigen Fragen. Sie enthält die, bei denen ein Mensch etwas verliert — Arbeit, Geld, einen Anspruch. Solche Entscheidungen im Betrieb zu treffen ist bequem und schnell, und es ist die häufigste Art, wie aus einem technischen Vorfall ein organisatorischer wird.

Der nützlichste Satz für die Bereitschaft„Ich kann beides, und hier ist der Preis: A kostet uns die letzte Stunde Buchungen, B kostet uns zwei weitere Stunden Stillstand. Wer entscheidet?“ — Diese Formulierung verlagert nichts ab, sondern legt die Wahl dorthin, wo sie hingehört, und macht den Betrieb zum Anwalt beider Optionen statt zum heimlichen Entscheider einer.

Was dieser Track nicht beantwortet

Zum Schluss die ehrliche Abgrenzung. Zwölf Module sind eine Grundlage, kein Berufsbild — und mehrere benachbarte Gebiete wurden bewusst nur gestreift.

Abfragen entwerfen und Datenmodelle bauen. Der Track liest Ausführungspläne, aber er schreibt kein SQL für Fachanforderungen und entwirft keine Schemata.
Der Dienstwiederanlauf nach einem Totalausfall. Reihenfolge über mehrere Dienste, Priorisierung unter Knappheit und die Führung der Lage stehen im Track backup-disaster-recovery, der auf dieses Modul ausdrücklich verweist.
Alarmentwurf, Bereitschaft und Vorfallskoordination als Handwerk. Das steht in monitoring-incident-operations; hier ging es um die Instrumente der Datenbank selbst.
Change-Verfahren, Freigaben und Risikosteuerung als Prozess. Das steht in itsm-operations. Dieser Track liefert, was die Datenbank dabei technisch tut.
Die rechtliche Bewertung von Aufbewahrung und Löschung. Der Track benennt den technischen Sachverhalt und die Entscheidungspunkte — mehr wäre unredlich.

Und eine Kennzeichnung, die zum Schluss gehörtDieser Track behandelt PostgreSQL und SQL Server, weil sie im deutschsprachigen Serverbetrieb am häufigsten anzutreffen sind. Die Muster oben gelten darüber hinaus — leise Voreinstellungen, zu schmale Bestätigungen, Einstellungen ohne Gegenstück und Maßnahmen mit knapper Voraussetzung gibt es in jedem Datenbanksystem. Die konkreten Werte gelten es nicht. Wer ein drittes System betreibt, nimmt die Fragen mit und schlägt die Antworten dort nach.

Der erste Tag an einem fremden Bestand

Der wahrscheinlichste Fall nach diesem Track ist nicht, dass jemand eine Datenbank neu aufsetzt — sondern dass er eine übernimmt, die seit Jahren läuft und die niemand mehr vollständig kennt. Die vier Muster liefern dafür eine Bestandsaufnahme, die an einem Vormittag machbar ist.

Welche Zusage gilt — und seit wann wurde sie belegt?→Was ist eingeschaltet, was läuft auf Voreinstellung?→Welche Einstellung hat ihr Gegenstück nicht?→Welche Rettungsmaßnahme setzt eine knappe Ressource voraus?

Vier Fragen, ein Vormittag

Die Zusage zuerst. Wann wurde zuletzt eine Wiederherstellung auf getrennter Instanz belegt? Gibt es niemanden, der das beantworten kann, ist das der wichtigste Befund des Tages — wichtiger als jede Einstellung.
Dann die Voreinstellungen. Stehen Protokollierung langsamer Abfragen, Sperrwartezeiten und die Zeitgrenzen für Sperren und untätige Transaktionen auf ihren Voreinstellungen? Jede davon ist eine Diagnosemöglichkeit, die im nächsten Vorfall fehlt.
Dann die Paare. Läuft die Archivierung wirklich, oder ist nur der Schalter gesetzt? Wird Verschlüsselung auf der Leitung verlangt oder nur erlaubt? Wartet wirklich eine Transaktion auf einen zweiten Knoten? Jede dieser Fragen ist in Minuten zu messen und in keiner Konfigurationsdatei zu lesen.
Zuletzt die Reserven. Gibt es Platz für eine Verdichtung, falls sie nötig wird? Liegt das Verschlüsselungszertifikat getrennt gesichert? Existiert ein zweiter Weg auf die alte Version? Diese Fragen kosten nichts und beantworten sich am Ernstfall sonst von selbst — mit nein.

Was bewusst nicht auf der Liste stehtKennzahlen. Ein Überwachungsbild mit grünen Balken sagt nichts über die vier Fragen oben — es zeigt, dass die Instanz läuft, und das war nie die Frage. Die Bestandsaufnahme fragt nach Zusagen, Voreinstellungen, Paaren und Reserven; alles vier ist unsichtbar, solange nichts passiert.

Die letzte Zusammenfassung

Was tut das System, wenn niemand etwas einstellt?→Was genau sagt diese Bestätigung zu?→Welche zweite Einstellung muss dafür stimmen?→Setzt diese Maßnahme etwas voraus, das im Ernstfall knapp ist?→Und wer entscheidet, wenn jemand etwas verliert?

Fünf Fragen statt zwölf Themen

Wer diese fünf Fragen stellt, kommt bei den meisten Themen dieses Tracks auf die richtige Spur, auch ohne die Einzelheiten auswendig zu wissen. Die Einzelheiten stehen in der Referenz — und nachzuschlagen ist keine Schwäche, sondern die Arbeitsweise, die dieser Track durchgehend vertreten hat: Jeder Befund hier stammt aus der Dokumentation, nicht aus der Erinnerung.

Die Checks in diesem ModulSie prüfen keine neuen Tatsachen. Sie verbinden Befunde aus verschiedenen Modulen und fragen, welche Entscheidung daraus folgt — einschließlich der Fälle, in denen die richtige Entscheidung lautet, sie nicht allein zu treffen.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität16 Primärquellen · zuletzt geprüft: 2026-09-12