Baza danych w stanie SUSPECT

Baza danych w stanie SUSPECT to baza oznaczona przez silnik jako uszkodzona i niedostępna do standardowego użytku.

Co oznacza stan SUSPECT w SQL Server

Stan SUSPECT w systemie Microsoft SQL Server oznacza, że aparat bazy danych nie zdołał poprawnie zakończyć procedury odzyskiwania podczas uruchamiania bazy albo wykrył problem uniemożliwiający jej bezpieczne udostępnienie. Baza pozostaje zarejestrowana w instancji, ale nie przechodzi do stanu ONLINE. Standardowe zapytania do jej tabel nie powinny być wtedy wykonywane, ponieważ silnik traktuje spójność danych lub możliwość odtworzenia transakcji jako niewystarczającą do normalnej pracy.

Nie jest to zwykły błąd logowania użytkownika ani informacja o braku uprawnień. Status opisuje stan całej bazy w metadanych SQL Server. Może pojawić się po awarii systemu operacyjnego, zaniku zasilania, niedostępności pliku danych lub pliku dziennika transakcji, błędach podsystemu dyskowego, uszkodzeniu stron danych albo nieudanej operacji odzyskiwania. Sam napis SUSPECT nie wskazuje jeszcze konkretnej przyczyny. Do ustalenia źródła problemu potrzebne są komunikaty z dziennika błędów SQL Server, dziennika systemowego oraz informacje o dostępności plików bazy.

Odzyskiwanie po nieudanym uruchomieniu bazy

Po ponownym uruchomieniu instancji SQL Server silnik wykonuje recovery, czyli odzyskiwanie bazy na podstawie dziennika transakcji. Proces obejmuje analizę punktu kontrolnego, ponowne wykonanie zatwierdzonych operacji oraz wycofanie zmian należących do transakcji, które nie zostały zatwierdzone. Jeżeli plik dziennika jest uszkodzony, brakuje wymaganych fragmentów, plik danych nie jest dostępny albo struktury wewnętrzne nie pozwalają na bezpieczne odtworzenie stanu, baza może pozostać w stanie SUSPECT.

W pierwszej kolejności należy ustalić, czy problem dotyczy logicznej spójności bazy, czy warstwy przechowywania plików. Sprawdza się ścieżki i rozmiary plików MDF, NDF oraz LDF, dostępność woluminów, błędy wejścia-wyjścia i uprawnienia konta usługi SQL Server. Należy również odczytać komunikaty z SQL Server Error Log, ponieważ numery błędów i treść wpisów często rozróżniają brak pliku, błąd odczytu, niewystarczające miejsce, uszkodzony nagłówek pliku oraz nieudaną fazę odzyskiwania. Zmiana statusu za pomocą przypadkowych poleceń nie usuwa przyczyny i może utrudnić późniejsze odzyskanie danych.

CHECKDB, kopia zapasowa i ryzyko naprawy

Podstawowym narzędziem oceny spójności jest polecenie DBCC CHECKDB. Wykonuje ono kontrole przydziału stron, struktur systemowych, relacji między stronami, indeksów oraz spójności logicznej obiektów. Wynik powinien być zapisany i przeanalizowany przed podjęciem decyzji o naprawie. Jeżeli baza nie jest dostępna w trybie pozwalającym na wykonanie kontroli, stosuje się procedurę awaryjną opartą na zmianie stanu dostępu, na przykład EMERGENCY, jednak nie jest to naprawa i nie powinno być traktowane jako rozwiązanie problemu.

Najbezpieczniejszym sposobem odzyskania sprawnej bazy jest przywrócenie odpowiedniej kopii zapasowej: pełnej, różnicowej oraz wymaganych kopii dziennika transakcji, zgodnie z rzeczywistym łańcuchem backupów. Przywrócenie powinno być poprzedzone identyfikacją punktu, do którego można zaakceptować utratę zmian. Jeżeli kopia zapasowa nie istnieje albo nie można jej użyć, SQL Server może raportować zalecaną opcję naprawy przez DBCC CHECKDB, na przykład REPAIR_ALLOW_DATA_LOSS. Nazwa tej opcji jest istotna: naprawa może usuwać uszkodzone lub niespójne elementy, a więc doprowadzić do utraty tabel, wierszy, stron albo innych fragmentów danych.

Przed operacją naprawczą należy zabezpieczyć kopię plików i ustalić, czy możliwe jest odtworzenie bazy w osobnej instancji lub na innym nośniku. Tryb SINGLE_USER może być wymagany, aby zapewnić wyłączny dostęp do bazy, lecz aktywne połączenia aplikacji, zadania agenta SQL Server i narzędzia monitorujące mogą przejąć jedyną sesję. Dlatego kolejność działań ma znaczenie. Po ewentualnej naprawie trzeba ponownie uruchomić kontrolę DBCC CHECKDB, sprawdzić kluczowe obiekty oraz porównać dane z dostępnymi źródłami. Usunięcie statusu SUSPECT bez potwierdzenia spójności nie oznacza odzyskania poprawnej bazy.

Diagnostyka i dalsze postępowanie techniczne

Ocena bazy w stanie SUSPECT powinna obejmować pełny łańcuch zależności: instancję SQL Server, pliki bazy, wolumin, kontroler lub macierz, system plików oraz mechanizm kopii zapasowych. Warto sprawdzić, czy w tym samym czasie wystąpiły błędy dysku, reset urządzenia, przepełnienie woluminu albo zatrzymanie usługi. Szczególnej ostrożności wymaga sytuacja, w której pliki są przechowywane na niestabilnym nośniku. Wielokrotne uruchamianie bazy i powtarzanie operacji zapisu może wtedy zwiększyć zakres uszkodzeń.

Jeżeli istnieje aktualna i sprawdzona kopia zapasowa, odtworzenie jej w kontrolowany sposób zwykle daje lepszą podstawę do dalszej pracy niż doraźna naprawa struktury. Po przywróceniu należy zweryfikować wynik kontroli spójności, działanie aplikacji oraz kompletność danych z okresu obejmowanego przez kopię. Gdy kopia jest niepełna, uszkodzenie dotyczy dziennika albo odzyskiwanie kończy się błędem, potrzebna jest analiza komunikatów SQL Server i stanu nośnika przez osobę posiadającą dostęp do instancji oraz systemu przechowywania. Baza SUSPECT jest sygnałem awarii procesu odzyskiwania, a nie samodzielną diagnozą; właściwe postępowanie zależy od ustalonej przyczyny i dostępnych kopii zapasowych.