Tryb awaryjny SQL Server to stan EMERGENCY, umożliwiający ograniczony dostęp do uszkodzonej bazy w celu jej naprawy.
Na czym polega stan EMERGENCY w SQL Server
Tryb awaryjny SQL Server, określany w dokumentacji jako stan EMERGENCY, jest specjalnym stanem bazy danych używanym podczas odzyskiwania dostępu do bazy, która została uszkodzona albo nie może przejść prawidłowo standardowego procesu uruchamiania. Nie jest to tryb awaryjny systemu Windows ani osobny tryb uruchamiania usługi SQL Server. Dotyczy konkretnej bazy danych w ramach działającej instancji aparatu SQL Server.
Po ustawieniu bazy w stanie EMERGENCY SQL Server oznacza ją jako tylko do odczytu, wyłącza standardowe logowanie zmian i ogranicza dostęp do członków stałej roli serwerowej sysadmin. Takie ograniczenie ma zapobiegać przypadkowym modyfikacjom podczas analizy uszkodzenia. Stan ten może umożliwić odczyt części danych z krytycznych tabel, ale nie gwarantuje, że wszystkie obiekty, strony danych i zależności transakcyjne będą dostępne.
Różnica między EMERGENCY, OFFLINE i SINGLE_USER
W SQL Server stan EMERGENCY nie oznacza tego samego co OFFLINE lub SINGLE_USER. Baza w stanie OFFLINE jest wyłączona z normalnego dostępu, natomiast SINGLE_USER ogranicza liczbę jednoczesnych połączeń do jednego użytkownika. EMERGENCY opisuje przede wszystkim awaryjny stan dostępu do uszkodzonej bazy i wiąże się z ograniczeniami odczytu oraz specjalnym sposobem działania poleceń kontroli spójności.
Do ustawienia stanu awaryjnego używa się instrukcji ALTER DATABASE, na przykład ALTER DATABASE [NazwaBazy] SET EMERGENCY. Wymaga to odpowiednich uprawnień, w tym uprawnienia pozwalającego zmienić stan bazy. Jeżeli konieczne jest wykonanie operacji wymagającej wyłącznego dostępu, można dodatkowo ustawić tryb jednego użytkownika: ALTER DATABASE [NazwaBazy] SET SINGLE_USER WITH ROLLBACK IMMEDIATE. Ta operacja rozłącza aktywne sesje i może przerwać trwające transakcje, dlatego powinna być wykonywana dopiero po zabezpieczeniu dostępnych danych i ustaleniu skutków dla użytkowników.
Kontrola spójności za pomocą DBCC CHECKDB
Najważniejszym narzędziem diagnostycznym w tej sytuacji jest DBCC CHECKDB. Polecenie sprawdza między innymi spójność alokacji stron, struktur systemowych, indeksów oraz relacji między elementami bazy. Podstawowe użycie ma postać DBCC CHECKDB ([NazwaBazy]) WITH NO_INFOMSGS. Wynik należy zachować, ponieważ zawiera informacje o rodzaju wykrytych błędów oraz o minimalnym poziomie naprawy sugerowanym przez SQL Server.
W stanie EMERGENCY polecenie DBCC CHECKDB z opcją REPAIR_ALLOW_DATA_LOSS może wykonać specjalne działania odzyskiwania. SQL Server może próbować użyć stron oznaczonych jako niedostępne z powodu błędów wejścia-wyjścia lub sum kontrolnych, przeprowadzić odzyskiwanie na podstawie dziennika transakcji, a w określonych sytuacjach odbudować dziennik transakcji. Odbudowa dziennika może jednak spowodować utratę spójności transakcyjnej, dlatego samo przejście bazy do stanu EMERGENCY nie jest naprawą.
Opcja REPAIR_ALLOW_DATA_LOSS może usunąć uszkodzone strony, wiersze lub inne elementy, aby doprowadzić bazę do fizycznie spójnego stanu. Fizyczna spójność nie oznacza zachowania poprawności biznesowej danych. Po naprawie mogą wystąpić brakujące rekordy, niespójne powiązania albo utracone fragmenty transakcji. Z tego powodu Microsoft zaleca w pierwszej kolejności odtworzenie bazy z ostatniej prawidłowej kopii zapasowej. Naprawa z dopuszczeniem utraty danych jest rozwiązaniem ostatniej szansy, a nie zamiennikiem kopii zapasowej.
Bezpieczna kolejność działań po awarii bazy
Przed zmianą stanu bazy należy ustalić, czy przyczyną problemu nie są uszkodzenia nośnika, błędy systemu plików, problemy z kontrolerem, pamięcią masową lub innym elementem ścieżki wejścia-wyjścia. Jeżeli źródło uszkodzeń nadal działa, kolejna próba uruchomienia lub naprawy może pogorszyć stan danych. Warto także zabezpieczyć kopię plików bazy i dziennika oraz zebrać komunikaty z dziennika błędów SQL Server. Plików nie powinno się nadpisywać ani przenosić bez planu odzyskiwania.
Po uruchomieniu kontroli DBCC CHECKDB należy najpierw przeanalizować raport bez opcji naprawczej. Jeżeli dostępna jest prawidłowa kopia zapasowa, odtworzenie jej na sprawnym środowisku jest zwykle bezpieczniejsze niż bezpośrednia naprawa uszkodzonej bazy. Gdy odtworzenie nie jest możliwe, można rozważyć dalsze działania diagnostyczne, eksport odczytywalnych danych i dopiero później naprawę wskazaną przez raport. Po użyciu opcji naprawczych trzeba zweryfikować dane aplikacyjne oraz wykonać DBCC CHECKCONSTRAINTS, ponieważ naprawa fizycznej struktury nie sprawdza wszystkich reguł logicznych i biznesowych.
Po pomyślnym zakończeniu naprawy SQL Server może ustawić bazę z powrotem w stanie ONLINE, lecz nie oznacza to automatycznie pełnej poprawności informacji. Należy sprawdzić możliwość otwierania tabel, wykonywania zapytań, zgodność kluczowych rekordów, działanie indeksów i poprawność aplikacji korzystającej z bazy. Dopiero po takiej weryfikacji można zaplanować ponowne uruchomienie normalnego dostępu oraz wykonanie nowej kopii zapasowej. W przypadku trwałej korupcji plików lub nieudanego DBCC CHECKDB tryb EMERGENCY może nie wystarczyć do odzyskania bazy.
