Operacje SELECT w EMERGENCY

Zapytania SELECT w trybie EMERGENCY służą wyłącznie wydobyciu danych z uszkodzonej bazy przed jej naprawą.

Co oznacza tryb EMERGENCY w SQL Server

Tryb EMERGENCY jest stanem awaryjnego dostępu do bazy danych Microsoft SQL Server. Ustawia się go poleceniem ALTER DATABASE [NazwaBazy] SET EMERGENCY, gdy baza nie przechodzi prawidłowo do stanu ONLINE albo występują problemy uniemożliwiające zwykłe otwarcie jej zawartości. Stan można sprawdzić w widoku katalogowym sys.databases, odczytując kolumny state_desc, user_access_desc oraz is_read_only.

EMERGENCY nie jest trybem normalnej pracy ani mechanizmem naprawiającym uszkodzone strony danych. Baza jest udostępniana jako tylko do odczytu, a dostęp jest przeznaczony przede wszystkim dla członków roli serwerowej sysadmin. W tym stanie można próbować odczytać zachowane rekordy, metadane i strukturę obiektów, ale nie należy zakładać, że każda tabela, kolumna lub relacja będzie dostępna i spójna.

Jak wykonywać SELECT podczas odzyskiwania danych

Podstawą pracy jest zwykłe zapytanie SELECT kierowane do konkretnego schematu i tabeli, na przykład SELECT TOP (1000) * FROM dbo.Klienci ORDER BY Id. Ograniczenie liczby wierszy zmniejsza obciążenie uszkodzonej bazy i ułatwia ocenę, czy odczyt działa poprawnie. Przy dużych tabelach bezpieczniej dzielić eksport na zakresy klucza głównego, używając warunku WHERE Id >= ... AND Id < ..., zamiast wykonywać jeden nieograniczony odczyt.

W pierwszej kolejności warto odczytać katalog systemowy, między innymi sys.tables, sys.columns, sys.schemas i sys.indexes. Pozwala to ustalić rzeczywiste nazwy tabel, typy kolumn, kolejność kluczy i istnienie indeksów. Przykładowe zapytanie SELECT s.name, t.name FROM sys.tables AS t JOIN sys.schemas AS s ON s.schema_id = t.schema_id ORDER BY s.name, t.name nie pobiera danych biznesowych, lecz pomaga odtworzyć mapę obiektów. W przypadku uszkodzenia metadanych także taki odczyt może zakończyć się błędem.

Granice wiarygodności odczytu z uszkodzonej bazy

Wynik SELECT wykonany w EMERGENCY należy traktować jako materiał do odzyskiwania, a nie jako potwierdzenie poprawności bazy. SQL Server może zwrócić błąd podczas odczytu strony danych, indeksu albo alokacji, na przykład komunikat wskazujący na błąd spójności lub niemożność odczytania określonej strony. Może również zwrócić część danych, gdy problem dotyczy tylko fragmentu tabeli. Brak błędu w jednym zapytaniu nie dowodzi, że cała tabela, wszystkie indeksy i zależności między obiektami są prawidłowe.

Do oceny uszkodzeń służy DBCC CHECKDB ([NazwaBazy]), który sprawdza spójność alokacji, struktury tabel, indeksów i relacji wewnętrznych. Raport z CHECKDB trzeba zachować przed podjęciem naprawy. Opcja REPAIR_ALLOW_DATA_LOSS może powodować usunięcie uszkodzonych struktur lub rekordów, dlatego nie powinna być traktowana jako sposób na bezpieczny eksport. Najpierw wykonuje się możliwie szeroki odczyt zachowanych danych, zapisuje wyniki poza uszkodzoną bazą i dopiero potem analizuje wariant odbudowy.

Eksport wyników i kontrola procesu odzyskiwania

Sam SELECT tylko zwraca wynik zapytania; nie tworzy automatycznie niezależnej kopii danych. Ponieważ baza w EMERGENCY jest przeznaczona do odczytu, operacje modyfikujące, takie jak INSERT, UPDATE, DELETE czy zapis przez SELECT INTO w tej samej bazie, nie są właściwą metodą zabezpieczenia rekordów. Wyniki można eksportować narzędziem działającym poza bazą, na przykład przez bcp z zapytaniem queryout, albo zapisać do pliku za pomocą narzędzia klienckiego. Należy kontrolować kodowanie, separator, wartości NULL, format dat i sposób reprezentacji znaków końca wiersza.

Każdy fragment eksportu powinien mieć zapisane zapytanie, czas wykonania, zakres kluczy, liczbę zwróconych wierszy i ewentualny komunikat błędu. Powtórzenie tego samego SELECT może dać ten sam rezultat, ale nie wolno łączyć fragmentów bez sprawdzenia duplikatów i brakujących zakresów. Po zakończeniu odczytu pliki powinny zostać zweryfikowane przez ponowne policzenie rekordów oraz porównanie kluczy głównych. Dopiero tak przygotowany materiał może posłużyć do odbudowy tabeli lub migracji danych do sprawnej instancji SQL Server.