DBCC (Transact-SQL)

Verwenden eines internen Datenbanksnapshots mit DBCC

Die folgenden DBCC-Befehle werden für einen von Database Engine (Datenbankmodul) erstellten internen schreibgeschützten Datenbanksnapshot ausgeführt. Auf diese Weise werden beim Ausführen dieser Befehle Blockierungs- und Parallelitätsprobleme verhindert. Weitere Informationen finden Sie unter Datenbanksnapshots.

Wenn Sie einen dieser DBCC-Befehle ausführen, erstellt Database Engine (Datenbankmodul) einen Datenbanksnapshot und versetzt diesen hinsichtlich der Transaktionen in einen konsistenten Status. Der DBCC-Befehl führt die Überprüfungen dann auf diesem Snapshot durch. Wenn die Ausführung des DBCC-Befehls abgeschlossen ist, wird der Snapshot gelöscht.

Manchmal ist ein interner Datenbanksnapshot nicht erforderlich oder kann nicht erstellt werden. In diesem Fall wird der DBCC-Befehl für die aktuelle Datenbank ausgeführt. Wenn die Datenbank online ist, verwendet der DBCC-Befehl Tabellensperren, um die Konsistenz der zu überprüfenden Objekte sicherzustellen. Dieses Verhalten ist identisch mit der WITH TABLOCK-Option.

Es wird kein interner Datenbanksnapshot erstellt, wenn unter folgenden Bedingungen eine DBCC-Befehl ausgeführt wird:

• Der Befehl wird für die master-Datenbank ausgeführt, und die Instanz von SQL Server wird im Einzelbenutzermodus ausgeführt.

• Der Befehl wird für eine andere Datenbank als die master-Datenbank ausgeführt, aber die Datenbank wurde mit der ALTER DATABASE-Anweisung in den Einzelbenutzermodus versetzt.

• Der Befehl wird für eine schreibgeschützte Datenbank ausgeführt.

• Der Befehl wird für eine Datenbank ausgeführt, für die mithilfe der ALTER DATABASE-Anweisung der Notfallmodus festgelegt wurde.

• Der Befehl wird für die tempdb-Datenbank ausgeführt. In diesem Fall kann aufgrund interner Einschränkungen kein Datenbanksnapshot erstellt werden.

• Der Befehl wird mit der WITH TABLOCK-Option ausgeführt. In diesem Fall berücksichtigt DBCC die Anforderung und erstellt keinen Datenbanksnapshot.

Die DBCC-Befehle verwenden Tabellensperren anstelle der internen Datenbanksnapshots, wenn der Befehl für folgende Komponenten ausgeführt wird:

• Eine schreibgeschützte Dateigruppe

• Ein FAT-Dateisystem

• Ein Volume, das 'benannte Datenströme' nicht unterstützt

• Ein Volume, das 'alternative Datenströme' nicht unterstützt

Hinweis
Wird DBCC CHECKALLOC oder der entsprechende Teil von DBCC CHECKDB mithilfe der WITH TABLOCK-Option ausgeführt, muss hierfür die Datenbank exklusiv gesperrt (X) werden. Diese Datenbanksperre kann nicht für die tempdb- oder master-Datenbank festgelegt werden und erzeugt wahrscheinlich bei allen anderen Datenbanken einen Fehler.

Hinweis
Der DBCC CHECKDB-Befehl erzeugt einen Fehler, wenn er für eine master-Datenbank ausgeführt wird und kein interner Datenbanksnapshot erstellt werden kann.

Statusmeldungen für DBCC-Befehle

Die sys.dm_exec_requests-Katalogsicht enthält Informationen zum Fortschritt und zur aktuellen Ausführungsphase der Befehle DBCC CHECKDB, CHECKFILEGROUP und CHECKTABLE. Die percent_complete-Spalte zeigt den Fortschritt des Befehls in Prozent, die command-Spalte meldet die aktuelle Ausführungsphase des Befehls.

Die Definition einer Statuseinheit hängt von der aktuellen Ausführungsphase des DBCC-Befehls ab. Manchmal wird der Status mit der Granularität einer Datenbankseite angezeigt, in anderen Phasen wird er mit der Granularität einer einzelnen Datenbank oder Zuordnungsreparatur gemeldet. In der folgenden Tabelle werden die einzelnen Ausführungsphasen beschrieben sowie die Granularität, mit der der Status der Befehlsausführung gemeldet wird.

Ausführungsphase	Beschreibung	Granularität der Statusmeldungen
DBCC TABLE CHECK	Während dieser Phase wird die logische und physische Konsistenz der Objekte in der Datenbank geprüft.	Der Status wird auf Datenbankseitenebene angezeigt. Der Wert der Statusmeldung wird nach jeweils 1000 geprüften Datenbankseiten aktualisiert.
DBCC TABLE REPAIR	Während dieser Phase werden Datenbankreparaturen ausgeführt, sofern REPAIR_FAST, REPAIR_REBUILD oder REPAIR_ALLOW_DATA_LOSS angegeben ist und Objektfehler vorliegen, die behoben werden müssen.	Der Status wird auf der Ebene einzelner Reparaturvorgänge angezeigt. Der Zähler wird für jeden abgeschlossenen Reparaturvorgang aktualisiert.
DBCC ALLOC CHECK	Während dieser Phase werden Zuordnungsstrukturen in der Datenbank geprüft. Hinweis Mit DBCC CHECKALLOC werden dieselben Überprüfungen ausgeführt.	Der Status wird nicht gemeldet.
DBCC ALLOC REPAIR	Während dieser Phase werden Datenbankreparaturen ausgeführt, sofern REPAIR_FAST, REPAIR_REBUILD oder REPAIR_ALLOW_DATA_LOSS angegeben ist und Zuordnungsfehler vorliegen, die behoben werden müssen.	Der Status wird nicht angezeigt.
DBCC SYS CHECK	Während dieser Phase werden die Datenbanksystemtabellen geprüft.	Der Status wird auf Datenbankseitenebene angezeigt. Der Wert der Statusmeldung wird nach jeweils 1000 geprüften Datenbankseiten aktualisiert.
DBCC SYS REPAIR	Während dieser Phase werden Datenbankreparaturen ausgeführt, sofern REPAIR_FAST, REPAIR_REBUILD oder REPAIR_ALLOW_DATA_LOSS angegeben ist und Systemtabellenfehler vorliegen, die behoben werden müssen.	Der Status wird auf der Ebene einzelner Reparaturvorgänge angezeigt. Der Zähler wird für jeden abgeschlossenen Reparaturvorgang aktualisiert.
DBCC SSB CHECK	Während dieser Phase werden SQL Server Service Broker-Objekte geprüft. Hinweis Bei DBCC CHECKTABLE wird diese Phase nicht ausgeführt.	Der Status wird nicht angezeigt.
DBCC CHECKCATALOG	Während dieser Phase wird die Konsistenz von Datenbankkatalogen überprüft. Hinweis Bei DBCC CHECKTABLE wird diese Phase nicht ausgeführt.	Der Status wird nicht angezeigt.
DBCC IVIEW CHECK	Während dieser Phase wird die logische Konsistenz aller in der Datenbank vorhandenen indizierten Sichten geprüft.	Der Status wird auf Ebene der einzelnen geprüften Datenbanksichten gemeldet.

Informative Anweisungen

Überprüfungsanweisungen

Verwaltungsanweisungen

Sonstige Anweisungen