Ryzyko związane z REPAIR_ALLOW_DATA_LOSS

Ryzyko związane z REPAIR_ALLOW_DATA_LOSS polega na trwałym usunięciu fragmentów danych uznanych za uszkodzone.

Zakres działania opcji REPAIR_ALLOW_DATA_LOSS w SQL Server

REPAIR_ALLOW_DATA_LOSS jest poziomem naprawy używanym przez polecenie DBCC CHECKDB w Microsoft SQL Server. Opcja służy do usuwania niezgodności wykrytych w strukturach bazy danych, gdy łagodniejsze działania naprawcze nie wystarczają. Nazwa wskazuje na najważniejszą konsekwencję: SQL Server może usunąć uszkodzone strony danych, rekordy, fragmenty indeksów albo inne elementy, których nie da się poprawnie odtworzyć na podstawie zachowanych informacji. Naprawa może więc przywrócić spójność struktur, ale jednocześnie zmniejszyć zakres dostępnych danych.

Nie jest to mechanizm odzyskiwania wszystkich utraconych informacji. Jeżeli fragment rekordu został nadpisany, zawiera niepoprawne identyfikatory albo nie może zostać powiązany z pozostałymi strukturami, silnik może go odłączyć lub zdealokować zamiast rekonstruować pierwotną zawartość. W efekcie baza może po naprawie przejść kontrolę integralności, lecz nie musi zawierać kompletu danych istniejących przed wystąpieniem uszkodzenia. Spójność techniczna bazy i kompletność informacji są w tym przypadku odrębnymi pojęciami.

Jak SQL Server ocenia uszkodzenie przed naprawą

Podstawowym krokiem jest wykonanie DBCC CHECKDB bez opcji naprawczej, aby ustalić rodzaj i zakres problemu. Przykładowe polecenie DBCC CHECKDB (N'NazwaBazy') WITH NO_INFOMSGS, ALL_ERRORMSGS; sprawdza między innymi strony danych, struktury alokacji, indeksy, zależności między tabelami oraz zgodność metadanych. Komunikaty DBCC CHECKDB mogą wskazać numery obiektów, identyfikatory stron, poziom błędu i zalecany poziom naprawy. Sama obecność błędów nie oznacza jeszcze, że REPAIR_ALLOW_DATA_LOSS jest właściwym pierwszym działaniem.

Jeżeli dostępna jest prawidłowa kopia zapasowa, preferowanym sposobem przywrócenia uszkodzonego fragmentu jest odtworzenie bazy albo wykonanie odpowiedniego odzyskiwania z kopii pełnej, różnicowej i dziennika transakcji. Pozwala to zachować dane zgodnie ze stanem zapisanym w kopiach. Przed użyciem naprawy należy także sprawdzić, czy problem nie wynika z awarii nośnika, pamięci masowej, kontrolera, sterownika lub pamięci operacyjnej. Usunięcie skutków w samej bazie bez usunięcia przyczyny może doprowadzić do ponownego uszkodzenia.

Dlaczego naprawa może oznaczać trwałą utratę danych

REPAIR_ALLOW_DATA_LOSS może korygować błędy alokacji i struktury, usuwać niespójne wpisy oraz dezasocjować elementy, których integralności nie da się potwierdzić. Dotyczy to między innymi sytuacji, w której rekord wskazuje na nieistniejącą stronę, strona ma sprzeczne informacje o alokacji albo indeks zawiera wpisy niezgodne z tabelą. SQL Server wybiera wtedy rozwiązanie pozwalające utrzymać poprawną strukturę bazy, nawet jeżeli wymaga ono odrzucenia części zawartości. Zakres utraty nie jest stałą wartością i wynika z konkretnego uszkodzenia.

Przed próbą naprawy należy wykonać kopię plików bazy oraz kopię zapasową, o ile stan bazy i konfiguracja pozwalają na jej utworzenie. Warto zachować również pełny wynik DBCC CHECKDB, informacje o wersji SQL Server, dzienniki błędów i dane dotyczące nośnika. Naprawa powinna być przeprowadzana w kontrolowanym oknie serwisowym, ponieważ baza może wymagać trybu SINGLE_USER, a aktywne połączenia mogą uniemożliwić zmianę trybu. Po wykonaniu polecenia trzeba ponownie uruchomić DBCC CHECKDB bez opcji naprawczej i porównać wynik z raportem początkowym.

Ocena bazy po zastosowaniu REPAIR_ALLOW_DATA_LOSS

Pomyślne zakończenie polecenia nie dowodzi, że wszystkie dane biznesowe pozostały dostępne. Po naprawie należy sprawdzić możliwość odczytu tabel, kluczowe relacje, indeksy, widoki i procedury zależne od usuniętych obiektów. SQL Server może zgłaszać brak błędów integralności, mimo że wcześniej uszkodzone rekordy zostały usunięte. Kontrola powinna obejmować także aplikację korzystającą z bazy, ponieważ dopiero zapytania wykonywane przez aplikację mogą ujawnić brakujące wartości, zerwane odwołania albo niespójne wyniki.

REPAIR_ALLOW_DATA_LOSS należy traktować jako działanie awaryjne, stosowane po analizie raportu DBCC CHECKDB i po ocenie możliwości odtworzenia danych z kopii. Nie powinno się uruchamiać go automatycznie po każdym błędzie bazy ani zastępować nim regularnego systemu kopii zapasowych. Jeżeli uszkodzenie wskazuje na problem sprzętowy, dalsza praca wymaga najpierw zabezpieczenia środowiska i ustalenia, czy nośnik przechowujący pliki MDF, NDF lub LDF działa prawidłowo. Dopiero po takim rozpoznaniu można rzetelnie ocenić, czy naprawa strukturalna jest uzasadniona.