DBCC CHECKDB — die Konsistenz-Strategie

Wann, wie oft, auf welcher Maschine? Korruption früh finden, statt sie im Backup mitzusichern — und richtig reagieren, wenn sie auftaucht.

Datenkorruption ist die heimtückischste aller Datenbank-Krankheiten, weil sie lange völlig symptomfrei verläuft. Eine beschädigte Datenseite tief in einer selten gelesenen Tabelle stört monatelang niemanden — bis der eine Bericht sie anfasst, der einmal im Quartal läuft, und plötzlich Fehler 824 im Protokoll steht. Das eigentliche Drama beginnt aber früher und leiser: Solange die Korruption unbemerkt bleibt, wird sie brav mitgesichert. Jede Nacht wandert der Schaden in ein neues Backup, und wenn er endlich auffällt, sind womöglich alle aufbewahrten Sicherungen längst verseucht. Das beste Backup-Konzept der Welt ist wertlos, wenn es eine kaputte Datenbank konserviert.

Genau deshalb gibt es DBCC CHECKDB — die Tiefenprüfung, die Korruption findet, solange sie noch klein und reparierbar ist und solange es noch saubere Backups gibt. Dieser Beitrag aus dem SQL-Server-Notarztwagen (die Triage-Übersicht liegt unter /sql-server-notarztwagen/) zeigt dir die Konsistenz-Strategie: wann und wie oft du prüfst, wie du die Last großer Datenbanken bändigst und — am wichtigsten — wie du richtig reagierst, wenn CHECKDB tatsächlich anschlägt. Als Beitrag der GRÜN-Stufe geht es um die ruhige Vorsorge; der akute Korruptions-Notfall mit Status Suspect hat seinen eigenen ROT-Beitrag.

Was CHECKDB prüft — und warum Vorsorge alles ist

DBCC CHECKDB ist die umfassende Konsistenzprüfung des SQL Servers. Es liest praktisch die gesamte Datenbank und verifiziert, dass alle internen Strukturen stimmig sind: dass die Datenseiten physisch unbeschädigt sind, dass die Verkettungen zwischen Seiten und die B-Baum-Strukturen der Indizes konsistent sind, dass Allokations-Strukturen mit den tatsächlich belegten Seiten übereinstimmen und dass die logischen Beziehungen zwischen Tabellen und ihren Indizes intakt sind. Kurz: Es ist der gründliche Gesundheits-Check, der weit über das hinausgeht, was der normale Betrieb je bemerken würde.

Die meisten Korruptionen entstehen nicht im SQL Server selbst, sondern eine Etage tiefer: im Storage-Subsystem. Ein Controller mit defektem Cache, ein RAID-Verbund mit einem schleichenden Plattenfehler, ein Firmware-Bug, ein Stromausfall im falschen Moment — sie alle können einzelne Bits auf der Platte umkippen, ohne dass der SQL Server im Schreibmoment etwas merkt. Genau hier setzt die erste Verteidigungslinie an: PAGE_VERIFY CHECKSUM. Mit dieser Einstellung berechnet der Server beim Schreiben jeder Seite eine Prüfsumme und kontrolliert sie beim nächsten Lesen — eine umgekippte Seite fällt damit schon im laufenden Betrieb auf, lange bevor das geplante CHECKDB läuft. CHECKDB ist die geplante Tiefenprüfung obendrauf, die auch die Bereiche erreicht, die selten gelesen werden. Wenn dir im Protokoll einmal der berüchtigte Fehler 824 begegnet (oder seine Verwandten 823 und 825), ist das übrigens genau die laufende Wache, die anschlägt: Der SQL Server hat beim Lesen eine Seite gefunden, deren Prüfsumme nicht stimmt, und verweigert die Auslieferung beschädigter Daten — eine unangenehme, aber ehrliche Meldung. Ohne CHECKSUM wäre dieselbe Seite stillschweigend mit falschem Inhalt zurückgegeben worden, und der Schaden hätte sich unbemerkt weiterverbreitet.

Der ganze Sinn der Übung ist Zeit: Korruption früh zu finden bedeutet, sie zu finden, solange noch ein sauberes Backup existiert. Findest du sie spät, hast du womöglich nur noch verseuchte Sicherungen und stehst vor der schlechtesten aller Optionen — der Reparatur mit Datenverlust. Deshalb ist die Frequenz von CHECKDB direkt an die Backup-Aufbewahrung gekoppelt: Du musst Korruption entdecken, bevor das letzte saubere Backup aus dem Aufbewahrungsfenster rollt. Eine Datenbank, die nie geprüft wird, ist nicht etwa risikofrei — sie ist eine Wette darauf, dass das Storage nie einen Fehler macht.

Die Strategie nach Datenbankgröße

Prüfen muss man immer — aber wie man prüft, hängt von der Größe der Datenbank und vom verfügbaren Wartungsfenster ab. Die folgende Skizze zeigt die Staffelung von klein bis groß und die richtige Reaktion auf einen Fehler:

Die Skripte: prüfen, verifizieren, abstufen

Schritt 1 — Page Verify und Korruptions-Historie prüfen

Bevor du eine CHECKDB-Strategie aufbaust, der Blick auf die erste Verteidigungslinie und auf bereits gemeldete Schäden:

Die suspect_pages-Tabelle sollte leer sein — jede Zeile ist eine vom Server bereits bemerkte Korruption und ein Fall für die Reaktions-Reihenfolge weiter unten. Beachte beim Umstellen von PAGE_VERIFY: Die Prüfsumme greift nur für Seiten, die nach der Umstellung geschrieben werden — Altbestände werden erst beim nächsten Schreiben abgedeckt, weshalb ein anschließendes vollständiges CHECKDB sinnvoll ist.

Schritt 2 — CHECKDB in den passenden Varianten

WITH NO_INFOMSGS unterdrückt die Erfolgsmeldungen und lässt nur Fehler übrig — unverzichtbar, damit ein echtes Problem nicht in hunderten Zeilen Routine-Ausgabe untergeht. PHYSICAL_ONLY ist der wichtigste Geschwindigkeits-Hebel für mittlere Datenbanken: Es findet die häufigste, storage-bedingte Korruption schnell, lässt aber die teuren logischen Prüfungen weg, die man dann seltener vollständig fährt.

Schritt 3 — Die Last auf eine Restore-Kopie verlagern

Der eleganteste Weg für große Datenbanken: das Backup auf einem separaten Server zurückspielen und dort prüfen. Das schont die Produktion und testet nebenbei das Backup — zwei Pflichten, ein Vorgang:

Wenn CHECKDB anschlägt — die richtige Reaktion

Reihenfolge bewahren, nicht reflexhaft reparieren

Der Moment, in dem CHECKDB einen Fehler meldet, ist der Moment, in dem die meisten Fehler gemacht werden — meist aus Panik. Die richtige Reaktion folgt einer festen Reihenfolge. Erstens: die komplette Meldung sichern. Fehleranzahl, betroffene Objekte und die empfohlene Mindest-Reparaturstufe sind die Grundlage jeder Entscheidung — ein Screenshot oder eine Logdatei, bevor irgendjemand etwas anfasst. Zweitens, der Goldstandard: aus einem sauberen Backup wiederherstellen. Ein Backup, das vor dem Auftreten der Korruption liegt, plus ein Tail-Log-Backup für die seither erfolgten Transaktionen — das ist die Wiederherstellung ohne Datenverlust, und sie ist fast immer möglich, wenn die Konsistenz-Strategie und die Backup-Strategie zusammenpassen.

REPAIR_ALLOW_DATA_LOSS — die Notlandung, nicht der Standard

Erst wenn kein brauchbares Backup existiert, kommt die letzte Option ins Spiel: REPAIR_ALLOW_DATA_LOSS. Der Name ist eine Warnung, kein Beiname — diese Reparatur stellt die Konsistenz wieder her, indem sie beschädigte Daten wegwirft. Sie macht die Datenbank wieder benutzbar, aber zum Preis der verlorenen Inhalte, und sie ist deshalb immer die Notlandung, nie der erste Griff. Der gefährlichste Reflex im ganzen Thema ist, die von CHECKDB genannte Reparaturstufe als Handlungsanweisung misszuverstehen: Auch wenn dort REPAIR_ALLOW_DATA_LOSS als Mindeststufe steht, heißt das nur „so schwer ist der Schaden“ — nicht „führe das jetzt aus“. Die Wiederherstellung aus dem Backup bleibt der erste Weg. Wie der akute Korruptions-Notfall im Detail abläuft, steht im Suspect-Beitrag der ROT-Stufe.

Die Ursache klären — sonst kommt sie wieder

Ist die Datenbank gerettet, ist die Arbeit nicht vorbei. Korruption ist ein Symptom, fast immer eines Hardware- oder Storage-Problems — und ohne behobene Ursache kehrt sie zurück, oft schon im nächsten Backup-Zyklus. Deshalb gehört nach jeder Korruption die Storage-Seite untersucht: Controller-Logs, RAID-Status, Plattengesundheit, Firmware-Stände. Mehrfach korruptierende Datenbanken auf derselben Maschine sind ein lautes Signal, dass das Problem unter dem SQL Server liegt. Wer nur repariert und die Ursache ignoriert, behandelt das Fieber und lässt die Infektion laufen. Ein praktischer Schutz gegen die unbemerkte Weiterverbreitung ist dabei die Option WITH CHECKSUM beim Backup: Sie prüft die Seiten beim Sichern auf ihre Prüfsumme und schlägt Alarm, wenn bereits beschädigte Daten in die Sicherung wandern würden. So wird verhindert, dass eine Korruption stillschweigend in jedes Backup kopiert wird — die Sicherung selbst wird zur zweiten Kontrollinstanz, und ein fehlschlagendes Backup ist hier ein willkommener Frühwarner statt eines Ärgernisses.

Was du auf keinen Fall tun solltest

Konsistenzprüfung in der Routine

Die Konsistenz-Strategie ist überwiegend Automatisierung mit klaren Regeln. Drei Punkte machen sie verlässlich: Erstens, CHECKDB automatisiert und überwacht fahren — Ola Hallengrens DatabaseIntegrityCheck ist der etablierte Weg, die Prüfung geplant und protokolliert auszuführen, mit Alarm bei Fehlern. Zweitens, die Prüfung mit dem Backup-Test koppeln: Wer große Datenbanken ohnehin auf einer Restore-Kopie prüft, erschlägt Konsistenzprüfung und Wiederherstellbarkeits-Test in einem Vorgang — die effizienteste Routine überhaupt. Drittens, Page Verify und Korruptions-Historie in den Health Check aufnehmen, damit CHECKSUM überall aktiv ist und keine Zeile in suspect_pages unbemerkt bleibt. Wie die Konsistenzprüfung ins große Bild der proaktiven Wartung passt, zeigt der Health-Check-Beitrag der GRÜN-Stufe.

Vertiefung in der Buchreihe

Konsistenzprüfung, Korruptions-Diagnose und Recovery-Strategien 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 Beiträge im Notarztwagen

Die Konsistenzprüfung ist mit den Recovery-Themen eng verwoben — diese Beiträge aus dem Cluster lohnen den Blick:

Drei Wege zur sauberen Konsistenz-Strategie

Selbst-Diagnose-Kit

Eine CHECKDB-Strategie selbst aufzusetzen ist gut investierte Vorsorge — und genau dafür gibt es das Diagnose-Kit. Es bündelt die Skripte aus diesem Beitrag — Page-Verify- und suspect_pages-Prüfung, CHECKDB in allen Varianten, den Restore-und-prüfen-Ablauf für große Datenbanken — plus die Größen-Staffelung zum Ausdrucken und eine Reaktions-Checkliste für den Fehlerfall. Damit verwandelst du die unsichtbare Bedrohung Korruption in einen kontrollierten, geprüften Prozess.

Festpreis-Analyse

Du willst Gewissheit, dass deine Datenbanken konsistent sind und im Korruptionsfall ein sauberer Weg zurück existiert? Die Festpreis-Analyse liefert sie: Ich prüfe die Konsistenz-Strategie gegen deine Datenbankgrößen und Wartungsfenster, kontrolliere Page Verify und Korruptions-Historie, bewerte das Zusammenspiel mit der Backup-Strategie und liefere einen Bericht mit priorisierten Maßnahmen — inklusive eines durchgeführten Konsistenz- und Restore-Tests. Zum vereinbarten Festpreis, ohne Stundenzähler.

Akut-Hotline

Wenn CHECKDB gerade jetzt einen Fehler gemeldet hat und die richtige Reaktion über Datenverlust oder Rettung entscheidet: anrufen. Halte die vollständige Fehlermeldung bereit und die Information, welche Backups vorliegen. In genau diesem Moment ist die Reihenfolge alles — und der häufigste Fehler ist die voreilige Reparatur, bevor der Restore-Weg geprüft wurde.

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.

Wie oft sollte ich DBCC CHECKDB ausführen?

So regelmäßig wie möglich, mindestens aber so häufig, wie deine Backup-Aufbewahrung reicht — denn Korruption nützt dir wenig, wenn du sie erst entdeckst, nachdem das letzte saubere Backup schon überschrieben ist. Für die meisten Datenbanken ist wöchentlich ein guter Richtwert, kritische Systeme prüft man öfter. Wichtiger als die exakte Frequenz ist die Lückenlosigkeit: Eine Datenbank, die seit der Installation nie geprüft wurde, ist eine tickende Zeitbombe, weil eine schleichende Korruption unbemerkt in jedes Backup wandern kann. Die genaue Frequenz und Methode hängt von der Größe ab — die Skizze in diesem Beitrag zeigt die Staffelung.

Was ist PAGE_VERIFY CHECKSUM?

PAGE_VERIFY CHECKSUM ist eine Datenbankeinstellung, die den SQL Server bei jedem Schreiben einer Datenseite eine Prüfsumme berechnen und beim nächsten Lesen verifizieren lässt. Stimmt die Prüfsumme nicht, ist die Seite zwischen Schreiben und Lesen beschädigt worden — fast immer durch das Storage-Subsystem. Das ist die erste Verteidigungslinie gegen Korruption: Sie macht Schäden schon beim normalen Betrieb sichtbar, lange bevor das geplante CHECKDB läuft. CHECKSUM sollte auf jeder Datenbank aktiv sein; bei alten, migrierten Datenbanken steht oft noch das schwächere TORN_PAGE_DETECTION oder NONE. Die Prüfabfrage dafür steht in diesem Beitrag.

Wie lange dauert DBCC CHECKDB?

Das hängt stark von Datenbankgröße, Storage-Geschwindigkeit und Serverlast ab — von Sekunden bei kleinen Datenbanken bis zu vielen Stunden bei Multi-Terabyte-Systemen. CHECKDB ist eine ressourcenintensive Operation: Es liest praktisch die gesamte Datenbank, beansprucht tempdb erheblich für interne Snapshots und belastet CPU wie I/O. Genau deshalb braucht es bei großen Datenbanken eine Strategie, statt es blind auf der Produktion laufen zu lassen: PHYSICAL_ONLY verkürzt die Prüfung, die Verlagerung auf eine Restore-Kopie nimmt die Last komplett vom Produktivserver, und CHECKFILEGROUP erlaubt das Aufteilen in Etappen. Die Wahl richtet sich nach Größe und Wartungsfenster.

Wie reduziere ich den Performance-Impact?

Mehrere Hebel, je nach Größe gestaffelt. Bei mittleren Datenbanken hilft DBCC CHECKDB WITH PHYSICAL_ONLY: Es prüft die physische Konsistenz (die häufigste, storage-bedingte Korruptionsart) deutlich schneller, lässt aber die teuren logischen Prüfungen weg, die man dann seltener vollständig fährt. Bei großen Datenbanken ist die wirksamste Methode, die Prüfung ganz vom Produktivserver wegzunehmen: das Backup auf einen separaten Server zurückspielen und dort CHECKDB laufen lassen — das prüft die Konsistenz und testet nebenbei das Backup. Zusätzlich lässt sich die Last über CHECKFILEGROUP in Etappen über mehrere Nächte verteilen. WITH NO_INFOMSGS hält die Ausgabe sauber.

Soll ich CHECKDB auf einem Replica laufen lassen?

Vorsicht — das ist ein verbreiteter Irrtum. Ein Always-On-Secondary oder Log-Shipping-Replica teilt sich oft dasselbe oder ein ähnliches Storage-Subsystem nicht, aber eine CHECKDB-Prüfung dort bestätigt nur die Konsistenz der Daten auf diesem Replica — sie sagt nichts über die Korruption auf dem Primary aus, denn jede Maschine kann unabhängig korrumpieren. Der sinnvolle Weg ist stattdessen die Prüfung auf einer frischen Restore-Kopie auf einem dedizierten Server: Die testet gleichzeitig die Wiederherstellbarkeit des Backups und die Konsistenz der gesicherten Daten. Das ist die effizienteste Kombination aus Backup-Test und Konsistenzprüfung — zwei Fliegen mit einer Klappe.

Was bedeuten die verschiedenen Schweregrade von Konsistenzfehlern?

CHECKDB meldet bei Fehlern eine empfohlene Mindest-Reparaturstufe. REPAIR_REBUILD bedeutet, dass der Schaden ohne Datenverlust behoben werden kann (etwa ein beschädigter Nonclustered-Index, der sich neu aufbauen lässt) — das ist der harmlose Fall. REPAIR_ALLOW_DATA_LOSS dagegen bedeutet, dass die Konsistenz nur wiederhergestellt werden kann, indem beschädigte Daten verworfen werden — das ist der ernste Fall. Wichtig: Diese empfohlene Stufe ist eine Information über die Schwere, keine Handlungsaufforderung. Auch bei der Meldung REPAIR_ALLOW_DATA_LOSS ist die richtige erste Reaktion fast immer die Wiederherstellung aus einem sauberen Backup, nicht die Reparatur mit Datenverlust.

Wie reagiere ich auf einen CHECKDB-Fehler?

Mit Ruhe und in fester Reihenfolge. Erstens: die komplette Meldung sichern — Fehleranzahl, betroffene Objekte und empfohlene Reparaturstufe sind die Grundlage jeder weiteren Entscheidung. Zweitens, der Goldstandard: aus einem sauberen Backup wiederherstellen, idealerweise mit einem Tail-Log-Backup für minimalen Datenverlust. Drittens, nur wenn kein brauchbares Backup existiert, die Notlandung REPAIR_ALLOW_DATA_LOSS — sie stellt die Konsistenz her, indem sie beschädigte Daten wegwirft, und ist deshalb immer der letzte Ausweg. Viertens, die Ursache klären: Korruption kommt fast immer vom Storage, und ohne behobene Ursache kehrt sie zurück. Wer hier hastet, macht aus einem Schaden zwei.