DBCC CHECKTABLE – błędy

Błędy zwracane przez DBCC CHECKTABLE sygnalizują wykryte niespójności strukturalne w przeskanowanej pojedynczej tabeli.

Co oznaczają błędy DBCC CHECKTABLE

DBCC CHECKTABLE jest poleceniem diagnostycznym silnika Microsoft SQL Server służącym do sprawdzania spójności strukturalnej wskazanej tabeli oraz powiązanych z nią struktur indeksowych. W odróżnieniu od DBCC CHECKDB, które analizuje całą bazę danych, CHECKTABLE ogranicza zakres kontroli do jednej tabeli. Wynik zawierający błędy oznacza, że SQL Server wykrył niezgodność w danych, metadanych, stronach danych, alokacji albo indeksach związanych z analizowanym obiektem.

Komunikat DBCC nie jest zwykłym ostrzeżeniem o nieoptymalnym zapytaniu ani informacją o braku indeksu. Może wskazywać na uszkodzenie logiczne, gdy relacje między stronami, rekordami, kluczami indeksu i metadanymi nie odpowiadają regułom obowiązującym w SQL Server. Może również oznaczać problem fizyczny, na przykład błędny odczyt strony danych z nośnika, nieprawidłową sumę kontrolną strony albo uszkodzenie fragmentu pliku bazy danych. Sam tekst komunikatu trzeba interpretować razem z numerem błędu, identyfikatorem obiektu, numerem strony i nazwą indeksu, jeżeli takie informacje zostały zwrócone.

Zakres kontroli pojedynczej tabeli w SQL Server

Podczas działania DBCC CHECKTABLE SQL Server sprawdza tabelę zgodnie z jej sposobem przechowywania i strukturą. Kontrola może obejmować strony danych, łańcuchy rekordów, przypisanie stron do obiektu, zgodność wierszy z metadanymi oraz relacje między tabelą a indeksami. W przypadku tabel partycjonowanych analizowane są także struktury związane z partycjami. Zakres i szczegóły raportu zależą od rodzaju obiektu oraz wersji używanego SQL Server, dlatego komunikat należy odnosić do konkretnej tabeli, a nie traktować jako ogólnej diagnozy całej instancji.

Do identyfikacji obiektu można użyć nazwy tabeli lub jej identyfikatora. W praktyce administrator może wykonać kontrolę w formie DBCC CHECKTABLE ('schema.table'), a opcje takie jak NO_INFOMSGS ograniczają liczbę komunikatów informacyjnych. ALL_ERRORMSGS pozwala zażądać raportowania wszystkich dostępnych komunikatów o błędach, a nie tylko ograniczonej liczby pierwszych wyników. Opcje te zmieniają sposób prezentacji raportu i nie naprawiają danych. Przed analizą trzeba upewnić się, że polecenie dotyczy właściwej bazy, schematu i tabeli.

Interpretacja raportu i ustalenie źródła niespójności

Najważniejsze jest zachowanie pełnego wyniku polecenia. Liczy się nie tylko końcowy komunikat o liczbie błędów, ale również wskazanie obiektu, indeksu, identyfikatora alokacji, numeru strony oraz rodzaju naruszonej reguły. Powtarzające się błędy odczytu lub problemy z konkretnymi stronami mogą wskazywać na awarię podsystemu pamięci masowej, kontrolera, połączenia z dyskiem albo uszkodzenie pliku. Błędy ograniczone do indeksu mogą mieć inny zakres niż niespójności dotyczące stron danych tabeli, jednak nie wolno zakładać z góry, że każdą taką sytuację można bezpiecznie rozwiązać przez przebudowę indeksu.

Wynik CHECKTABLE warto porównać z raportem DBCC CHECKDB dla całej bazy, dziennikiem SQL Server, dziennikiem systemowym oraz informacjami o stanie dysków i kopiach zapasowych. Jeżeli wystąpiły błędy 823, 824 lub 825, szczególną uwagę zwraca się na problemy wejścia-wyjścia i powtarzające się ostrzeżenia o odczycie stron. Nie powinno się usuwać ani nadpisywać plików bazy w celu ukrycia komunikatu. Najpierw należy zabezpieczyć kopię bieżącego stanu, ustalić moment pojawienia się niespójności i sprawdzić, czy istnieje poprawna kopia zapasowa pozwalająca odtworzyć dane.

Naprawa uszkodzonej tabeli a odzyskanie danych

Najbezpieczniejszą metodą usunięcia niespójności jest zwykle odtworzenie bazy albo odpowiednich danych z kopii zapasowej, która została zweryfikowana pod kątem poprawności. Naprawa bez odtwarzania wymaga dobrania działania do rodzaju błędu. DBCC CHECKTABLE udostępnia między innymi opcje REPAIR_FAST, REPAIR_REBUILD i REPAIR_ALLOW_DATA_LOSS, ale ich zastosowanie nie jest równoważne. REPAIR_ALLOW_DATA_LOSS może usunąć uszkodzone lub niespójne elementy, aby przywrócić spójność struktur, co oznacza ryzyko utraty części rekordów, stron albo relacji logicznych. Nie jest to metoda gwarantująca zachowanie wszystkich danych.

Opcje naprawcze powinny być używane wyłącznie po analizie raportu, w kontrolowanym oknie serwisowym i po wykonaniu kopii stanu bazy. Po naprawie należy ponownie uruchomić odpowiednią kontrolę DBCC, sprawdzić działanie zapytań, integralność indeksów oraz kompletność danych aplikacji. Jeżeli przyczyną był problem sprzętowy lub z systemem plików, sama naprawa tabeli nie usuwa źródła awarii i niespójność może powrócić. Diagnostyka i naprawa wymagają więc jednoczesnej oceny bazy SQL Server, plików danych, dziennika transakcji, kopii zapasowych oraz warstwy pamięci masowej.