Export danych z bazy w trybie EMERGENCY

Export danych z bazy w trybie EMERGENCY to procedura ratunkowa odzyskiwania informacji z bazy przełączonej w stan awaryjny.

EMERGENCY jako stan awaryjny bazy danych

Export danych z bazy w trybie EMERGENCY oznacza próbę odzyskania informacji z bazy, która została przełączona w stan awaryjny. W terminologii Microsoft SQL Server stan EMERGENCY jest jednym ze stanów dostępności bazy i sygnalizuje sytuację wymagającą administracyjnej interwencji. Baza może być w tym stanie udostępniona w ograniczonym zakresie, zwykle z przeznaczeniem do diagnostyki, odczytu metadanych albo ratowania danych. Sam status EMERGENCY nie oznacza, że wszystkie informacje są poprawne lub że każda tabela będzie możliwa do odczytania.

Procedura nie jest zwykłym eksportem wykonywanym podczas normalnej pracy aplikacji. Jej celem jest zachowanie możliwie dużej części danych przed naprawą plików bazy, odtworzeniem kopii zapasowej albo inną operacją administracyjną. Przed rozpoczęciem należy ustalić, który silnik obsługuje bazę, gdzie znajdują się pliki danych i logu transakcyjnego oraz czy istnieje aktualna kopia zapasowa. Próba przypadkowej naprawy, skrócenia procedury lub nadpisania plików może ograniczyć późniejsze możliwości odzyskania.

Rozpoznanie przyczyny przed odczytem danych

Stan EMERGENCY powinien być traktowany jako objaw problemu, a nie jako samodzielna metoda naprawy. Przyczyną może być uszkodzenie struktury pliku danych, niedostępność pliku logu transakcyjnego, błąd systemu plików, awaria nośnika, nieprawidłowe odłączenie bazy albo przerwana operacja odzyskiwania. Znaczenie ma również to, czy baza została wcześniej oznaczona jako SUSPECT, RECOVERY_PENDING, OFFLINE lub pozostaje w innym stanie, który uniemożliwia normalne otwarcie.

W środowisku Microsoft SQL Server administrator powinien najpierw zebrać informacje diagnostyczne z dziennika SQL Server, dziennika systemowego oraz metadanych bazy. Przydatne jest sprawdzenie stanu bazy w widoku sys.databases, identyfikacja plików przez sys.database_files i zapisanie komunikatów błędów przed wykonaniem operacji naprawczych. W szczególności nie należy automatycznie uruchamiać DBCC CHECKDB z opcją REPAIR_ALLOW_DATA_LOSS. Ta opcja może usunąć uszkodzone lub niespójne struktury, dlatego naprawa może spowodować utratę części danych. Jeśli eksport jest możliwy, bezpieczniej jest najpierw skopiować odzyskane rekordy do odrębnego, kontrolowanego miejsca.

Przebieg ratunkowego eksportu rekordów

Export w trybie EMERGENCY powinien być wykonywany na kopii plików lub na środowisku odizolowanym od aplikacji produkcyjnej, gdy tylko pozwala na to stan infrastruktury. Najpierw ustala się zakres danych wymaganych do zachowania: tabele, widoki, kluczowe kolumny, identyfikatory rekordów oraz zależności między tabelami. Następnie sprawdza się, czy obiekty można odczytać pojedynczo. Gdy odczyt całej tabeli kończy się błędem, próbuje się ustalić, czy problem dotyczy konkretnego zakresu stron, indeksu lub pojedynczego rekordu.

W SQL Server można użyć zapytań SELECT do odczytu dostępnych danych i zapisać wynik w formacie, który zachowuje typy oraz strukturę informacji. CSV jest użyteczny przy prostych tabelach, lecz nie zawsze zachowuje wartości binarne, precyzję typów dziesiętnych, wartości NULL, kodowanie znaków i relacje między rekordami. Dla danych zawierających obrazy, dokumenty lub inne wartości varbinary konieczne jest użycie formatu obsługującego dane binarne albo osobnego mechanizmu zapisu. Eksport powinien obejmować także definicje tabel, klucze główne, kolumny tożsamości, ograniczenia i kolejność importu, ponieważ same rekordy nie wystarczą do odtworzenia działającej struktury.

Weryfikacja odzyskanego eksportu

Po zakończeniu odczytu trzeba sprawdzić, czy eksport jest kompletny i spójny. Należy porównać liczbę odczytanych wierszy z dostępnymi informacjami diagnostycznymi, sprawdzić duplikaty kluczy, brakujące wartości, zakresy dat oraz relacje wskazywane przez klucze obce, jeżeli da się je odtworzyć. Jeżeli część rekordów była pomijana z powodu błędów odczytu, trzeba to zapisać w raporcie wraz z nazwą tabeli, zakresem i komunikatem silnika. Eksport ratunkowy nie powinien być przedstawiany jako pełna kopia bazy bez potwierdzenia zawartości.

Odzyskane dane należy zaimportować do nowej, pustej bazy testowej i wykonać kontrolne zapytania aplikacyjne. Weryfikacji wymagają również formaty dat, strefy czasowe, kodowanie znaków, wartości NULL, relacje między tabelami oraz dane binarne. Dopiero po takim sprawdzeniu można ocenić, które informacje nadają się do dalszego użycia. W przypadku fizycznego uszkodzenia nośnika, braku dostępu do plików lub błędów uniemożliwiających odczyt niezbędna może być praca na obrazie dysku i analiza kopii przez osobę posiadającą odpowiednie uprawnienia administracyjne. Wszelkie działania powinny być dokumentowane, aby nie utracić informacji o kolejności operacji i stanie źródłowej bazy.