Baza danych w trybie EMERGENCY

Baza danych w trybie EMERGENCY to alternatywne określenie bazy przełączonej w stan awaryjny dla celów naprawczych.

Stan EMERGENCY w SQL Server i jego przeznaczenie

„Baza danych w trybie EMERGENCY” oznacza bazę Microsoft SQL Server znajdującą się w stanie awaryjnym, ustawionym w celu wykonania czynności diagnostycznych lub naprawczych. Nie jest to osobny silnik, format pliku ani alternatywny rodzaj bazy danych, lecz wartość właściwości stanu bazy. Stan można ustawić poleceniem ALTER DATABASE, na przykład: ALTER DATABASE [NazwaBazy] SET EMERGENCY;. Operację tę może wykonać użytkownik posiadający odpowiednie uprawnienia administracyjne do instancji.

Tryb EMERGENCY należy odróżnić od automatycznych stanów RECOVERY_PENDING, SUSPECT i RECOVERING. W tych stanach SQL Server sygnalizuje konkretny problem z otwarciem bazy, odzyskiwaniem transakcji albo spójnością. EMERGENCY jest natomiast stanem ustawianym administracyjnie, zwykle wtedy, gdy standardowy dostęp do bazy nie jest możliwy lub wymaga ograniczenia. Samo przełączenie bazy do EMERGENCY nie naprawia uszkodzonych danych i nie odtwarza brakujących plików.

Jak SQL Server ogranicza dostęp w trybie awaryjnym

Po ustawieniu stanu EMERGENCY baza jest udostępniana w trybie przeznaczonym do diagnostyki. SQL Server traktuje ją jako bazę tylko do odczytu, a zapisy aplikacyjne nie powinny być kontynuowane. Dodatkowo tryb ten wiąże się z wyłączeniem standardowego mechanizmu logowania transakcji dla operacji wykonywanych w tym stanie. Nie oznacza to jednak, że można bezkarnie modyfikować dane ani że każda operacja administracyjna zakończy się powodzeniem.

W praktyce dostęp może wymagać konta należącego do roli serwerowej sysadmin. Przydatne informacje można odczytać między innymi z widoku katalogowego sys.databases, sprawdzając kolumnę state_desc, oraz z dziennika błędów SQL Server. Do oceny problemu wykorzystuje się również właściwości plików danych i dziennika transakcji, komunikaty o błędach wejścia-wyjścia oraz informacje o ostatnich próbach odzyskiwania. Zmiana stanu na EMERGENCY nie powinna być traktowana jako sposób na ominięcie kontroli dostępu dla zwykłych użytkowników.

Diagnostyka plików, metadanych i spójności

Przed podjęciem naprawy należy ustalić, czy problem dotyczy samego pliku bazy, pliku dziennika, ścieżki do plików, uprawnień systemowych, uszkodzenia nośnika czy nieudanego odzyskiwania po restarcie. Pomocne są polecenia DBCC CHECKDB oraz DBCC CHECKCATALOG, ale ich użycie powinno być poprzedzone zabezpieczeniem dostępnych kopii plików i oceną możliwości odtworzenia bazy z kopii zapasowej. Wynik DBCC CHECKDB opisuje wykryte błędy spójności stron danych, struktur alokacji, indeksów i metadanych.

Najbezpieczniejszą metodą odzyskania działania jest zwykle odtworzenie sprawnej kopii zapasowej, jeżeli taka kopia istnieje i obejmuje wymagany zakres danych. Opcje naprawcze DBCC, w szczególności REPAIR_ALLOW_DATA_LOSS, powinny być stosowane wyłącznie po analizie raportu i po ustaleniu, że odtworzenie kopii nie jest możliwe albo nie spełnia wymagań. Nazwa tej opcji wskazuje na istotne ryzyko: SQL Server może usunąć uszkodzone lub niespójne struktury, aby uzyskać formalną spójność bazy. Udane zakończenie polecenia nie gwarantuje zachowania wszystkich rekordów ani poprawności logicznej danych aplikacji.

Powrót z EMERGENCY do normalnej pracy

Po zakończeniu diagnostyki i usunięciu przyczyny awarii stan bazy należy zweryfikować, zamiast automatycznie przywracać dostęp aplikacji. W zależności od sytuacji administrator może ustawić bazę w trybie wielodostępnym poleceniem ALTER DATABASE [NazwaBazy] SET MULTI_USER;, a następnie sprawdzić jej stan, dostępność obiektów, możliwość wykonywania transakcji oraz zgodność danych z oczekiwaniami aplikacji. Jeżeli baza nadal ma błędy spójności, przełączenie jej do trybu wielodostępnego nie stanowi rozwiązania problemu.

Po naprawie warto wykonać kontrolne zapytania aplikacyjne, sprawdzić dziennik błędów SQL Server i przygotować nową kopię zapasową dopiero po potwierdzeniu poprawnego działania bazy. W przypadku komputera używanego w małej firmie lub biurze konieczne jest także rozróżnienie awarii samego SQL Server od problemu systemu Windows, dysku, kontrolera magazynu danych albo zasilania. Diagnostyka komputera powinna obejmować stan nośnika i plików systemowych, natomiast operacje na bazie wymagają zachowania procedur właściwych dla konkretnej instancji SQL Server oraz posiadania aktualnego planu odtworzenia danych.