DBCC CHECKDB – błędy

Błędy zwracane przez DBCC CHECKDB sygnalizują wykryte niespójności strukturalne w przeskanowanej bazie danych.

Co oznacza komunikat DBCC CHECKDB

DBCC CHECKDB jest poleceniem diagnostycznym silnika Microsoft SQL Server służącym do sprawdzania spójności fizycznej i logicznej bazy danych. Błąd zwrócony przez to polecenie oznacza, że podczas kontroli wykryto nieprawidłowość w strukturach plików bazy, stronach danych, indeksach, alokacji miejsca albo relacjach między obiektami. Nie jest to ogólny komunikat o niedostępności serwera, lecz wynik konkretnej kontroli integralności wybranej bazy.

Zakres problemu zależy od treści komunikatu. DBCC CHECKDB może zgłosić między innymi błędne identyfikatory stron, niezgodność map alokacji, uszkodzone rekordy, problemy z metadanymi tabeli lub niespójność indeksu. Część błędów dotyczy wyłącznie indeksu i może być możliwa do usunięcia przez jego odbudowę, ale komunikaty odnoszące się do stron danych, systemowych metadanych albo alokacji wymagają ostrożniejszej analizy.

Jak SQL Server wykrywa niespójność

Kontrola DBCC CHECKDB obejmuje kilka powiązanych mechanizmów. SQL Server sprawdza między innymi poprawność alokacji stron, zgodność struktur systemowych, relacje między stronami danych i indeksów oraz integralność obiektów w bazie. W praktyce oznacza to porównywanie informacji zapisanych w różnych strukturach wewnętrznych, a nie tylko odczyt pojedynczego pliku z dysku. Dlatego wynik może wskazywać zarówno na fizyczne uszkodzenie strony, jak i na logiczną niezgodność zapisanych informacji.

W komunikacie istotne są numer błędu DBCC, poziom ważności, nazwa obiektu, identyfikator obiektu, numer strony oraz zalecenie naprawy. Numery stron w SQL Server są zwykle prezentowane jako kombinacja identyfikatora pliku i numeru strony. Informacja o tabeli lub indeksie pomaga ustalić, czy problem obejmuje dane użytkowe, strukturę pomocniczą, czy elementy systemowe. Sam fakt, że polecenie zakończyło się błędem, nie określa jeszcze, czy można bezpiecznie zastosować automatyczną naprawę.

Interpretacja opcji naprawczych i kopii zapasowej

Podstawową czynnością po wykryciu niespójności jest zabezpieczenie istniejących danych oraz sprawdzenie dostępnych kopii zapasowych. Jeżeli baza jest objęta prawidłową strategią backupu, odtworzenie sprawdzonej kopii często pozwala zachować pełniejsze dane niż próba usunięcia uszkodzeń przez mechanizmy naprawcze. Przed zmianami należy także ustalić, czy problem nie wynika z błędów systemu pamięci masowej, kontrolera, pamięci RAM, systemu plików albo nagłego przerwania operacji wejścia-wyjścia.

DBCC CHECKDB może w określonych przypadkach zasugerować użycie opcji REPAIR_ALLOW_DATA_LOSS. Nazwa tej opcji ma znaczenie praktyczne: naprawa może doprowadzić do usunięcia uszkodzonych wierszy, stron lub innych elementów, więc nie jest równoważna bezstratnemu odtworzeniu. Opcje naprawcze powinny być traktowane jako rozwiązanie awaryjne, wykonywane po analizie raportu i najlepiej na kopii bazy lub w kontrolowanym środowisku. Nie należy uruchamiać polecenia naprawczego wyłącznie dlatego, że zostało wymienione w końcowej części komunikatu.

W zależności od rodzaju uszkodzenia można rozważyć odbudowę indeksów, ponowne utworzenie obiektów, odtworzenie bazy z backupu albo skopiowanie poprawnych danych do nowej bazy. Każda z tych metod ma inny zakres skutków. Odbudowa indeksu może pomóc przy uszkodzeniu struktury indeksowej, lecz nie naprawi uszkodzonych danych przechowywanych w tabeli. Z kolei kopiowanie danych może wymagać pominięcia rekordów, których nie da się odczytać, dlatego po takiej operacji konieczne jest porównanie schematu, liczby danych i zależności między obiektami.

Postępowanie po zakończeniu kontroli

Po uzyskaniu raportu DBCC CHECKDB należy zachować pełny wynik polecenia, a nie tylko ostatnią linię z komunikatem o powodzeniu lub błędzie. Raport powinien zostać zestawiony z dziennikiem SQL Server, dziennikiem systemowym oraz informacjami o stanie dysków i kontrolera. Jeżeli błędy pojawiają się ponownie po odtworzeniu lub odbudowie struktur, wskazuje to na problem, który może nadal powodować uszkodzenia. Jednorazowe usunięcie objawu bez sprawdzenia warstwy sprzętowej nie daje pewności stabilności bazy.

Kontrolę warto wykonywać w sposób zaplanowany, z uwzględnieniem obciążenia serwera i rozmiaru bazy. DBCC CHECKDB może zużywać znaczące zasoby procesora, pamięci oraz operacji wejścia-wyjścia, a czas działania zależy między innymi od wielkości i struktury bazy. Wynik prawidłowej kontroli nie potwierdza sprawności całego komputera, lecz informuje, że w badanym momencie SQL Server nie wykrył niespójności objętych zakresem tego polecenia. W przypadku powtarzających się błędów potrzebna jest analiza całego łańcucha: nośnika danych, systemu operacyjnego, instancji SQL Server, kopii zapasowych oraz samej bazy.

Przy diagnostyce należy rozdzielić błąd DBCC CHECKDB od błędów aplikacji korzystającej z bazy. Aplikacja może zgłaszać niepoprawne wyniki zapytań, przerwane transakcje lub problemy z połączeniem, mimo że integralność struktur bazy jest prawidłowa. Z drugiej strony uszkodzona baza może powodować błędy widoczne dopiero w konkretnym module programu. Rzetelna ocena wymaga więc powiązania komunikatu DBCC z obiektem, czasem wystąpienia i rzeczywistym zachowaniem systemu.