Tryb EMERGENCY

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

Tryb EMERGENCY w Microsoft SQL Server

Tryb EMERGENCY jest specjalnym stanem bazy danych Microsoft SQL Server, używanym podczas diagnostyki poważnych problemów z dostępnością lub spójnością bazy. Nie jest to zwykły tryb pracy aplikacji ani alternatywny sposób logowania użytkowników. Po ustawieniu bazy w stanie EMERGENCY SQL Server traktuje ją jako wymagającą interwencji administracyjnej. Dostęp otrzymują wyłącznie członkowie stałej roli serwerowej sysadmin, czyli konta mające najwyższy poziom uprawnień w danej instancji.

Stan można ustawić poleceniem ALTER DATABASE [NazwaBazy] SET EMERGENCY. Operacja ta nie naprawia uszkodzonych stron danych, indeksów, metadanych ani dziennika transakcji. Jej celem jest uzyskanie kontrolowanego dostępu do bazy w sytuacji, w której standardowe uruchomienie nie kończy się powodzeniem. W tym stanie baza jest oznaczana jako tylko do odczytu, dlatego próby zapisu nowych rekordów, modyfikacji istniejących danych lub wykonywania normalnych operacji aplikacyjnych mogą zakończyć się błędem.

Uprawnienia sysadmin i ograniczenia dostępu

Wymóg członkostwa w roli sysadmin ma znaczenie praktyczne i bezpieczeństwa technicznego. Nie wystarczy uprawnienie właściciela bazy, członkostwo w roli db_owner ani dostęp przyznany pojedynczym użytkownikom wewnątrz bazy. W stanie EMERGENCY SQL Server ogranicza dostęp do administratorów instancji, ponieważ odczyt może wymagać pracy na bazie o niepełnej spójności i bez gwarancji prawidłowego działania wszystkich mechanizmów systemowych.

Przed rozpoczęciem odczytu należy ustalić, czy problem dotyczy samej bazy, plików danych, pliku dziennika transakcji, systemu plików, kontrolera dyskowego czy całej instancji SQL Server. Pomocne są między innymi widoki katalogowe i komunikaty silnika, lecz ich dostępność może zależeć od rodzaju awarii. Stan bazy można sprawdzić w widoku sys.databases, odczytując kolumnę state_desc. Sam fakt ustawienia EMERGENCY nie potwierdza, że wszystkie dane są poprawne ani że każda tabela będzie możliwa do odczytania.

Odczyt danych przed próbą naprawy

Najważniejszym zastosowaniem trybu EMERGENCY jest umożliwienie odczytu danych potrzebnych do ich ratowania. Po uzyskaniu dostępu administrator może próbować odczytać konkretne tabele, wykonać zapytania selekcyjne i skopiować dostępne rekordy do innej, sprawnej bazy. W praktyce warto zaczynać od danych o najwyższym znaczeniu, ponieważ uszkodzenie może powodować błędy tylko przy odczycie określonych obiektów. Nie należy zakładać, że pomyślne wykonanie jednego zapytania oznacza pełną sprawność bazy.

Odczyt powinien być prowadzony w sposób możliwie mało obciążający uszkodzone pliki. Wyniki można eksportować do wcześniej przygotowanego miejsca, a następnie kontrolować liczbę rekordów, klucze główne, relacje i wartości krytycznych kolumn. Jeżeli dostępna jest aktualna kopia zapasowa, odtworzenie jej na oddzielnym środowisku powinno być traktowane jako podstawowy punkt odniesienia. Dane odczytane z bazy w stanie awaryjnym należy porównywać z kopią zapasową, logami aplikacji i innymi niezależnymi źródłami, ponieważ część rekordów może być niekompletna, niespójna albo niedostępna z powodu uszkodzenia stron danych.

Tryb EMERGENCY nie zastępuje kopii zapasowej i nie powinien być wykorzystywany jako sposób na obejście prawidłowego modelu uprawnień. Po zakończeniu ratowania danych należy ustalić przyczynę awarii, zabezpieczyć pliki i logi diagnostyczne oraz zaplanować odbudowę bazy. Powrót do normalnego stanu powinien nastąpić dopiero po potwierdzeniu, że struktura bazy i jej zawartość są spójne. W przeciwnym razie zmiana stanu może jedynie ukryć problem, bez usunięcia jego przyczyny.

Kontrola spójności i dalsze postępowanie

Po zabezpieczeniu możliwie dużej ilości danych można wykonać kontrolę spójności poleceniem DBCC CHECKDB. Wynik tego polecenia trzeba zachować w całości, ponieważ zawiera informacje o uszkodzonych obiektach, stronach, indeksach i strukturach wewnętrznych. W pierwszej kolejności należy rozważyć odtworzenie bazy z poprawnej kopii zapasowej. Polecenia naprawcze, w szczególności wariant REPAIR_ALLOW_DATA_LOSS, nie są neutralnym sposobem odzyskiwania. Mogą usunąć uszkodzone struktury lub dane, a ich użycie może doprowadzić do utraty informacji, której nie da się później odtworzyć.

Jeżeli nie ma użytecznej kopii zapasowej, tryb EMERGENCY może stanowić etap awaryjnego wydobywania danych, ale nie daje gwarancji odzyskania całej bazy. Każdą czynność należy dokumentować: czas wykonania, użyte polecenia, komunikaty SQL Server, zakres odczytanych tabel oraz wyniki kontroli rekordów. Przy uszkodzeniu nośnika lub plików bazy konieczne może być wcześniejsze wykonanie kopii sektorowej i praca na kopii roboczej, aby nie pogorszyć stanu oryginalnych danych. W przypadku laptopa lub komputera używanego do lokalnego uruchamiania SQL Server diagnostyka powinna obejmować również dysk, pamięć operacyjną, temperatury i stabilność zasilania.

Praca z trybem EMERGENCY wymaga doświadczenia w Microsoft SQL Server oraz ostrożnego rozdzielenia czynności odczytowych od naprawczych. Diagnostyka sprzętu, kopii plików i środowiska uruchomieniowego powinna poprzedzać działania, które mogą zmienić zawartość bazy. W zastosowaniach lokalnych, na komputerze stacjonarnym lub laptopie, najważniejsze jest najpierw zabezpieczenie dostępnych danych, a dopiero później przywracanie normalnego działania systemu.