Datenbank im Status Suspect

Die rote Karte. Die Recovery-Pyramide vom Goldstandard (Restore + Tail-Log) bis zur Notlandung (REPAIR_ALLOW_DATA_LOSS) — und was du unter keinen Umständen tun darfst.

Es ist Dienstagmorgen, 06:42 Uhr, bei der Musterwerk GmbH. Die Nachtschicht hat sauber zu Ende gearbeitet, der Server wurde nach einem kurzen Stromausfall im Rechenzentrum neu gestartet — und jetzt, bevor die Frühschicht kommt, steht neben der zentralen Produktionsdatenbank das schlimmste Wort, das ein DBA dort lesen kann: (Suspect). Nicht „Recovery Pending“, nicht „Restoring“ — Suspect. Die rote Karte. Der Server hat versucht, die Datenbank hochzufahren, ist dabei auf einen schweren Fehler gestoßen und hat sie als verdächtig offline genommen. Und während sich Panik breitmacht und eine innere Stimme schon nach dem einen mächtigen Reparatur-Befehl ruft, von dem man mal gehört hat, ist das Wichtigste in diesem Moment: nichts überstürzen. Die Datenbank ist offline — sie wird nicht schlimmer, solange du nicht falsch handelst.

Willkommen beim ernstesten Notfall des SQL-Server-Notarztwagens (die Triage-Übersicht liegt unter /sql-server-notarztwagen/) — und dem letzten der fünfundzwanzig Beiträge. Suspect bedeutet echte Korruption, und genau deshalb entscheidet hier die Reihenfolge über alles: über Datenverlust oder Rettung, über Stunden oder Tage. Dieser Beitrag zeigt dir die Recovery-Pyramide vom Goldstandard (Restore plus Tail-Log) bis zur Notlandung — und vor allem den einen Befehl, der so verlockend wie gefährlich ist und den man niemals als Erstes anfasst. Es ist der Beitrag, den man hofft, nie zu brauchen — und den man froh ist zu kennen, wenn der Ernstfall doch eintritt.

Was „Suspect“ technisch bedeutet

Um die rote Karte zu verstehen, muss man wissen, was beim Hochfahren passiert. Jede Datenbank durchläuft beim Start die Recovery: Der Server wertet das Transaktionslog aus, zieht abgeschlossene Transaktionen nach und rollt unvollständige zurück, um einen konsistenten Zustand herzustellen. Der Status SUSPECT bedeutet, dass der Server diese Recovery begonnen — und dann an einem schwerwiegenden Fehler abgebrochen hat. Er ist auf etwas gestoßen, das er nicht sauber verarbeiten konnte: eine beschädigte Datenseite, ein korruptes Log, eine inhaltliche Inkonsistenz. Daraufhin nimmt er die Datenbank offline und markiert sie als verdächtig, um zu verhindern, dass mit beschädigten Daten weitergearbeitet wird.

Das ist der fundamentale Unterschied zum verwandten Status RECOVERY_PENDING, und ihn zu kennen entscheidet über die richtige Behandlung. Bei Recovery Pending konnte die Recovery nicht beginnen — meist ein harmloses Zugriffsproblem, bei dem die Daten intakt sind. Bei Suspect dagegen ist die Recovery begonnen und gescheitert — hier ist wirklich etwas beschädigt. Komme-nicht-ran gegen ist-kaputt. Wer einen Suspect-Fall wie ein Zugriffsproblem behandelt, wundert sich, warum SET ONLINE nicht hilft; wer umgekehrt ein Recovery Pending mit Korruptions-Werkzeugen angeht, zerstört intakte Daten. Bei Suspect ist tatsächlich etwas kaputt — und genau deshalb braucht es die strukturierte Recovery-Pyramide statt eines einzelnen Befehls.

Die Ursache der Korruption liegt fast immer unter dem SQL Server, im Storage-Subsystem: ein Controller mit defektem Cache, eine Platte mit schleichendem Fehler, ein Treiber-Bug, ein Stromausfall im falschen Moment — wie im Lead-Beispiel. Der typische Begleiter im Protokoll ist Fehler 824 (eine logische Konsistenzprüfung beim Seitenlesen schlug fehl) oder seine Verwandten 823 und 825. Diese Fehler sind nicht nur ein Datenbank-Problem, sondern ein Fingerzeig auf die Hardware: Ohne behobene Storage-Ursache kehrt die Korruption zurück, und keine Reparatur der Welt hält dauerhaft, wenn darunter weiter Bits umkippen.

Die Recovery-Pyramide

Bei Suspect arbeitest du die Pyramide immer von oben nach unten ab — jede Stufe tiefer bedeutet mehr Datenverlust, und die unterste ist der letzte Ausweg. Die folgende Skizze zeigt die vier Stufen, die Sofortmaßnahmen und die Dinge, die du niemals tun darfst:

Die Skripte: sichern, diagnostizieren, retten

Schritt 1 — Sofort: das Tail-Log sichern

Bevor du irgendetwas anderes tust, sichere das Log — es ist die Grundlage für eine Wiederherstellung ohne Datenverlust. Bei einer beschädigten Datenbank brauchst du dafür NO_TRUNCATE:

Gelingt das Tail-Log-Backup, hast du die jüngsten Transaktionen gesichert und damit die Voraussetzung für Stufe eins der Pyramide geschaffen. Erst danach geht es weiter — niemals umgekehrt.

Schritt 2 — Der Goldstandard: Restore aus Backup

Die erste und beste Stufe: aus einem sauberen Backup wiederherstellen, abgeschlossen mit dem eben gesicherten Tail-Log — das ist die Rettung ohne Datenverlust:

Schritt 3 — Kein Backup? Diagnose im EMERGENCY-Modus

Nur wenn kein brauchbares Backup existiert, gehst du tiefer. Im EMERGENCY-Modus wird die Datenbank lesbar, und CHECKDB nennt den Schaden:

Beachte die Reihenfolge im Skript: EMERGENCY und CHECKDB dienen erst der Diagnose und dem Herauskopieren noch lesbarer Daten. REPAIR_ALLOW_DATA_LOSS steht bewusst auskommentiert und ganz unten — es ist die Notlandung, nicht der nächste Schritt.

Die vier Stufen der Recovery-Pyramide

Jede Stufe hat ihren Platz — und die goldene Regel lautet: immer oben anfangen, nur so tief gehen wie nötig:

Stufe 1 — Restore aus Backup (der Goldstandard)

Aus einem sauberen Backup wiederherstellen, abgeschlossen mit dem Tail-Log-Backup. Das ist die Rettung ohne Datenverlust und immer der erste Weg, sofern Backups existieren. Genau hier zahlt sich eine getestete Backup-Strategie aus — sie verwandelt den Suspect-Notfall von einer Katastrophe in einen geordneten Restore.

Stufe 2 — CHECKDB mit REPAIR_REBUILD

Wenn kein Backup hilft, prüft CHECKDB den Schaden. Bietet es REPAIR_REBUILD als minimale Stufe an, ist eine Reparatur ohne Datenverlust möglich — etwa bei einem beschädigten Nonclustered-Index, der sich neu aufbauen lässt, weil seine Daten anderswo vollständig vorliegen. Die harmlose Reparatur.

Stufe 3 — EMERGENCY-Modus: Daten retten

Reicht REPAIR_REBUILD nicht, ist der EMERGENCY-Modus das Rettungsboot vor der Reparatur: Solange die Datenbank lesbar ist, kopierst du so viele Daten wie möglich in eine neue, gesunde Datenbank heraus. Dieser Schritt rettet oft mehr Daten als die Reparatur selbst — er gehört vor jede verlustbehaftete Maßnahme.

Stufe 4 — REPAIR_ALLOW_DATA_LOSS (die Notlandung)

Der letzte Ausweg, wenn alles andere ausgeschöpft ist. REPAIR_ALLOW_DATA_LOSS stellt die Konsistenz wieder her, indem es beschädigte Daten verwirft — der Name ist die Warnung. Danach gehört zwingend ein erneutes CHECKDB gefahren und die Storage-Ursache geklärt. Diese Stufe ist die Notlandung mit Schaden, nicht der Standard — und niemals der erste Griff.

Was du auf keinen Fall tun solltest

Nachsorge: damit es nicht wiederkommt

Ist die Datenbank gerettet, ist die Arbeit nicht vorbei — Suspect ist ein Symptom, und ohne behobene Ursache kehrt es zurück. Drei Schritte für die Nachsorge: Erstens, der Storage-Ursache nachgehen: Controller-Logs, RAID-Status, Plattengesundheit, Treiber- und Firmware-Stände prüfen — eine korruptierende Maschine ist ein lautes Warnsignal aus der Hardware. Zweitens, Page Verify auf CHECKSUM und regelmäßige CHECKDB-Läufe sicherstellen, damit die nächste Korruption früh auffällt, solange sie noch klein und reparierbar ist — die Konsistenz-Strategie hat dafür einen eigenen Beitrag. Drittens, und das ist die wichtigste Lehre jedes Suspect-Falls: die Backup-Strategie prüfen und testen. Ein Suspect mit sauberem, getestetem Backup ist ein geordneter Restore; ein Suspect ohne Backup ist eine Katastrophe. Genau hier schließt sich der Bogen zur ganzen GRÜN-Stufe des Notarztwagens — zur Vorsorge, die den Notfall entschärft, bevor er eintritt.

Vertiefung in der Buchreihe

Korruptions-Recovery, die Recovery-Pyramide und die Konsistenz-Strategie füllen in der Buchreihe „SQL Server in der Praxis“ eigene Kapitel — alle Bände in der Übersicht auf der SQL-Pillar-Seite unter /sql-server/.

Verwandte Notfälle im Notarztwagen

Suspect ist der Schlussstein der Recovery-Themen — diese Beiträge sind die nächste Station:

Drei Wege, wenn die Datenbank jetzt Suspect zeigt

Akut-Hotline

Wenn die Datenbank in diesem Moment im Status Suspect steht: anrufen — und bis dahin nichts Überstürztes tun, vor allem keinen Reparatur-Befehl. Halte bereit, ob ein Tail-Log-Backup noch möglich ist und welche Backups vorliegen. Das sind die zwei Informationen, die über den Weg entscheiden: Mit sauberem Backup ist es ein geordneter Restore ohne Datenverlust, ohne Backup beginnt die sorgfältige Rettung über den EMERGENCY-Modus. In genau dieser Lage ist die richtige Reihenfolge alles wert — und der häufigste, teuerste Fehler ist der voreilige Griff zu REPAIR_ALLOW_DATA_LOSS.

Festpreis-Analyse

Wenn du nach einem überstandenen Suspect-Fall sicherstellen willst, dass er sich nicht wiederholt — oder vorbeugen, bevor es überhaupt so weit kommt? Die Festpreis-Analyse liefert beides: Ich prüfe die Storage-Gesundheit und die Korruptions-Vorsorge (Page Verify, CHECKDB-Routine), bewerte die Backup-Strategie auf ihre Tauglichkeit für den Ernstfall mit einem echten Restore-Test und liefere einen Bericht mit priorisierten Maßnahmen. Zum vereinbarten Festpreis, ohne Stundenzähler.

Selbst-Diagnose-Kit

Für alle, die für den Ernstfall gerüstet sein wollen: Das Diagnose-Kit bündelt die Skripte aus diesem Beitrag — das Tail-Log-Backup mit NO_TRUNCATE, die Restore-Sequenz, die EMERGENCY-Diagnose mit CHECKDB — plus die Recovery-Pyramide zum Ausdrucken und eine Notfall-Checkliste, die die richtige Reihenfolge festhält. Damit hast du, wenn die rote Karte erscheint, einen klaren Plan statt Panik — und greifst nicht zum gefährlichen Befehl, der Daten wegwirft.

Häufige Fragen (FAQ)

Diese Sektion ist auf häufige Suchanfragen abgestimmt. Sie hilft dir, schnell den Punkt zu finden, der dir gerade akut weiterhilft — und sie ist gleichzeitig die Eingabe für das FAQPage-Schema auf der Seite.

Was bedeutet SQL Server Suspect?

Der Status Suspect bedeutet, dass der SQL Server die Datenbank beim Hochfahren wiederherstellen wollte, die Recovery aber begonnen und dann an einem schwerwiegenden Fehler abgebrochen hat — typischerweise an einer inhaltlichen Korruption der Daten oder des Transaktionslogs. Anders als bei Recovery Pending (wo die Recovery gar nicht erst starten konnte, meist wegen eines Zugriffsproblems) ist hier wirklich etwas beschädigt. Die Datenbank wird offline genommen und als verdächtig markiert, um weiteren Schaden zu verhindern. Suspect ist die rote Karte unter den Datenbank-Status: ernst, aber mit der richtigen Reihenfolge fast immer ohne oder mit minimalem Datenverlust lösbar — sofern saubere Backups existieren. Der Restore aus dem Backup ist immer der erste Weg, nicht die Reparatur.

Wie rette ich eine Suspect-Datenbank?

Über die Recovery-Pyramide, immer von oben nach unten. Stufe eins und der Goldstandard: aus einem sauberen Backup wiederherstellen, idealerweise ergänzt um ein Tail-Log-Backup für die jüngsten Transaktionen — das ist die Rettung ohne Datenverlust. Stufe zwei: Wenn kein brauchbares Backup existiert, prüft DBCC CHECKDB den Schaden; bietet es REPAIR_REBUILD an, ist eine Reparatur ohne Datenverlust möglich. Stufe drei: Im EMERGENCY-Modus lassen sich noch lesbare Daten herauskopieren und retten. Erst Stufe vier, die Notlandung, ist REPAIR_ALLOW_DATA_LOSS — die Reparatur, die beschädigte Daten verwirft. Wer von unten beginnt, wirft Daten weg, die ein Restore verlustfrei gerettet hätte. Reihenfolge ist hier alles.

Was ist der Unterschied zwischen REPAIR_REBUILD und REPAIR_ALLOW_DATA_LOSS?

REPAIR_REBUILD behebt Schäden, die sich ohne Datenverlust reparieren lassen — etwa einen beschädigten Nonclustered-Index, der einfach neu aufgebaut werden kann, weil seine Daten anderswo vollständig vorhanden sind. Es ist die harmlose Reparatur. REPAIR_ALLOW_DATA_LOSS dagegen stellt die Konsistenz der Datenbank wieder her, indem es beschädigte Seiten verwirft — der Name ist eine wörtliche Warnung: Daten gehen verloren. Es ist die Notlandung, wenn kein Backup mehr hilft und die Konsistenz um jeden Preis wiederhergestellt werden muss. DBCC CHECKDB nennt selbst die minimal nötige Reparaturstufe; diese Angabe ist aber eine Information über die Schwere des Schadens, keine Handlungsanweisung — auch wenn dort REPAIR_ALLOW_DATA_LOSS steht, bleibt der Restore der erste Weg.

Wie führe ich DBCC CHECKDB sicher aus?

Bei einer Suspect-Datenbank musst du sie zunächst in den EMERGENCY-Modus versetzen, weil CHECKDB sonst nicht auf die offline genommene Datenbank zugreifen kann: ALTER DATABASE [DB] SET EMERGENCY, dann SET SINGLE_USER, dann DBCC CHECKDB. Lies das Ergebnis genau: Es nennt die Zahl der Konsistenzfehler, die betroffenen Objekte und die minimal nötige Reparaturstufe. Diese Ausgabe ist deine Entscheidungsgrundlage — sie sagt dir, wie schwer der Schaden ist und ob eine verlustfreie Reparatur (REPAIR_REBUILD) überhaupt möglich wäre. Wichtig: CHECKDB auszuführen heißt nicht, sofort zu reparieren. Erst diagnostizieren, das Ergebnis verstehen, und dann die Recovery-Pyramide von oben durchgehen — Restore vor jeder Reparatur.

Was bedeutet SQL Server Error 824?

Fehler 824 ist eine der wichtigsten Korruptionsmeldungen des SQL Servers: Er besagt, dass eine logische Konsistenzprüfung beim Lesen einer Datenseite fehlgeschlagen ist — die Seite ist beschädigt. Er gehört zur Familie 823 (ein Betriebssystem-Fehler beim Datei-Zugriff), 824 (logischer Konsistenzfehler trotz erfolgreichem Lesen) und 825 (ein Lesevorgang gelang erst nach Wiederholungen — ein Frühwarnzeichen). Tritt 824 auf, ist fast immer das Storage-Subsystem darunter die eigentliche Ursache: ein Controller, eine Platte, ein Treiber, der Bits umkippen lässt. Der Fehler ist deshalb nicht nur ein Datenbank-Thema, sondern ein Hinweis, die Hardware zu untersuchen — sonst kehrt die Korruption zurück. Page Verify mit CHECKSUM macht solche Fehler frühzeitig sichtbar.

Wie mache ich ein Tail-Log-Backup?

Ein Tail-Log-Backup sichert die jüngsten, noch nicht gesicherten Transaktionen aus dem Log — es ist der Schlüssel, um bei einer Suspect-Datenbank den Datenverlust auf nahezu null zu drücken. Bei einer beschädigten Datenbank nutzt du dafür die Optionen WITH NO_TRUNCATE (und gegebenenfalls CONTINUE_AFTER_ERROR), die das Sichern des Logs auch dann erlauben, wenn die Datenbank nicht im Normalzustand ist: BACKUP LOG [DB] TO DISK = '…' WITH NO_TRUNCATE. Voraussetzung ist, dass das Log noch zugänglich und intakt ist — ein wichtiger Grund, Daten- und Logdateien physisch zu trennen. Das Tail-Log-Backup ist der allererste Handgriff, bevor du irgendetwas anderes versuchst, denn es ist die Grundlage für eine Wiederherstellung ohne Datenverlust.

Was tun, wenn keine Backups vorhanden sind?

Dann beginnt der schwierige Teil der Recovery-Pyramide — und die unbequeme Lehre, dass ein fehlendes Backup im Ernstfall durch nichts zu ersetzen ist. Ohne Backup gehst du die unteren Stufen: Über den EMERGENCY-Modus versuchst du zunächst, möglichst viele noch lesbare Daten herauszukopieren und in eine neue, gesunde Datenbank zu retten — das ist oft der Weg, der die meisten Daten erhält. Erst wenn auch das ausgeschöpft ist, bleibt als letzte Option REPAIR_ALLOW_DATA_LOSS, das die Datenbank wieder konsistent macht, indem es beschädigte Teile verwirft. Danach gehört zwingend ein erneutes CHECKDB gefahren und die Storage-Ursache geklärt. Die eigentliche Lehre aber zieht man vorher: Diesen Fall verhindert man durch eine getestete Backup-Strategie.