Diagnostyka za pomocą DBCC CHECKDB to proces szczegółowej weryfikacji integralności wszystkich obiektów bazy danych.
Zakres kontroli wykonywanej przez DBCC CHECKDB
DBCC CHECKDB jest poleceniem diagnostycznym silnika Microsoft SQL Server służącym do sprawdzania spójności logicznej i fizycznej całej wskazanej bazy danych. Kontrola obejmuje między innymi strony danych, struktury alokacji, metadane systemowe, obiekty tabel, indeksy oraz zależności zapisane w katalogu systemowym. Polecenie może wykryć niespójności powstałe wskutek uszkodzenia nośnika, problemów z pamięcią masową, błędów kontrolera, nieprawidłowego działania systemu plików albo awarii występującej podczas operacji zapisu.
Wewnętrznie zakres DBCC CHECKDB odpowiada kontroli wykonywanej przez powiązane mechanizmy, takie jak DBCC CHECKALLOC, DBCC CHECKTABLE i DBCC CHECKCATALOG. Sprawdzane są między innymi mapy alokacji stron, zgodność informacji o obiektach z ich fizyczną organizacją oraz poprawność relacji między tabelami i indeksami. Wynik nie jest jednak ogólną oceną wydajności bazy. Brak komunikatu o niespójności oznacza, że przeprowadzone testy nie wykazały błędów objętych zakresem danej kontroli.
Jak interpretować komunikaty o niespójności
Rezultat DBCC CHECKDB może zawierać numer komunikatu, poziom ważności, identyfikator obiektu, numer indeksu, numer strony oraz opis wykrytego problemu. Szczególne znaczenie mają komunikaty wskazujące na błędy alokacji, błędne łańcuchy stron, niezgodność metadanych lub uszkodzone rekordy. Pojedynczy komunikat nie zawsze opisuje niezależną usterkę, ponieważ jedno uszkodzenie może powodować kolejne błędy wykrywane podczas sprawdzania zależnych struktur.
Kontrolę można uruchomić na przykład poleceniem DBCC CHECKDB (NazwaBazy) WITH NO_INFOMSGS;. Opcja NO_INFOMSGS ogranicza wyświetlanie komunikatów informacyjnych, pozostawiając komunikaty dotyczące błędów i ostrzeżeń. Do analizy konkretnego obiektu można wykorzystać DBCC CHECKTABLE, natomiast DBCC CHECKCATALOG koncentruje się na spójności metadanych katalogu bazy. Takie zawężenie ułatwia porównanie wyników, ale nie zastępuje pełnego sprawdzenia DBCC CHECKDB.
PHYSICAL_ONLY, rozszerzona kontrola i koszt operacji
Opcja PHYSICAL_ONLY ogranicza zakres do kontroli fizycznej, między innymi poprawności nagłówków stron, sum kontrolnych i podstawowej integralności struktur rekordów. Przykładowe polecenie to DBCC CHECKDB (NazwaBazy) WITH PHYSICAL_ONLY, NO_INFOMSGS;. Taki wariant jest zwykle mniej obciążający i może być używany jako częstszy test stanu nośnika, ale nie sprawdza pełnego zakresu zależności logicznych. Nie powinien więc być traktowany jako całkowity zamiennik standardowego DBCC CHECKDB.
EXTENDED_LOGICAL_CHECKS rozszerza kontrolę logiczną między innymi o określone struktury indeksowanych widoków, indeksów XML oraz indeksów przestrzennych. Ta opcja może znacząco wydłużyć działanie polecenia, szczególnie w dużych bazach. NOINDEX pozwala pominąć intensywną kontrolę nieklastrowanych indeksów użytkownika, lecz nie pomija wszystkich kontroli indeksów wewnętrznych. Czas wykonania zależy od rozmiaru bazy, liczby obiektów, szybkości pamięci masowej, obciążenia serwera i wybranego zestawu opcji.
Postępowanie po wykryciu uszkodzeń
Wykrycie niespójności powinno rozpocząć się od zabezpieczenia aktualnego stanu oraz sprawdzenia dostępnych kopii zapasowych. Najbezpieczniejszą metodą przywrócenia integralności jest odtworzenie bazy z poprawnej kopii zapasowej i wykonanie kontroli DBCC CHECKDB po zakończeniu odtwarzania. Przed próbą naprawy należy zachować kopię uszkodzonej bazy, ponieważ operacje naprawcze mogą zmienić albo usunąć część danych.
DBCC CHECKDB udostępnia opcje naprawcze, między innymi REPAIR_REBUILD i REPAIR_ALLOW_DATA_LOSS. Pierwsza może wykonać naprawy, które nie powinny powodować utraty danych, na przykład odbudowę niektórych struktur indeksowych. Druga jest trybem awaryjnym i może usuwać uszkodzone strony, rekordy lub inne elementy, dlatego jej użycie nie gwarantuje zachowania pełnej zawartości bazy. Naprawę należy wykonywać wyłącznie po ocenie raportu, kopii bezpieczeństwa i konsekwencji dla aplikacji. Po operacji trzeba ponownie uruchomić DBCC CHECKDB oraz zweryfikować działanie aplikacji i kompletność danych.
DBCC CHECKDB dotyczy konkretnego silnika Microsoft SQL Server, a jego wynik powinien być analizowany razem z dziennikiem SQL Server, historią kopii zapasowych i informacjami o stanie pamięci masowej. Sama naprawa logiczna nie usuwa przyczyny powtarzających się błędów sprzętowych. W przypadku komputerów wykorzystywanych do pracy z lokalnymi bazami i aplikacjami diagnostyka może obejmować także dysk, pamięć operacyjną, system plików oraz konfigurację środowiska, w którym działa SQL Server.
