Der Datenbankkonsolenbefehl CHECKDB (DBCC CHECKDB) wird verwendet, um die Integrität (physisch & und logisch) von Objekten in einer SQL Server-Datenbank zu prüfen Der Befehl wird in Datenbanken unterstützt, die speicheroptimierte Tabellen enthalten, aber die Validierung wird nur in festplattenbasierten Tabellen unterstützt. Die DBCC-Reparaturoption ist in speicheroptimierten Tabellen nicht verfügbar und führt daher zur Notwendigkeit einer regelmäßigen Datenbanksicherung.
Die verschiedenen Operationen, die von CHECKDB durchgeführt werden, sind:
- DBCC CHECKALLOC Ausführung auf SQL-Datenbank.
- DBCC CHECKTABLE Ausführung auf jeder Tabelle und Ansicht der SQL-Datenbank.
- DBCC CHECKCATALOG Ausführung auf SQL-Datenbank.
- Validierung des Inhalts in der indizierten Ansicht der Datenbank.
- Überprüfung der Konsistenz auf Link-Ebene zwischen den Dateiverzeichnissen und den Tabellen-Metadaten.
- Überprüfung der Service-Broker-Daten.
Da DBCC CHECKDB alle anderen Befehle ausführt, ist es nicht erforderlich, die Befehle CHECKALLOC, CHECKTABLE und CHECKCATALOG separat auszuführen.
DBCC CHECKDB Syntax
Die in der obigen Syntax verwendeten Argumente bedeuten folgendes:
database_name | database_id | 0 Dies ist der Name der Datenbank.Falls der Name nicht angegeben wird oder nur 0 geschrieben wird, wird die aktuelle Datenbank verwendet. NOINDEX Er gibt an, dass die Integritätsprüfung von nicht geclusterten Indextabellen nicht durchgeführt werden soll. Diese Syntax hat keine Auswirkungen auf die in den Tabellen befindlichen Daten. REPAIR_ALLOW_DATA_LOSS Diese Syntax repariert die in der Datenbank gefundenen Fehler, was zum Verlust einiger Daten führen kann.
Hinweis: Diese Syntax wird von Microsoft unterstützt und erweist sich nicht immer als ideale Lösung, um die Datenbank in einen guten physischen Zustand zu versetzen. Dies liegt daran, dass die gesamten Daten, die sich als beschädigt herausstellen, gelöscht werden und zu einem größeren Datenverlust führen können, als ursprünglich in der Datenbank vorhanden war, und sollte daher nur als letztes Mittel eingesetzt werden.
REPAIR_FAST Dieses Argument erhält nur die Abwärtskompatibilität aufrecht und führt keine Reparatur durch. REPAIR REBUILD Dieses Argument beinhaltet einen schnelleren Reparaturprozess, bei dem kein Datenverlust droht. ALL_ERRORMSGS Hier werden alle Fehler angezeigt, die in allen Objekten erzeugt werden. Das Ein- oder Ausschließen dieser Syntax hat keine Auswirkungen, da die Fehlermeldungen normalerweise nach der Objekt-ID sortiert werden. Die maximale Anzahl der erzeugten Fehlermeldungen kann bis zu 1000 betragen. EXTENDED_LOGICAL_CHECKS Dieses Argument führt eine logische Konsistenzprüfung für Views und Indizes durch, wenn die Kompatibilitätsebene 100 ist. NO_INFOMSGS Es werden alle Informationsmeldungen entfernt. TABLOCK Diese Syntax erhält eine exklusive Sperre für die Datenbank und erhöht die Geschwindigkeit von DBCC CHECKDB auf einer Datenbank in Zeiten hoher Last. Sie verringert jedoch die Verfügbarkeit der Datenbank für gleichzeitige Operationen. ESTIMATEONLY Hier wird der Speicherplatz angegeben oder geschätzt, den die Datenbank für die Ausführung des CHECKDB-Befehls benötigen würde. PHYSICAL_ONLY Diese Option beschränkt sich auf die Überprüfung der physischen Struktur der Datenbank. Eine kurze Overhead-Prüfung der physischen Datenbank geht mit der Erkennung von zerrissenen Seiten, Fehlern und häufigen Problemen der Benutzer einher. DATA PURITY Diese Syntax prüft auf Spaltenwerte, die entweder außerhalb des zulässigen Bereichs liegen oder nicht gültig sind. Integritätsprüfungen von Spaltenwerten sind standardmäßig aktiviert und benötigen keine DATA_PURITY-Syntax.
Zu beachtende Dinge
- Deaktivierte Indizes können nicht von DBCC CHECKDB überprüft werden.
- Die benutzerdefinierten und bytegeordneten Typen müssen serialisiert werden, wenn DBCC CHECKDB ausgeführt werden soll. In jedem anderen Fall tritt der Fehler 2537 auf.
- DBCC CHECKDB kann nicht direkt auf der Ressourcendatenbank ausgeführt werden, da sie nur im Single-Mode modifiziert werden kann.
Fehlermeldungen von DBCC CHECKDB
Wenn der CHECKDB-Befehl ausgeführt wird, wird eine Meldung in das SQL-Fehlerprotokoll geschrieben. Im Erfolgsfall wird eine Meldung über den Erfolg und die Gesamtzeit, in der der Befehl ausgeführt wurde, erzeugt. Im Falle eines Fehlers wird der Prozess aufgrund des Auftretens eines Fehlers abgebrochen, was durch eine Meldung angezeigt wird. Die verschiedenen Statuswerte, die die Fehlermeldung darstellen, sind:
Fehlerbericht
Wenn eine Beschädigung durch den CHECKDB-Befehl festgestellt wird, wird eine Dump-Datei mit dem Namen SQLDUMPNNNN.txt im Protokollverzeichnis des SQL-Servers erstellt. Falls das Feature Nutzungsdatensammlung und Fehlerberichterstattung in SQL aktiviert ist, wird der Fehlerbericht zu Verbesserungszwecken an Microsoft gesendet.
Datenbankwiederherstellung
In dem Szenario der Fehlergenerierung in SQL Server wird empfohlen, die Datenbank von der letzten erstellten Sicherung wiederherzustellen, anstatt die Datenbank zu reparieren.Falls keine Sicherung vorhanden ist, können Sie sich für die Reparaturoptionen entscheiden. Aber die Entscheidung für die Reparatur mit REPAIR_ALLOW_DATA_LOSS kann zur Löschung einiger Daten führen.
Alternative Lösung für die Wiederherstellung der Datenbank
Grundlegend prüft der Befehl DBCC CHECKDB die Konsistenzen der Datenbank, einschließlich der physischen oder logischen. Dieser Befehl überprüft die Seiten, den Index und einige andere Komponenten der SQL-Server-Datenbank, aber an einigen kritischen Punkten verweigert er die Wiederherstellung der SQL-Datenbank. Im Falle der Abwesenheit der Sicherung von MS SQL-Server-Datenbank, die opted Reparatur-Optionen können eine beträchtliche Menge an Daten zu löschen.daher, um die Datenbank wiederherzustellen, ohne Kompromisse mit der Datenintegrität, können Sie für Microsoft SQL-Datenbank Recovery-Lösung entscheiden. Sie garantieren eine vollständige Wiederherstellung der Datenbank ohne Löschen einer Menge von Daten.