Błąd DBCC CHECKDB

Błąd DBCC CHECKDB sygnalizuje wykrycie niespójności strukturalnej podczas weryfikacji integralności bazy danych.

Jak DBCC CHECKDB wykrywa niespójność w SQL Server

DBCC CHECKDB to polecenie diagnostyczne aparatu Microsoft SQL Server służące do sprawdzania logicznej i fizycznej integralności obiektów znajdujących się w bazie danych. Weryfikacja obejmuje między innymi strony danych, alokację przestrzeni, metadane, indeksy, relacje między obiektami oraz zgodność struktur systemowych. Komunikat o błędzie oznacza, że SQL Server znalazł różnicę pomiędzy oczekiwanym stanem struktury a stanem zapisanym w plikach bazy. Nie jest to zwykłe ostrzeżenie dotyczące wydajności ani informacja o nieoptymalnym zapytaniu.

Wynik DBCC CHECKDB może zawierać numer komunikatu, poziom ważności, stan, nazwę obiektu, identyfikator strony lub identyfikator rekordu. Takie szczegóły są istotne, ponieważ wskazują, czy problem dotyczy alokacji stron, tabeli, indeksu, metadanych czy samego pliku bazy. Błąd może być skutkiem uszkodzenia zapisu na nośniku, awarii zasilania, problemu z pamięcią lub kontrolerem dysku, nieprawidłowego działania systemu plików albo wcześniejszego uszkodzenia pliku MDF, NDF lub LDF. Sam komunikat DBCC nie przesądza jeszcze, która z tych przyczyn wystąpiła.

Różnica między uszkodzonym indeksem a uszkodzeniem danych

Nie każda niespójność ma taki sam wpływ na bazę. Jeżeli DBCC CHECKDB wskazuje wyłącznie nieklastrowany indeks, podstawowym rozwiązaniem może być odbudowa albo odtworzenie tego indeksu. Indeks nieklastrowany jest dodatkową strukturą służącą do wyszukiwania danych, dlatego jego uszkodzenie nie musi oznaczać utraty wierszy przechowywanych w tabeli. Inaczej należy traktować błędy dotyczące indeksu klastrowanego, stron danych, alokacji lub tabel systemowych, ponieważ indeks klastrowany określa fizyczną organizację danych tabeli.

Szczególnie istotne są komunikaty dotyczące błędów alokacji, niespójnych metadanych oraz stron oznaczonych jako uszkodzone. Problemy tego typu mogą powodować niepełne wyniki zapytań, błędy odczytu, nieudane operacje aktualizacji, zatrzymanie przywracania kopii zapasowej albo nieprawidłowe działanie aplikacji korzystającej z SQL Server. Brak błędu podczas otwierania bazy przez aplikację nie dowodzi jej integralności, ponieważ uszkodzona strona może nie zostać jeszcze odczytana przez konkretny fragment systemu.

Bezpieczna kolejność czynności po wykryciu błędu

Po otrzymaniu wyniku DBCC CHECKDB należy zachować pełny raport, wraz z numerami komunikatów, nazwami obiektów i informacją o czasie wykonania badania. Warto również sprawdzić dziennik SQL Server oraz dziennik systemowy Windows pod kątem błędów wejścia-wyjścia, komunikatów sterownika dysku i problemów z systemem plików. Jeżeli występują błędy odczytu lub zapisu, samo wykonanie ponownego CHECKDB nie usuwa przyczyny. Najpierw trzeba ustalić, czy pliki bazy znajdują się na stabilnym nośniku i czy możliwe jest wykonanie kopii bezpieczeństwa.

Preferowaną metodą odzyskania poprawnego stanu jest odtworzenie bazy z wiarygodnej kopii zapasowej, poprzedzone analizą jej kompletności i aktualności. Polecenie DBCC CHECKDB (NazwaBazy) WITH NO_INFOMSGS, ALL_ERRORMSGS może pomóc w uzyskaniu pełniejszego wyniku diagnostycznego, ale nie naprawia uszkodzeń. Opcje naprawcze, takie jak REPAIR_REBUILD i REPAIR_ALLOW_DATA_LOSS, mają inne znaczenie. Pierwsza może przebudować niektóre struktury, natomiast druga może usunąć uszkodzone strony, wiersze lub inne elementy, aby doprowadzić bazę do stanu, w którym SQL Server będzie mógł ją otworzyć. Nazwa REPAIR_ALLOW_DATA_LOSS wskazuje na rzeczywiste ryzyko utraty danych, dlatego nie powinna być traktowana jako bezpieczny zamiennik odtworzenia kopii.

Przed decyzją o naprawie należy ustalić, czy problem można odtworzyć na kopii bazy, jakie obiekty są uszkodzone oraz czy aplikacja może działać bez części danych. Po każdej operacji naprawczej trzeba ponownie uruchomić DBCC CHECKDB i porównać wyniki. Poprawny komunikat końcowy nie oznacza automatycznie, że brakujące lub zmienione dane zostały odzyskane. Naprawa struktury może jedynie usunąć przeszkodę uniemożliwiającą dalszą pracę silnika.

Wpływ błędu na dalszą pracę komputera i aplikacji

Błąd DBCC CHECKDB dotyczy konkretnego silnika SQL Server, a nie ogólnej kategorii baz danych. Dlatego diagnostyka powinna uwzględniać wersję SQL Server, typ plików bazy, sposób przechowywania danych oraz mechanizm wykonywania kopii zapasowych właściwy dla tego środowiska. Nie należy przenosić na SQL Server poleceń ani procedur charakterystycznych dla PostgreSQL, MySQL lub Oracle. Również komunikat o naprawie powinien być interpretowany razem z dokumentacją konkretnej wersji SQL Server i pełnym raportem DBCC.

Na komputerze użytkownika objawem problemu może być wolne działanie programu, błędy zapisu, niemożność otwarcia dokumentów albo komunikat aplikacji informujący o utracie połączenia z bazą. Objawy te nie identyfikują jednak samego uszkodzenia. Należy odróżnić błąd integralności bazy od awarii usługi SQL Server, niedostępności udziału sieciowego, braku miejsca na dysku, uszkodzenia systemu plików i błędu konfiguracji połączenia. Dopiero zestawienie logów aplikacji, dziennika SQL Server, stanu dysku i raportu DBCC pozwala ocenić, czy problem znajduje się w danych, nośniku czy warstwie komunikacji.

W przypadku komputera, na którym działa aplikacja zależna od SQL Server, diagnostyka sprzętowa może obejmować stan dysku, pamięć operacyjną, temperatury, zasilanie i stabilność systemu. Wnioski dotyczące samej bazy SQL Server powinny wynikać z raportów tego silnika, kopii zapasowych oraz analizy środowiska, w którym baza jest uruchomiona.