Baza w stanie EMERGENCY widoczna w sys.databases wymaga naprawy przed przywróceniem normalnej dostępności.
Co oznacza EMERGENCY w widoku sys.databases
W Microsoft SQL Server kolumna state_desc w widoku katalogowym sys.databases opisuje bieżący stan bazy danych. Wartość EMERGENCY oznacza tryb awaryjny, który może zostać ustawiony przez administratora poleceniem ALTER DATABASE ... SET EMERGENCY. Nie jest to zwykły stan gotowości do pracy ani potwierdzenie, że baza została naprawiona. Tryb ten służy do ograniczonego dostępu diagnostycznego, gdy normalne otwarcie bazy nie jest możliwe albo baza wymaga sprawdzenia pod kątem uszkodzeń.
Po przejściu w stan EMERGENCY baza jest dostępna w trybie tylko do odczytu, a dostęp do niej jest ograniczony do członków stałej roli serwera sysadmin. Z tego powodu użytkownik aplikacji może nadal otrzymywać błędy połączenia lub komunikaty o niedostępności danych. Sam wpis w sys.databases nie wskazuje jeszcze dokładnej przyczyny problemu. Przyczyną może być między innymi uszkodzenie plików bazy, nieudana procedura odzyskiwania po awarii, problem z plikiem dziennika transakcji albo ręczne ustawienie trybu awaryjnego podczas diagnostyki.
Odczyt stanu bazy i odróżnienie EMERGENCY od innych stanów
Podstawową kontrolę można wykonać zapytaniem:
SELECT name, state, state_desc, user_access_desc, is_read_only, recovery_model_desc FROM sys.databases WHERE name = N'Naz waBazy';
W praktycznym zapytaniu należy oczywiście zastąpić przykładową nazwę rzeczywistą nazwą bazy. Kolumna state zawiera wartość liczbową, natomiast state_desc jej opis tekstowy. Warto sprawdzić również user_access_desc, ponieważ ograniczenie dostępu może wynikać z ustawienia SINGLE_USER lub RESTRICTED_USER, a nie wyłącznie z samego stanu awaryjnego. is_read_only pomaga potwierdzić, że baza nie przyjmuje zwykłych operacji modyfikujących dane.
EMERGENCY należy odróżnić od stanów SUSPECT i RECOVERY_PENDING. Stan SUSPECT oznacza, że podczas uruchamiania lub odzyskiwania SQL Server wykrył problem, przez który baza nie może zostać poprawnie otwarta. RECOVERY_PENDING wskazuje, że odzyskiwanie powinno się rozpocząć, ale wystąpiła przeszkoda, na przykład brak pliku, brak zasobów lub problem z dostępem do plików. EMERGENCY jest natomiast specjalnym trybem administracyjnym i nie powinien być traktowany jako automatyczna diagnoza konkretnego uszkodzenia.
Kontrola integralności przed próbą przywrócenia dostępności
Po potwierdzeniu stanu EMERGENCY należy zebrać informacje z dziennika SQL Server oraz wykonać kontrolę integralności poleceniem DBCC CHECKDB. Przykładowa forma diagnostyczna to:
DBCC CHECKDB (N'Na zwaBazy') WITH NO_INFOMSGS, ALL_ERRORMSGS;
DBCC CHECKDB sprawdza między innymi spójność stron danych, struktur alokacji, tabel, indeksów i zależności wewnętrznych bazy. Wynik trzeba zapisać w całości, ponieważ komunikaty mogą wskazywać konkretny numer błędu, obiekt, identyfikator strony lub zalecany poziom naprawy. Opcja NO_INFOMSGS ogranicza komunikaty informacyjne, a ALL_ERRORMSGS pozwala uzyskać pełniejszą listę wykrytych błędów. Brak komunikatów o błędach integralności nie oznacza, że można bez sprawdzenia usunąć kopie bezpieczeństwa lub pominąć analizę dziennika.
Najbezpieczniejszą drogą odzyskania bazy jest przywrócenie poprawnej kopii zapasowej, jeżeli taka kopia istnieje i jest możliwa do użycia. Polecenia naprawcze DBCC CHECKDB z opcjami REPAIR_REBUILD albo REPAIR_ALLOW_DATA_LOSS mają inne znaczenie. Pierwsza opcja może odbudować niektóre struktury, natomiast druga może usunąć uszkodzone dane lub obiekty w celu uzyskania spójności. REPAIR_ALLOW_DATA_LOSS nie jest zamiennikiem kopii zapasowej ani gwarancją odzyskania wszystkich rekordów. Jej użycie powinno nastąpić dopiero po ocenie wyniku CHECKDB, zabezpieczeniu dostępnych plików i zaakceptowaniu ryzyka utraty danych.
Powrót z trybu awaryjnego do normalnej pracy SQL Server
Jeżeli kontrola integralności nie wykazała problemów, a przyczyna ustawienia trybu awaryjnego została usunięta, administrator może przywrócić bazę do trybu wielodostępnego i odczytu-zapisu. Stosuje się do tego odpowiednio polecenia:
ALTER DATABASE [NazwaBazy] SET ONLINE;
ALTER DATABASE [NazwaBazy] SET READ_WRITE;
ALTER DATABASE [NazwaBazy] SET MULTI_USER;
Nie należy wykonywać tych poleceń mechanicznie tylko dlatego, że w sys.databases pojawiła się wartość EMERGENCY. Jeżeli baza pozostaje uszkodzona, wymuszenie stanu ONLINE może zakończyć się ponownym przejściem do SUSPECT albo nieprawidłowym działaniem aplikacji. Po zmianie stanu trzeba ponownie odczytać state_desc, is_read_only i user_access_desc, a następnie uruchomić testowe zapytania odczytujące dane z kluczowych tabel. Należy także sprawdzić, czy aplikacja może ustanowić połączenie i czy nie występują nowe błędy w dzienniku SQL Server.
Jeżeli baza nie wraca do normalnego stanu, dalsze działania powinny obejmować analizę plików danych i dziennika, dostępności ścieżek, uprawnień konta usługi SQL Server oraz poprawności kopii zapasowych. W przypadku istotnych danych właściwym rozwiązaniem może być odtworzenie pełnej kopii bazy, a następnie odpowiednich kopii różnicowych i dzienników transakcji. Tryb EMERGENCY należy traktować jako etap kontrolowany przez administratora silnika SQL Server, a nie jako trwały sposób udostępniania bazy użytkownikom.
