DBCC CHECKDB-Strategie: letzte erfolgreiche Prüfung, Aufteilen der Arbeit, Ergebnisse deuten

Befehl

-- Last successful CHECKDB (1900-01-01 = never):
SELECT name, DATABASEPROPERTYEX(name, 'LastGoodCheckDbTime') AS last_good_checkdb
FROM   sys.databases
WHERE  state_desc = N'ONLINE' AND name <> N'tempdb'
ORDER BY last_good_checkdb;

-- Estimated tempdb requirement:
DBCC CHECKDB (N'Musteri') WITH ESTIMATEONLY;

-- Split a large DB across days: allocation + catalog + table by table CHECKTABLE
USE [Musteri];
DBCC CHECKALLOC (N'Musteri') WITH NO_INFOMSGS;
DBCC CHECKCATALOG (N'Musteri') WITH NO_INFOMSGS;
DBCC CHECKTABLE (N'dbo.Siparis') WITH NO_INFOMSGS, ALL_ERRORMSGS;

-- Get results as rows (error rows with object and page):
DBCC CHECKDB (N'Musteri') WITH TABLERESULTS, NO_INFOMSGS, ALL_ERRORMSGS, MAXDOP = 4;

Was es tut

Zeigt den Zeitpunkt des letzten erfolgreichen CHECKDB für jede Datenbank, schätzt den benötigten tempdb-Platz, lässt dich die Prüfung großer Datenbanken in CHECKALLOC + CHECKCATALOG + CHECKTABLE aufteilen und liefert die Ergebnisse als Zeilen (Objekt, Index, Seite).

Wann einsetzen

Bei der Überprüfung der Wartung, für sehr große Datenbanken, die nicht ins Wartungsfenster passen, oder um nach 823/824 das Ausmaß der Korruption zu bestimmen.

Vorsicht

Die Formulierung "repair_allow_data_loss is the minimum repair level" im Ergebnis bedeutet, dass die Reparatur Daten löscht; erwäge zuerst einen Restore aus einem guten Backup (oder einen Page Restore). Sind nur Nonclustered-Indizes (index_id > 1) betroffen, behebt Löschen und Neuanlegen des Index das Problem ohne Datenverlust. Untersuche nach dem Fund einer Korruption das Plattensubsystem. PHYSICAL_ONLY überspringt logische Prüfungen; ein vollständiges CHECKDB ist trotzdem regelmäßig nötig. Beim Aufteilen mit CHECKTABLE ist die Abdeckung unvollständig, wenn nicht auch CHECKALLOC/CHECKCATALOG laufen.