W trybie EMERGENCY dopuszczalne są odczyty oraz naprawa poleceniem DBCC CHECKDB z opcją dopuszczającą utratę danych.
Znaczenie trybu EMERGENCY w SQL Server
EMERGENCY to specjalny stan bazy danych Microsoft SQL Server używany podczas awarii, gdy normalny dostęp do bazy nie jest możliwy albo baza znajduje się w stanie podejrzanym, na przykład SUSPECT. Ustawienie tego trybu wykonuje się poleceniem ALTER DATABASE [NazwaBazy] SET EMERGENCY. Nie jest to zwykły tryb pracy ani metoda poprawy wydajności. Jego celem jest uzyskanie ograniczonego dostępu administracyjnego do bazy i przeprowadzenie czynności ratunkowych.
W stanie EMERGENCY baza jest traktowana jako tylko do odczytu, a dostęp do niej zostaje ograniczony do członków stałej roli serwerowej sysadmin. Wyłączenie rejestrowania operacji w dzienniku transakcji ma umożliwić wykonanie awaryjnych czynności nawet wtedy, gdy dziennik jest uszkodzony lub nie może zostać poprawnie otwarty. Oznacza to jednak, że tryb ten nie zapewnia normalnych właściwości transakcyjnych i nie powinien być używany do bieżącej pracy aplikacji.
Odczyt danych i rozpoznanie uszkodzeń
Podstawową czynnością w trybie EMERGENCY jest odczyt dostępnych informacji diagnostycznych. Administrator może sprawdzić stan bazy w widokach katalogowych, między innymi przez sys.databases, oraz przeanalizować komunikaty zapisane przez aparat SQL Server. Możliwy zakres odczytu zależy od stopnia uszkodzenia plików danych, stron bazodanowych i metadanych. Samo ustawienie EMERGENCY nie naprawia tabel, indeksów ani struktur systemowych.
Kontrolę spójności wykonuje się poleceniem DBCC CHECKDB, na przykład DBCC CHECKDB (N'NazwaBazy') WITH NO_INFOMSGS, ALL_ERRORMSGS. Polecenie sprawdza logiczną i fizyczną spójność obiektów bazy, w tym stron danych, alokacji, indeksów, relacji między strukturami oraz wybranych elementów metadanych. Wynik należy zachować w całości, ponieważ komunikaty DBCC wskazują rodzaj wykrytych problemów i mogą zawierać zalecany poziom naprawy. Odczyt danych przed naprawą jest ważny także po to, aby ustalić, które tabele lub obiekty są jeszcze dostępne.
DBCC CHECKDB z REPAIR_ALLOW_DATA_LOSS
W sytuacji, w której nie ma dostępnej poprawnej kopii zapasowej, SQL Server może wskazać użycie opcji REPAIR_ALLOW_DATA_LOSS. Przykładowa składnia wygląda następująco: DBCC CHECKDB (N'NazwaBazy', REPAIR_ALLOW_DATA_LOSS). Nazwa tej opcji opisuje jej najważniejszą konsekwencję: naprawa może usunąć uszkodzone strony, rekordy, wiersze indeksów albo inne elementy, których nie da się bezpiecznie odtworzyć. Polecenie może doprowadzić do uzyskania spójności technicznej bazy, ale nie gwarantuje zachowania wszystkich danych ani pełnej zgodności logicznej aplikacji.
Przed uruchomieniem naprawy należy wykonać kopię plików bazy, o ile są dostępne, oraz zabezpieczyć każdy możliwy eksport danych. Trzeba także sprawdzić, czy możliwe jest odtworzenie bazy z kopii pełnej, różnicowej lub dziennika transakcji. Przywrócenie poprawnej kopii jest zwykle bezpieczniejszym sposobem odzyskania danych niż naprawa dopuszczająca ich utratę. Jeżeli naprawa jest jedyną dostępną drogą, wynik DBCC trzeba zapisać, a następnie przeprowadzić dodatkowe kontrole tabel, kluczy, indeksów i działania aplikacji.
Wykonanie polecenia naprawczego może wymagać ustawienia bazy w tryb pojedynczego użytkownika, aby żadne inne połączenie nie zablokowało operacji. Przykładowo stosuje się ALTER DATABASE [NazwaBazy] SET SINGLE_USER WITH ROLLBACK IMMEDIATE, a po zakończeniu prac przywraca odpowiedni tryb dostępu. Opcja WITH ROLLBACK IMMEDIATE kończy istniejące transakcje i rozłącza użytkowników, dlatego jej użycie wpływa na aktualny stan pracy systemu.
Granice operacji ratunkowych i dalsza kontrola
EMERGENCY nie jest sposobem na ominięcie praw dostępu, odtworzenie brakujących plików ani naprawę każdego rodzaju awarii. Jeżeli uszkodzeniu uległ nośnik, plik danych jest niedostępny albo występują błędy sprzętowe, samo DBCC CHECKDB może nie wystarczyć. Nie należy usuwać plików .mdf, .ndf ani .ldf ani tworzyć nowej bazy o tej samej nazwie w nadziei na odzyskanie danych. Takie działania mogą utrudnić późniejsze odtworzenie.
Po zakończeniu naprawy należy ponownie uruchomić DBCC CHECKDB bez opcji naprawczych i sprawdzić, czy pozostały błędy spójności. Następnie warto zweryfikować dostęp do najważniejszych tabel, poprawność indeksów, działanie kluczy obcych oraz zgodność danych z wymaganiami aplikacji. Sama informacja, że DBCC nie zgłasza błędu fizycznego, nie dowodzi, że usunięte rekordy nie wpłynęły na raporty, rozliczenia lub działanie procedur. Tryb EMERGENCY należy wyłączyć po zakończeniu diagnostyki i przywróceniu właściwego modelu dostępu, ponieważ pozostawienie bazy w stanie awaryjnym utrudnia normalną eksploatację i zwiększa ryzyko niekontrolowanych zmian administracyjnych.
