Inhaltsverzeichnis verstecken

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):

Ein Screenshot der Ausführung von DBCC CHECKDB in SQL Server Management Studio (SSMS), einschließlich der Ausgabeergebnisse.

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:
Eine detaillierte Erklärung der Struktur der DBCC CHECKDB-Fehlermeldung, einschließlich der Bedeutung jedes Teils.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'
  1. 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'
  1. Differenzielle Sicherung anwenden (wenn verfügbar):
RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'
  1. 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'
  1. 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:

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:

Eine Vergleichstabelle der Wiederherstellungsraten zwischen DataNumen SQL Recovery und andere Wettbewerber, darunter DBCC CHECKDB & CHECKTABLE.

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

10.1 Grundlegende Fragen zur Verwendung

F: Wie oft sollte ich DBCC CHECKDB ausführen?

A: Führen Sie CHECKDB für kritische Produktionsdatenbanken wöchentlich aus. Bei Systemen mit hohem Transaktionsaufkommen sollten Sie tägliche Prüfungen mit der Option PHYSICAL_ONLY und wöchentliche vollständige Prüfungen in Betracht ziehen. Entwicklungsdatenbanken können monatlich geprüft werden.

F: Kann ich DBCC CHECKDB auf einer Live-Produktionsdatenbank ausführen?

A: Ja, DBCC CHECKDB kann auf Online-Datenbanken ausgeführt werden, ohne Benutzer zu blockieren. Es verbraucht jedoch erhebliche Ressourcen. Planen Sie es daher in Zeiten geringer Aktivität ein und überwachen Sie die Systemleistung.

F: Was ist der Unterschied zwischen CHECKDB und CHECKTABLE?

A: CHECKDB untersucht die gesamte Datenbank, während CHECKTABLE sich auf einzelne Tabellen konzentriert. Verwenden Sie CHECKTABLE für tarWenn Sie eine Fehlerbehebung benötigen oder bestimmte Tabellen prüfen möchten, ohne die gesamte Datenbank zu scannen, ist dies hilfreich.

10.2 Leistungs- und Ressourcenfragen

F: Warum dauert DBCC CHECKDB bei meiner großen Datenbank so lange?

A: Die Dauer von CHECKDB hängt von der Datenbankgröße, der Hardwareleistung und den verwendeten Optionen ab. Verwenden Sie PHYSICAL_ONLY für schnellere Prüfungen oder NOINDEX, um nicht gruppierte Indizes zu überspringen. Erwägen Sie die Ausführung während Wartungsfenstern mit dedizierten Ressourcen.

F: Wie viel Tempdb-Speicherplatz benötigt CHECKDB?

A: Reservieren Sie bei CHECKDB-Vorgängen im Allgemeinen 10–15 % Ihrer Datenbankgröße für Tempdb. Verwenden Sie die Option ESTIMATEONLY, um genaue Schätzungen zu erhalten: DBCC CHECKDB('YourDB') WITH ESTIMATEONLY

F: Kann ich einen laufenden CHECKDB-Vorgang abbrechen?

A: Ja, Sie können CHECKDB mit dem Befehl KILL für die Sitzungs-ID abbrechen. Der Abbruch liefert jedoch keine Informationen zur Datenbankintegrität und muss später erneut ausgeführt werden.

10.3 Fragen zur Fehlerbehandlung

F: CHECKDB hat Fehler gefunden – sollte ich in Panik geraten?

A: Keine Panik, sondern schnell handeln. Prüfen Sie zunächst, ob CHECKDB erfolgreich abgeschlossen wurde, aber eine Beschädigung festgestellt hat, oder ob CHECKDB selbst nicht ausgeführt werden konnte. Prüfen Sie, ob Fehler nur nicht gruppierte Indizes (weniger kritisch) oder Tabellendaten (schwerwiegender) betreffen.

F: Wann sollte ich REPAIR_ALLOW_DATA_LOSS verwenden?

A: Nur als allerletzter Ausweg, wenn Sie keine brauchbaren Backups haben und ein Datenverlust im Vergleich zum vollständigen Datenbankverlust akzeptabel ist. Versuchen Sie immer zuerst, aus einem Backup wiederherzustellen, da Reparaturvorgänge zu dauerhaftem Datenverlust führen können.

F: Was bedeutet „Konsistenzfehler in der Datenbank“ im Vergleich zu „Zuordnungsfehlern“?

A: Zuordnungsfehler beeinflussen, wie SQL Server verfolgt die Speicherplatznutzung, während Konsistenzfehler auf Probleme mit Daten- oder Indexstrukturen hinweisen. Beide erfordern Aufmerksamkeit, aber Konsistenzfehler wirken sich in der Regel direkter auf den Datenzugriff aus.

10.4 Fragen zu Sicherung und Wiederherstellung

F: Soll ich CHECKDB für meine Backups ausführen?

A: Unbedingt! Führen Sie CHECKDB nach der Wiederherstellung von Backups auf Testservern aus. Dies überprüft die Integrität des Backups und stellt sicher, dass Sie es nach einer Beschädigung tatsächlich wiederherstellen können. Automatisieren Sie diesen Prozess nach Möglichkeit.

F: Mein Backup ist auch beschädigt – was nun?

A: Versuchen Sie es mit älteren Backups, bis Sie ein sauberes finden. Wenn keine sauberen Backups vorhanden sind, ziehen Sie professionelle Wiederherstellungslösungen in Betracht wie DataNumen SQL Recovery. Dokumentieren Sie den Zeitablauf der Korruption, um zukünftige Vorkommnisse zu verhindern.

F: Kann eine Seitenwiederherstellung Beschädigungen beheben, ohne die Datenbank vollständig wiederherzustellen?

A: Ja, aber nur in SQL Server Enterprise Edition mit vollständigem Wiederherstellungsmodell und aktuellen Protokollsicherungen. Die Seitenwiederherstellung funktioniert bei isolierten Seitenbeschädigungen, erfordert jedoch eine sorgfältige Ausführung gemäß den entsprechenden Verfahren.

10.5 Fragen zur Fehlerbehebung

F: CHECKDB schlägt mit der Fehlermeldung „Nicht genügend Speicherplatz“ fehl – ​​was kann ich tun?

A: Geben Sie Tempdb-Speicherplatz frei, verschieben Sie Tempdb in einen schnelleren Speicher oder verwenden Sie die TABLOCK-Option, um die Tempdb-Nutzung zu reduzieren. Führen Sie CHECKDB ggf. mit NOINDEX oder PHYSICAL_ONLY aus, um den Ressourcenbedarf zu reduzieren.

F: Wie erkenne ich anhand der CHECKDB-Ausgabe, welche Tabelle beschädigt ist?

A: Suchen Sie in Fehlermeldungen nach „Objekt-ID“-Nummern und verwenden Sie dann: SELECT OBJECT_NAME(object_id) um Tabellennamen zu finden. Fehlermeldungen enthalten auch Seiten- und Slot-Nummern zur genauen Standortidentifizierung.

F: Können Hardwareprobleme dazu führen, dass CHECKDB Fehlalarme meldet?

A: Ja, fehlerhafte Hardware (insbesondere Speicher) kann zu zeitweiligen Fehlern führen, die zwischen CHECKDB-Läufen auftreten und wieder verschwinden. Wenn die Fehler inkonsistent sind, untersuchen Sie Ihr E/A-Subsystem und führen Sie mehrere Prüfungen durch, um Muster zu bestätigen.

10.6 Erweiterte Konfigurationsfragen

F: Welche Ablaufverfolgungsflags können die CHECKDB-Leistung verbessern?

A: Das Ablaufverfolgungsflag 2562 kann die Leistung verbessern, indem CHECKDB als einzelner Batch ausgeführt wird. Das Ablaufverfolgungsflag 2549 hilft, wenn sich Datenbankdateien auf separaten Datenträgern befinden. Verwenden Sie diese mit Bedacht und testen Sie sie zunächst außerhalb der Produktion.

F: Wie automatisiere ich die Überwachung und Alarmierung von CHECKDB?

A: Wasser SQL Server Agentenwarnungen für Fehlernummern 8930, 8939 und andere. Implementieren Sie Log-Parsing, um CHECKDB-Ergebnisse zu extrahieren und Benachrichtigungen für entdeckte Beschädigungen zu erstellen. Erwägen Sie die Verwendung von Frameworks für Wartungslösungen wie den Skripten von Ola Hallengren.

F: Soll ich die Option EXTENDED_LOGICAL_CHECKS verwenden?

A: Nur bei Verdacht auf komplexe logische Beschädigungen und entsprechendem Leistungsaufwand. Diese Option führt zusätzliche Prüfungen für indizierte Sichten, XML-Indizes und räumliche Indizes durch, erhöht jedoch die Ausführungszeit erheblich.

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