Ograniczenia EMERGENCY

Tryb EMERGENCY daje odczyt uszkodzonej bazy tylko członkom roli sysadmin i służy wyłącznie do ratowania danych.

EMERGENCY jako stan awaryjny bazy SQL Server

EMERGENCY jest specjalnym stanem bazy danych w Microsoft SQL Server, używanym podczas awarii, gdy baza nie może zostać normalnie otwarta. W tym stanie baza przechodzi w tryb tylko do odczytu, jest oznaczona jako dostępna wyłącznie dla członków stałej roli serwerowej sysadmin, a jej głównym przeznaczeniem jest umożliwienie dostępu do danych potrzebnych podczas odzyskiwania. Nie jest to zwykły tryb pracy aplikacji ani sposób na obejście praw dostępu dla użytkowników.

Stan EMERGENCY może być ustawiony poleceniem ALTER DATABASE nazwa_bazy SET EMERGENCY. Sama zmiana stanu nie naprawia uszkodzeń plików danych, dziennika transakcji ani struktur systemowych. Pozwala jedynie podjąć ograniczone czynności ratunkowe, w szczególności odczytać dostępne dane i przygotować dalszą procedurę odzyskiwania. Jeżeli przyczyną problemu jest awaria dysku, brak pliku MDF lub NDF, uszkodzenie nagłówka pliku albo niespójność metadanych, EMERGENCY nie usuwa źródła problemu.

Uprawnienia i zakres odczytu

Najważniejszym ograniczeniem tego trybu jest wymóg posiadania uprawnień administratora instancji SQL Server. Dostęp do bazy w stanie EMERGENCY otrzymują członkowie roli sysadmin; zwykłe konta bazodanowe, właściciele obiektów i użytkownicy mający wybrane uprawnienia w bazie nie uzyskują automatycznie takiego dostępu. Wynika to z charakteru trybu: odczyt może odbywać się mimo tego, że normalny proces uruchamiania bazy nie zakończył się poprawnie.

EMERGENCY nie zapewnia pełnej funkcjonalności bazy. Operacje modyfikujące dane, wykonywanie transakcji, normalna obsługa aplikacji i korzystanie z bazy przez wielu użytkowników nie są celem tego stanu. Próby wykonania poleceń wymagających zapisu mogą zakończyć się błędem albo pozostawić administratora bez oczekiwanego efektu. Odczyt także może być niepełny, jeżeli uszkodzone są strony danych, indeksy, alokacja obiektów lub katalog systemowy. Wynik zapytania nie powinien być więc traktowany jako dowód, że cała baza jest spójna.

Dlaczego EMERGENCY nie zastępuje kopii zapasowej

Tryb awaryjny może pomóc w ocenie, czy z uszkodzonej bazy da się jeszcze odczytać określone tabele, ale nie zastępuje kopii zapasowej ani odtworzenia do nowej, sprawnej bazy. Przed użyciem poleceń naprawczych należy zachować kopię wszystkich dostępnych plików bazy i dziennika transakcji, ponieważ działania naprawcze mogą trwale usunąć uszkodzone lub niespójne dane. Szczególne znaczenie ma rozróżnienie między kopią plikową a poprawnym backupem wykonanym przez SQL Server: sama kopia plików nie musi być równoważna kopii zapasowej możliwej do bezpiecznego odtworzenia.

Do oceny spójności służy między innymi DBCC CHECKDB. Polecenie może wskazać uszkodzenia stron, błędy alokacji, niespójności indeksów i problemy z obiektami systemowymi. Opcja REPAIR_ALLOW_DATA_LOSS ma nazwę opisującą ryzyko dosłownie: dopuszcza naprawę kosztem możliwej utraty danych. Nie powinna być używana jako pierwszy krok, gdy istnieje poprawna kopia zapasowa. Najbezpieczniejszą kolejnością jest zwykle zabezpieczenie materiału źródłowego, analiza komunikatów DBCC CHECKDB, próba odtworzenia backupu oraz dopiero późniejsze rozważenie naprawy awaryjnej, jeśli odtworzenie nie jest możliwe.

Powrót do normalnego stanu po odzyskiwaniu

Po zakończeniu odczytu i analizy baza powinna zostać przywrócona do stanu odpowiadającego rzeczywistemu wynikowi odzyskiwania. Jeżeli struktury są poprawne i SQL Server może przeprowadzić normalne uruchomienie, administrator może użyć polecenia ALTER DATABASE nazwa_bazy SET ONLINE. Jeżeli baza nadal ma status SUSPECT, RECOVERY_PENDING albo inny stan wskazujący na nierozwiązany problem, samo przełączenie jej na ONLINE nie gwarantuje poprawności. Przed udostępnieniem bazy aplikacji trzeba sprawdzić logi SQL Server, wyniki kontroli spójności oraz możliwość odczytu krytycznych tabel.

Ograniczenia EMERGENCY mają więc charakter zarówno techniczny, jak i proceduralny. Tryb jest przeznaczony dla administratora silnika SQL Server, działa jako awaryjne okno dostępu i nie przywraca automatycznie integralności danych. W środowisku użytkowym należy unikać dalszej pracy aplikacji na bazie, dopóki nie zostanie ustalone, czy dane są kompletne i spójne. Po zakończeniu działań ratunkowych warto zweryfikować kopie zapasowe, przyczynę awarii oraz stan nośnika, na którym znajdują się pliki bazy. Odtworzenie działania usługi bez tych kontroli może jedynie ukryć problem i doprowadzić do kolejnych uszkodzeń.