DBCC CHECKDB: Vollständiger Leitfaden zu MS SQL Server Datenbankzustand (2025)

Eine Beschädigung der Datenbank ist SQL Server Der Albtraum eines Administrators. Wenn kritische Geschäftsdaten unzugänglich oder unzuverlässig werden,ost kann verheerend sein. Dieser umfassende Leitfaden behandelt alles, was Sie über die Verwendung von DBCC CHECKDB wissen müssen, um die Datenbankintegrität zu erhalten und Beschädigungen zu verhindern. Außerdem bietet er erweiterte Wiederherstellungslösungen für den Fall, dass Standardtools nicht ausreichen.

1. Bedeutung von SQL Server Datenbankintegrität

1.1 Welche Datenbankbeschädigung Costs Unternehmen

Heute, most Unternehmen speichern ihre kritischen Daten in Datenbanken. Eine Beschädigung der Datenbank hat verheerende Folgen:

• Finanzielle Verluste durchschnittlich 2.3 Millionen US-Dollar jährlich durch Datenverlust, wobei Hardwarefehler und -beschädigung die Hauptursachen sind (EMC Corporation)
• Geschäftsschließungsraten zeigen, dass 50 % der kleinen Unternehmen, die aufgrund von Hardwarefehlern Datenverlust erleiden, innerhalb von zwei Jahren ihr Geschäft aufgeben müssen, während 94 % der Unternehmen mit katastrophalen Datenverlusten überhaupt nicht überleben.
• Häufigkeit der Datenbeschädigung betrifft jährlich 20 % der unternehmenskritischen Anwendungen und führt zu Störungen der Geschäftskontinuität (Gartner-Studie)
• Hardwarebezogene Beschädigung 67 % aller Datenverluste sind auf Festplattenabstürze und Systemausfälle zurückzuführen, wobei 40 % der Datenverluste direkt auf Hardwarefehler zurückzuführen sind.
• Softwarebeschädigung costs Die Kosten reichen von Tausenden bis zu Millionen Dollar, je nach Schweregrad und Umfang. 82 % der Unternehmen erleben ungeplante Ausfälle, bei denen Korruption eine der Hauptursachen ist.

1.2 Warum regelmäßige Gesundheitschecks wichtig sind

Menschen benötigen regelmäßige Gesundheitschecks, um mögliche Krankheiten frühzeitig zu erkennen. Auch Datenbanken benötigen regelmäßige Gesundheitschecks:

1. Erkennen Sie potenzielle Korruption frühzeitig und gehen Sie umgehend dagegen vor. So verhindern Sie, dass die Probleme schwerwiegend werden und sich ausbreiten, was katastrophale Folgen für das Unternehmen haben könnte.
2. Stellen Sie sicher, dass die Datenbank mit optimaler Leistung arbeitet.
3. Die cost von proaktiven Datenbank-Integritätsprüfungen ist viel geringer als die der reaktiven Datenwiederherstellung nach einem Datenbankdesaster.

1.3 Einführung in Datenbankintegritätsbefehle

SQL Server bietet mehrere integrierte Befehle zur Aufrechterhaltung der Datenbankintegrität, mit DBCC-CHECKDB dient als most Umfassendes Tool zur Integritätsprüfung verfügbar. Diese Befehle arbeiten zusammen, um verschiedene Aspekte Ihrer Datenbankstruktur zu überprüfen, von einzelnen Tabellen bis hin zur gesamten Datenbankkonsistenz. So entsteht eine umfassende Wartungsstrategie, die Ihre Daten sicher und zugänglich hält.

2. Was ist DBCC CHECKDB

DBCC-CHECKDB is SQL ServerDas wichtigste Tool von zum Überprüfen der Datenbankintegrität und zum Identifizieren von Beschädigungsproblemen.

• Es handelt sich um eine T-SQL-Anweisung, nicht um ein GUI-Tool.
• Sie können es über gängige Methoden ausführen, wie zum Beispiel SQL Server Management Studio (SSMS), SQL Server Agent, SQLCMD usw.

2.1 Was CHECKDB tatsächlich in Ihrer Datenbank prüft

Wenn Sie DBCC CHECKDB ausführen, führt der Befehl mehrere Validierungsebenen in Ihrer Datenbankstruktur durch:

• Überprüfung der Seitenprüfsummen um physische Beschädigungen und Hardwareprobleme zu erkennen
• Validierung der Indexkonsistenz um eine ordnungsgemäße Datenabruf- und Abfrageleistung sicherzustellen
• Prüfungen der Allokationsstruktur um die genaue Speicherplatznutzung und Seitenzuweisung zu bestätigen
• Prüfung der referenziellen Integrität zwischen verknüpften Tabellen und Fremdschlüsselbeziehungen
• Validierung der Systemtabellenkonsistenz sicherstellen SQL ServerDie internen Metadaten bleiben zuverlässig
• Überprüfung der Datenseitenverknüpfung um die ordnungsgemäße Integrität der Seitenkette zu bestätigen
• Datenbankschemakonsistenz um Objektdefinitionen und Abhängigkeiten zu validieren

Diese umfassenden Prüfungen decken sowohl Benutzerdaten als auch Systemstrukturen ab und bieten vollständige Transparenz über den Gesundheitszustand Ihrer Datenbank.

3. Ausführen von DBCC CHECKDB: Schritt für Schritt

3.1-Voraussetzungen

Nachfolgend finden Sie die Checkliste vor der Ausführung eines DBCC CHECKDB-Vorgangs:

• Vollständige Datenbanksicherung – Erstellen Sie vor der Durchführung von Integritätsprüfungen eine vollständige Sicherung als Sicherheitsnetz, falls Beschädigungen festgestellt werden oder Reparaturvorgänge erforderlich werden.
• Richtige Berechtigungen – Sie benötigen Sysadmin- oder db_owner-Berechtigungen, um DBCC CHECKDB-Befehle auszuführen
• Ausreichende Systemressourcen:
  • Speicher: 25 % der Datenbankgröße
  • Tempdb-Speicherplatz: 10–15 % der Datenbankgröße
  • CPU: 50–70 % Verfügbarkeit während der Wartung
  • E/A: Erwarten Sie umfangreiche Lesevorgänge
• Datenbankzugriff – Stellen Sie sicher, dass Ihre Datenbank zugänglich ist und sich nicht in einem eingeschränkten Zustand befindet, da CHECKDB Lesezugriff auf alle Datenbankseiten benötigt

3.2 Grundlegende Befehle

Die most Der grundlegende DBCC CHECKDB-Befehl umfasst drei gängige Varianten:

(1) Überprüfen Sie die aktuelle Datenbank (keine Parameter):

DBCC CHECKDB

(2) Überprüfen Sie eine Datenbank anhand des Namens:

DBCC CHECKDB ('YourDatabaseName')

(3) Überprüfen Sie eine Datenbank anhand der ID:

DBCC CHECKDB(5)  -- Replace 5 with your database ID

Dieser grundlegende Befehl führt eine vollständige Integritätsprüfung der angegebenen Datenbank durch und untersucht dabei alle Tabellen, Indizes und Systemstrukturen. Bei Datenbanken mit Standardnamen ohne Leerzeichen können Sie die Anführungszeichen weglassen. Der Befehl wird bis zum Abschluss ausgeführt und zeigt Fortschrittsmeldungen und Endergebnisse an. Diese grundlegende Syntax eignet sich ideal für kleinere Datenbanken oder wenn ausreichend Zeit für die Wartung zur Verfügung steht.

Unten sehen Sie einen Screenshot der Ausführung von DBCC CHECKDB in SQL Server Management Studio (SSMS):

3.3 Vollständige Optionen

Nachfolgend sind die vollständigen Optionen für DBCC CHECKDB aufgeführt:

Kategorie	Option	BESCHREIBUNG	DBCC CHECKDB-Beispiel
Reparaturoptionen	REPAIR_REBUILD	Reparaturen ohne Datenverlust (z. B. Indexneuaufbau)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Keine Reparatur. Nur Abwärtskompatibilität	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Repariert alle Fehler (kann zu Datenverlust führen)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Umfangskontrolle	NOINDEX	Überspringt nicht gruppierte Indexprüfungen	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Überprüft nur die physische Speicherintegrität (Seiten/Datensätze)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Prüft auf logische Spaltenwertfehler (z. B. ungültige Daten)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Tiefgehende logische Prüfungen (indizierte Ansichten, XML/räumliche Indizes)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Ausgabesteuerung	ALL_ERRORMSGS	Zeigt alle Fehler an (Standard: 200 pro Objekt)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Versteckt Informationsmeldungen	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Kennzahlen	TABLOCK	Verwendet Tabellensperren (reduziert die TempDB-Nutzung, blockiert aber Schreibvorgänge)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Überschreibt Parallelitätseinstellungen	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Dienstprogramm	ESTIMATEONLY	Schätzt den benötigten TempDB-Speicherplatz. (keine tatsächliche Prüfung)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Ihre Ergebnisse verstehen

DBCC CHECKDB liefert unterschiedliche Ergebnisse, je nachdem, ob die Ausführung erfolgreich abgeschlossen wurde oder nicht. Wir erklären sie im Detail.

4.1 CHECKDB-Ausführung erfolgreich abgeschlossen

Wenn die Ausführung von DBCC CHECKDB erfolgreich abgeschlossen wird, werden je nach Integritätsstatus Ihrer Datenbank unterschiedliche Ergebnistypen gemeldet.

4.1.1 Keine Probleme gefunden

Wenn DBCC CHECKDB keine Probleme findet, wird eine Ausgabe ähnlich der folgenden angezeigt:

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Dieses Ergebnis zeigt, dass Ihre Datenbank über alle geprüften Strukturen hinweg eine perfekte Integrität aufweist.

4.1.2 Gefundene Korruptionsfehler

Immer wenn DBCC CHECKDB einen Beschädigungsfehler erkennt, wird eine Fehlermeldung mit der folgenden Struktur ausgegeben:
Leitfaden zum Schweregrad:

• Level 16-19: Vom Benutzer korrigierbare Fehler, oft geringfügige Beschädigungen
• Level 20-24: Systemfehler, schwerwiegende Beschädigungen, die sofortige Aufmerksamkeit erfordern
• Niveau 25: Schwerwiegende Fehler, möglicherweise ist der Zugriff auf die Datenbank nicht möglich

Häufige Fehler sind:

• Seitenprüfsummenfehler (Meldung 824)
• Zuordnungsfehler (Meldung 8928)
• Indexkonsistenzprobleme (Meldung 8964)

Das Verständnis der Nachrichtenstruktur hilft dabei, Reaktionsmaßnahmen zu priorisieren und geeignete Wiederherstellungsstrategien zu bestimmen.

4.1.3 Allgemeine Informations- und Warnmeldungen

Nicht alle DBCC CHECKDB-Ausgaben weisen auf schwerwiegende Probleme hin. Es können auch einige Informations- und Warnmeldungen ausgegeben werden, darunter:

• Reparaturerklärungen – Nachrichten, die Reparaturbefehle zur Behebung kleinerer Probleme vorschlagen
• Allokationswarnungen – Warnungen zur Speicherplatzzuweisung, die den Datenzugriff nicht beeinträchtigen
• Empfehlungen zur Leistung – Vorschläge zur Indexpflege und -optimierung
• Informationshinweise – Allgemeine Statusmeldungen, die kein sofortiges Handeln erfordern

Diese Meldungen bieten wertvolle Hinweise zur Wartung und unterscheiden zwischen kritischen Beschädigungen, die sofortiges Handeln erfordern, und kleineren Problemen, die während der regulären Wartungsfenster behoben werden können.

Beispiel einer Warnmeldung:

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 CHECKDB-Ausführungsabbrüche

Wenn CHECKDB während der Ausführung aus verschiedenen Gründen abbricht, wird eine Fehlermeldung ausgegeben und ein Fehlerprotokoll mit dem folgenden Statuscode hinzugefügt:

Staat	BESCHREIBUNG
0	Es wurde Fehlernummer 8930 ausgegeben. Dies weist auf eine Beschädigung der Metadaten hin, die zum Abbruch des DBCC-Befehls führte.
1	Fehlernummer 8967 wurde ausgelöst. Es ist ein interner DBCC-Fehler aufgetreten.
2	Während der Datenbankreparatur im Notfallmodus ist ein Fehler aufgetreten.
3	Dies weist auf eine Beschädigung der Metadaten hin, die den DBCC-Befehl beendet hat.
4	Es wurde eine Assert- oder Zugriffsverletzung erkannt.
5	Es ist ein unbekannter Fehler aufgetreten, der den DBCC-Befehl beendet hat.

Beispiel-Fehlermeldung:

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

oder

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

Beispiel eines Fehlerprotokolls:

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

In einem solchen Fall können Sie alternative erweiterte Optionen ausprobieren, wie z. B. DataNumen SQL Recovery um die Beschädigung in Ihrer Datenbank zu beheben.

5. Beheben von Korruptionsfehlern

5.1 Sichern und Wiederherstellen: Die sicherste Lösung

Wenn DBCC CHECKDB Korruptionsfehler erkennt, stellt die Wiederherstellung aus einer sauberen Sicherung die sicherste undost zuverlässige Lösung. Dieser Ansatz garantiert Datenintegrität und beseitigt gleichzeitig die zugrunde liegenden Ursachen für Beschädigungen. Überprüfen Sie vor der Wiederherstellung die Integrität der Sicherung mit NUR ÜBERPRÜFEN WIEDERHERSTELLEN Befehle und berücksichtigen Sie zeitpunktbezogene Wiederherstellungsoptionen, um Datenverluste zu minimieren. Dokumentieren Sie die Details der Beschädigung für die Ursachenanalyse, da Hardware- oder Softwarefehler möglicherweise zusätzliche Aufmerksamkeit erfordern, um ein erneutes Auftreten zu verhindern.

5.2 Lösungen für Beschädigungen auf Seitenebene

Bei isolierten Seitenbeschädigungen, die kleine Datenteile betreffen, SQL Server Die Enterprise Edition bietet Funktionen zur Seitenwiederherstellung, mit denen bestimmte beschädigte Seiten repariert werden können, ohne dass die Datenbank vollständig wiederhergestellt werden muss. Diese erweiterte Technik erfordert ein vollständiges Wiederherstellungsmodell und aktuelle Protokollsicherungen.

Schrittweiser Seitenwiederherstellungsprozess:

1. Identifizieren Sie die beschädigte Seite aus CHECKDB-Fehlermeldung (zB Seite 1:256)
2. Erstellen Sie eine aktuelle Protokollsicherung um aktuelle Transaktionen zu erfassen:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

3. Stellen Sie die beschädigte Seite wieder her vom most letzte vollständige Sicherung:

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

4. Differenzielle Sicherung anwenden (wenn verfügbar):

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

5. Alle Protokollsicherungen anwenden der Reihe nach, einschließlich der gerade erstellten:

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

6. Erstellen Sie eine abschließende Protokollsicherung und stellen Sie sie wieder her um die Seite auf den neuesten Stand zu bringen:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

Alternative für nicht kritische Daten: Wenn die Beschädigung nicht kritische Daten betrifft, können Sie nicht betroffene Zeilen in neue Tabellen exportieren, bevor Sie beschädigte Strukturen neu erstellen:

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 Schnelle Lösungen für Indexbeschädigungen

Indexbeschädigungen lassen sich häufig gut durch Wiederherstellungsvorgänge beheben, bei denen die Indexstrukturen neu erstellt werden, ohne die zugrunde liegenden Tabellendaten zu beeinträchtigen:

ALTER INDEX ALL ON YourTable REBUILD

Dieser Ansatz funktioniert besonders gut bei Beschädigungen nicht gruppierter Indizes, da beim Neuerstellen die Indexseiten aus den Daten der Quelltabelle regeneriert werden. Dadurch werden Beschädigungen effektiv beseitigt, während alle ursprünglichen Informationen erhalten bleiben.

6. Verwenden Sie REPAIR_REBUILD und REPAIR_ALLOW_DATA_LOSS

Wenn alle vorherigen Methoden fehlschlagen oder nicht durchführbar sind, können Sie die Optionen REPAIR_REBUILD und REPAIR_ALLOW_DATA_LOSS verwenden, um die Datenbank zu reparieren.

6.1 REPAIR_REBUILD (Sicherere Option):

• Verwenden für: Indexbeschädigungen und geringfügige Zuordnungsfehler
• Datensicherheit: Versucht, Beschädigungen zu beheben, ohne Daten zu löschen
• Risikostufe: Niedrig – kein Datenverlust zu erwarten
• Typische Szenarien: Beschädigung des nicht gruppierten Index, kleinere Metadatenprobleme
• Befehlsbeispiel: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Letzter Ausweg):

• Verwenden für: Schwere Beschädigung, wenn keine Sicherungen verfügbar sind
• Datensicherheit: Kann beschädigte Daten löschen, um die Datenbankfunktionalität wiederherzustellen
• Risikostufe: Hoch – dauerhafter Datenverlust möglich
• Typische Szenarien: Seitenbeschädigung, Systemtabellenschaden, Zuordnungskettenfehler
• Befehlsbeispiel: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Best Practices für diese Optionen:

• Immer testen Reparaturvorgänge an Datenbankkopien, sofern möglich
• Immer sichern bevor Sie diese Optionen ausführen
• Dokumentieren Sie alle Änderungen zu Compliance- und Fehlerbehebungszwecken
• Datenbank auf Einzelbenutzermodus einstellen vor der Durchführung von Reparaturvorgängen

Normalerweise sollten wir versuchen REPARATUR_WIEDERHERSTELLEN Option zuerst. Wenn es fehlschlägt, versuchen Sie REPAIR_ALLOW_DATA_LOSS .

6.4 REPAIR_ALLOW_DATA_LOSS-Ergebnisse

6.4.1 Reparatur gelingt trotz Datenverlust

Manchmal die REPAIR_ALLOW_DATA_LOSS Option wird erfolgreich sein, aber einige Daten sind lost nach der Reparatur.

Nachfolgend finden Sie einige Beispielnachrichten:

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

Dies liegt daran, dass DBCC CHECKDB die Datenbank repariert, indem einige beschädigte Datensätze verworfen werden, aber tatsächlich, most davon können noch wiederhergestellt werden über DataNumen SQL Recovery.

Beispieldateien:

SQL Server Version	Beschädigte MDF-Datei	MDF-Datei behoben durch DataNumen SQL Recovery
SQL Server 2014	Fehler10_1.mdf (Msg 8909 gefolgt von Msg 8939) (600 Datensätze lost mit REPAIR_ALLOW_DATA_LOSS)	Fehler10_1_fixed.mdf (Kein Datensatz lost)
SQL Server 2014	Fehler10_2.mdf (Msg 8909 gefolgt von Msg 8939) (6000 Datensätze (50%) lost mit REPAIR_ALLOW_DATA_LOSS)	Fehler10_2_fixed.mdf (Nur 100 Datensätze lost)
SQL Server 2014	Fehler 7.mdf (100 Datensätze lost mit REPAIR_ALLOW_DATA_LOSS)	Fehler7_fixed.mdf (Nur ein Datensatz lost)

6.4.2 Reparatur schlägt fehl – ​​Professionelle Lösung in Betracht ziehen

If REPAIR_ALLOW_DATA_LOSS fehlschlägt, werden eine oder mehrere Fehlermeldungen ausgegeben.

Nachfolgend einige Beispiele:

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

In diesen Szenarien benötigen Sie eine professionelle Lösung wie DataNumen SQL Recovery um Ihre Datenbank zu reparieren.

Beispieldateien

SQL Server Version	Beschädigte MDF-Datei	MDF-Datei behoben durch DataNumen SQL Recovery
SQL Server 2014	Fehler1_3.mdf (Einzelnachricht 824)	Fehler1_3_fixed.mdf
SQL Server 2014	Fehler1_1.mdf (Kontinuierliche Meldung 824-Fehler)	Fehler1_1_fixed.mdf
SQL Server 2014	Fehler1_2.mdf ((Nachricht 824 gefolgt von Nachricht 7909)	Fehler1_2_fixed.mdf
SQL Server 2014	Fehler4_1.mdf (Nachricht 8992 gefolgt von Nachricht 3852)	Fehler4_1_fixed.mdf
SQL Server 2014	Fehler4_2.mdf (Nachricht 8992 gefolgt von Nachricht 3852)	Fehler4_2_fixed.mdf
SQL Server 2014	Fehler5.mdf (Nachricht 8945)	Fehler5_fixed.mdf
SQL Server 2014	Fehler6.mdf (Nachricht 2510)	Fehler6_fixed.mdf
SQL Server 2014	Fehler2.mdf (Nachricht 2575)	Fehler2_fixed.mdf
SQL Server 2014	Fehler11.mdf (Nachricht 8905)	Fehler11_fixed.mdf
SQL Server 2014	Fehler3.mdf (Nachricht 5028)	Fehler3_fixed.mdf
SQL Server 2014	Fehler 8.mdf (Nachricht 5125)	Fehler 8_fixed.mdf
SQL Server 2014	Fehler9.mdf (Nachricht 3313)	Fehler9_fixed.mdf

7. Best Practices

7.1 Planen regelmäßiger CHECKDB-Operationen

Implementieren Sie wöchentliche DBCC CHECKDB-Ausführungen für kritische Produktionsdatenbanken, mit täglichen Prüfungen für Systeme mit hohem Transaktionsaufkommen. Planen Sie Vorgänge in Zeiten geringer Auslastung, um die Leistungseinbußen zu minimieren, und wechseln Sie je nach Datenbankgröße und Wartungsfenstern zwischen vollständigen Prüfungen und PHYSICAL_ONLY-Optionen. Automatisierte Planung durch SQL Server Der Agent gewährleistet eine konsistente Ausführung und bietet gleichzeitig zentrale Überwachungs- und Warnfunktionen.

7.2 Performance Impact Management

DBCC CHECKDB-Operationen verbrauchen erhebliche Systemressourcen und können die gleichzeitige Benutzeraktivität beeinträchtigen. Überwachen Sie CPU-Auslastung, Speicherverbrauch und Festplatten-E/A während der Prüfungen, um Leistungseinbußen zu erkennen. Erwägen Sie die Verwendung von NOINDEX-Optionen für Routineprüfungen und reservieren Sie die vollständige Validierung für monatliche Wartungsfenster. Implementieren Sie Erweiterungen für Abfragetimeouts und Strategien zur Benutzerkommunikation, um die Erwartungen während der Integritätsprüfungen zu steuern.

7.3 Wartungsfensterplanung

Koordinieren Sie die DBCC CHECKDB-Planung mit anderen Wartungsaktivitäten wie Sicherungsvorgängen, Indexneuaufbau und Statistikaktualisierungen. Vermeiden Sie die Überschneidung ressourcenintensiver Vorgänge, die zu Leistungseinbußen oder Timeout-Problemen führen können. Planen Sie Wartungsfenster basierend auf dem prognostizierten Datenbankwachstum und stellen Sie sicher, dass bei zunehmendem Datenvolumen ausreichend Zeit für eine vollständige Integritätsprüfung bleibt.

7.4 Automatisierte Überwachung und Alarmierung

Einrichtung SQL Server Agentenwarnungen informieren Administratoren sofort, wenn DBCC CHECKDB eine Beschädigung erkennt. Implementieren Sie Lösungen zur Protokollanalyse, die Ergebnisse von Integritätsprüfungen extrahieren und kategorisieren. Dies ermöglicht Trendanalysen und eine proaktive Problemerkennung. Erstellen Sie Eskalationsverfahren, die Reaktionszeiträume und zuständige Mitarbeiter für unterschiedliche Schweregrade der Beschädigung definieren.

8. DBCC CHECKTABLE: Die leichte Alternative

8.1 Wann wird CHECKTABLE anstelle von CHECKDB verwendet?

DBCC CHECKTABLE bietet eine fokussierte Integritätsprüfung für einzelne Tabellen und ist somit ideal für tarFehlerbehebung und Wartung bestimmter Datenbankobjekte. Verwenden Sie CHECKTABLE, um Leistungsprobleme mit bestimmten Tabellen zu untersuchen, kritische Geschäftstabellen zwischen vollständigen Datenbankprüfungen zu validieren oder wenn Zeitbeschränkungen eine vollständige Datenbankvalidierung verhindern. Dieser Ansatz erweist sich besonders bei großen Datenbanken als nützlich, bei denen vollständige CHECKDB-Operationen die verfügbaren Wartungsfenster überschreiten.

8.2 DBCC CHECKTABLE Syntax und Beispiele

Der grundlegende CHECKTABLE-Befehl tarerhält bestimmte Tabellen:

DBCC CHECKTABLE('YourTable')

Wie CHECKDB unterstützt CHECKTABLE verschiedene Optionen, darunter NOINDEX zur Leistungsoptimierung und Reparaturparameter zur Behebung von Fehlern. Sie können auch Schemanamen zur präzisen Tabellenidentifizierung angeben:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Dieser tarDer bewährte Ansatz ermöglicht eine detaillierte Integritätsprüfung bei gleichzeitiger Aufrechterhaltung der Systemleistung während der Geschäftszeiten.

8.3 Leistungsvorteile bei großen Datenbanken

CHECKTABLE-Operationen werden deutlich schneller ausgeführt als vollständige Datenbankprüfungen und ermöglichen so eine häufigere Integritätsprüfung kritischer Tabellen. Dieser Ansatz ermöglicht die tägliche Validierung wichtiger Geschäftstabellen, während umfassende CHECKDB-Operationen wöchentlich oder monatlich durchgeführt werden. Durch den reduzierten Ressourcenverbrauch eignet sich CHECKTABLE für die Ausführung in Produktionsumgebungen mit minimalen Benutzereinflüssen.

9. Wenn CHECKDB fehlschlägt

DBCC CHECKDB schlägt in verschiedenen Szenarien fehl, darunter:

• DBCC CHECKDB-Ausführung wird abnormal beendet
• Die Ausführung von DBCC CHECKDB wird erfolgreich abgeschlossen, aber die Reparaturmöglichkeiten Die Reparatur der Datenbank schlägt fehl.

In diesen Szenarien benötigen wir ein professionelleres Tool, das uns hilft, die Beschädigungen in der Datenbank zu beheben.

9.1 Einführung in DataNumen SQL Recovery

DataNumen SQL Recovery bietet erweiterte Funktionen:

• Beste Wiederherstellungsrate in der Industrie.
• Stellen Sie stark beschädigte Datenbankdateien wieder her.
• Stellen Sie alle Datenbankobjekte wieder her, einschließlich Tabellen, Indizes, Ansichten, Trigger, Regeln und Standardwerte.
• Stellen Sie gespeicherte Prozeduren, Skalarfunktionen, Inline-Tabellenwertfunktionen und Tabellenwertfunktionen mit mehreren Anweisungen wieder her.
• Stellen Sie dauerhaft gelöschte Datensätze wieder her.
• Entschlüsseln Sie verschlüsselte Objekte in SQL Server Datenbanken.
• Reparieren Sie MDF-Dateien im Stapel.
• Umfassende Reparaturmöglichkeiten.
• Erweiterte Protokollierung und Berichterstellung.
• Unterstützung für alle SQL Server Versionen.
• Verfügbarkeit des technischen Supports
• Regelmäßige Updates und Verbesserungen

9.2 Vergleich der Erfolgsquoten

Die Erfolgsraten bei der Wiederherstellung unterscheiden sich erheblich:

• DBCC CHECKDB & CHECKTABLE: 1.27% durchschnittliche Wiederfindungsrate
• DataNumen: 92.6% Erholungsrate

Nachfolgend finden Sie einen vollständigen Wettbewerbsvergleich:

9.3 Wiederherstellung nach schwerer Korruption

Erweiterte Funktionen für schwere Fälle:

• Wiederherstellung aus physisch beschädigtem Speicher
• Wiederherstellung von formatierten Laufwerken oder abgestürzten Systemen
• Wiederherstellen von Disk-Images, Backup-Dateien, virtuellen Maschinen-Disk-Dateien, Temporary-Dateien usw.

9.4 Wann sind professionelle Lösungen sinnvoll?

• Keine aktuelle Backup-Verfügbarkeit
• DBCC CHECKDB schlägt fehl
• Schwere Korruptionsszenarien
• Umgang mit kritischen Geschäftsdaten
• Wenn die Zeit knapp ist
• Wenn maximale Erholung wichtig ist

10. FAQs

11. Fazit

11.1 Zusammenfassung der wichtigsten Punkte

11.1.1 Zusammenfassung der wichtigsten DBCC CHECKDB-Befehle

Beherrschen Sie die grundlegende DBCC CHECKDB-Syntax für umfassende Datenbankprüfungen, nutzen Sie die Optionen NOINDEX und PHYSICAL_ONLY zur Leistungsoptimierung und verstehen Sie CHECKTABLE für tarGeted Table Verification. Diese grundlegenden Befehle bilden die Grundlage für eine proaktive Datenbankwartung und ermöglichen eine frühzeitige Beschädigungserkennung und eine systematische Integritätsüberwachung.

11.1.2 Wichtige Best Practices-Erinnerung

Erstellen Sie vor Integritätsprüfungen stets aktuelle Backups, planen Sie regelmäßige CHECKDB-Operationen basierend auf der Datenbankkritikalität und implementieren Sie eine automatisierte Überwachung für sofortige Warnungen bei Beschädigungen. Bedenken Sie, dass Prävention durch regelmäßige Überwachung reaktive Ansätze übertrifft. Professionelle Wiederherstellungslösungen bieten wertvolle Backup-Optionen, wenn Standardtools nicht ausreichen.

11.2 Wann ist DBCC CHECKDB im Vergleich zu erweiterten Lösungen zu verwenden?

Verwenden Sie DBCC CHECKDB für die routinemäßige Integritätsüberwachung und die Behebung geringfügiger Beschädigungen. Professionelle Wiederherstellungstools sollten jedoch nur bei schwerwiegenden Beschädigungen eingesetzt werden, die über die integrierten Reparaturfunktionen hinausgehen. Der Entscheidungsrahmen sollte die Verfügbarkeit von Backups, die Wichtigkeit der Daten, Zeitbeschränkungen und den Schweregrad der Beschädigung berücksichtigen. Erfolgreiche Datenbankadministratoren kombinieren regelmäßige CHECKDB-Überwachung mit umfassenden Backup-Strategien und kennen erweiterte Wiederherstellungsoptionen, wenn sich Standardansätze als unzureichend erweisen.

12. Referenzen

1. Microsoft Learn. „DBCC CHECKDB (Transact-SQL).“ SQL Server Dokumentation. Microsoft Corporation.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. „Beheben Sie von DBCC CHECKDB gemeldete Datenbankkonsistenzfehler.“ SQL Server Dokumentation. Microsoft Corporation.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors