Kopia zapasowa przed REPAIR_ALLOW_DATA_LOSS

Kopia przed REPAIR_ALLOW_DATA_LOSS to obowiązkowy backup wykonywany przed naprawą bazy, która może trwale usunąć uszkodzone dane.

Kopia zapasowa przed REPAIR_ALLOW_DATA_LOSS — czym jest to polecenie

REPAIR_ALLOW_DATA_LOSS jest opcją używaną w procedurze DBCC CHECKDB w Microsoft SQL Server. Jej nazwa sygnalizuje, że silnik bazy może próbować naprawić wykryte niespójności kosztem usunięcia części uszkodzonych struktur, rekordów albo stron danych. Nie jest to zwykłe sprawdzenie stanu bazy ani bezpieczna optymalizacja. To działanie awaryjne, które może przywrócić możliwość otwierania lub odczytu bazy, ale jednocześnie może trwale zmienić jej zawartość.

Kopia zapasowa przed uruchomieniem REPAIR_ALLOW_DATA_LOSS powinna być traktowana jako warunek rozpoczęcia prac. Backup tworzy punkt odniesienia, do którego można wrócić, gdy naprawa okaże się zbyt inwazyjna, nie rozwiąże problemu albo ujawni dodatkowe uszkodzenia. Bez takiej kopii można utracić możliwość porównania stanu bazy przed i po naprawie, a także zamknąć sobie drogę do odzyskania danych, które nie zostały odczytane poprawnie.

Warto rozróżnić kopię plików od kopii logicznej oraz pełny backup bazy od ręcznego skopiowania pliku MDF lub LDF. Pliki bazy mogą pozostawać otwarte, być objęte blokadami lub zależeć od dodatkowych plików. Proste kopiowanie z poziomu systemu operacyjnego nie zawsze daje spójny obraz danych. Z tego powodu należy korzystać z mechanizmu backupu SQL Server, a przy poważnych problemach dodatkowo rozważyć wykonanie kopii plikowej po zatrzymaniu usług, zgodnie z dokumentacją używanego środowiska.

REPAIR_ALLOW_DATA_LOSS a stan techniczny bazy i dostępne porównania

Przed podjęciem decyzji należy ustalić, czy problem dotyczy samej bazy, nośnika danych, pamięci operacyjnej, kontrolera dysku, systemu plików albo aplikacji korzystającej z SQL Server. Błąd integralności może być skutkiem jednorazowego zdarzenia, lecz może też wskazywać na powtarzające się błędy odczytu lub zapisu. Uruchomienie naprawy bez rozpoznania przyczyny może doprowadzić do ponownego uszkodzenia bazy po kilku godzinach albo dniach.

Najpierw zwykle wykonuje się kontrolę DBCC CHECKDB bez opcji naprawczej i zapisuje pełny komunikat diagnostyczny. Istotne są między innymi identyfikatory obiektów, numery stron, rodzaj niespójności oraz informacja, czy znaleziono błędy alokacji, indeksów, tabel lub relacji. Sam komunikat o uszkodzeniu nie określa jeszcze, które dane zostaną usunięte przez REPAIR_ALLOW_DATA_LOSS. Zakres możliwych zmian zależy od konkretnego stanu bazy.

Jeżeli dostępna jest prawidłowa kopia zapasowa, preferowaną metodą bywa odtworzenie bazy z backupu, a następnie odtworzenie kolejnych kopii różnicowych i dziennika transakcji, o ile taki łańcuch istnieje i jest kompletny. Naprawa in-place może być rozważana dopiero wtedy, gdy odtworzenie nie jest możliwe, kopia jest nieaktualna lub uszkodzona, a priorytetem staje się odzyskanie choć częściowej dostępności. W takim przypadku należy zaakceptować możliwość utraty fragmentu danych i zaplanować późniejszą weryfikację aplikacji.

Nie należy utożsamiać poprawnego uruchomienia DBCC CHECKDB z pełnym odzyskaniem danych. Baza może przejść kontrolę integralności, a mimo to zawierać braki w tabelach, osierocone relacje, przerwane dokumenty lub niespójności widoczne dopiero z poziomu programu. Dlatego potrzebne jest porównanie liczby rekordów, kluczowych sum kontrolnych, zakresów dat, dokumentów, załączników i wyników najważniejszych zapytań.

Kopia przed REPAIR_ALLOW_DATA_LOSS przy typowych problemach

Najczęstszym scenariuszem jest nieoczekiwane wyłączenie komputera, utrata zasilania albo reset podczas zapisu. W takiej sytuacji SQL Server może rozpocząć odzyskiwanie transakcji, ale jeżeli uszkodzeniu uległy strony danych lub metadane, samo odtwarzanie nie wystarczy. Inną przyczyną bywa zużyty dysk, niestabilne połączenie z macierzą, błędy pamięci albo nieprawidłowe działanie sterownika. Każdy z tych sygnałów powinien skłaniać do zabezpieczenia danych przed kolejnymi próbami zapisu.

Problem może również dotyczyć pliku dziennika transakcji. Jego usunięcie, skrócenie lub podmiana bez zrozumienia zależności między bazą a dziennikiem może utrudnić późniejsze odtworzenie. Podobnie ryzykowne jest odłączanie bazy, zmiana nazw plików oraz próby naprawy znalezione w przypadkowych poradnikach. Przed każdą zmianą warto zachować kopię plików konfiguracyjnych, logów, ustawień połączeń i danych aplikacji, ponieważ sama baza może nie wystarczyć do odtworzenia całego działania programu.

W przypadku uszkodzonych indeksów czasem możliwa jest odbudowa lub usunięcie konkretnego indeksu zamiast użycia szerokiej naprawy. Takie działanie wymaga jednak pewności, że uszkodzenie rzeczywiście ogranicza się do indeksu, a dane podstawowe pozostają czytelne. Nie można zakładać, że komunikat o indeksie wyklucza problemy w tabeli, ponieważ awaria nośnika może wpływać na wiele obiektów jednocześnie.

Po utworzeniu kopii należy zabezpieczyć również jej dostępność. Backup przechowywany na tym samym fizycznym dysku co uszkodzona baza może przestać być użyteczny razem z oryginałem. Zalecane jest sprawdzenie, czy plik kopii można odczytać, czy zawiera oczekiwaną bazę oraz czy odtworzenie testowe kończy się bez błędów. Sam fakt istnienia pliku z rozszerzeniem typowym dla backupu nie potwierdza jego poprawności.

REPAIR_ALLOW_DATA_LOSS — praktyczne wskazówki przed naprawą

• Przerwane zapisy i aktywne procesy korzystające z bazy należy ograniczyć przed wykonaniem diagnostyki oraz naprawy.
• Wyniki DBCC CHECKDB trzeba zapisać w całości, bez ograniczania komunikatu do pierwszych kilku wierszy.
• Przed użyciem opcji naprawczej należy wykonać pełny backup, a jeżeli jest to możliwe, także kopię dziennika transakcji.
• Plik kopii powinien zostać umieszczony na sprawnym nośniku, niezależnym od miejsca, na którym znajduje się uszkodzona baza.
• Przed rozpoczęciem należy określić, jakie dane są najważniejsze: zamówienia, ewidencje, dokumenty, użytkownicy, konfiguracja lub historia operacji.
• Po naprawie trzeba ponownie uruchomić kontrolę integralności i zachować jej wynik jako część dokumentacji.
• Aplikację należy sprawdzić nie tylko pod kątem uruchamiania, lecz także odczytu, zapisu, wyszukiwania, raportowania oraz relacji między tabelami.
• Gdy wykrywane są błędy sprzętowe, nie powinno się wielokrotnie ponawiać operacji na tym samym nośniku, ponieważ kolejne zapisy mogą zwiększyć zakres uszkodzeń.

Dobrym uzupełnieniem jest przygotowanie planu wycofania zmian. Powinno być wiadomo, gdzie znajduje się kopia, jak odtworzyć bazę, jak odłączyć aplikację od uszkodzonego egzemplarza i jak zabezpieczyć dane odzyskane po naprawie. W większych instalacjach warto najpierw wykonać próbę na kopii roboczej, aby ocenić, jakie rekordy, obiekty i zależności pozostają dostępne. Pozwala to ograniczyć ryzyko podejmowania decyzji pod presją niedostępności systemu.

Kiedy zgłosić się z REPAIR_ALLOW_DATA_LOSS do serwisu

Do serwisu warto zgłosić się przed uruchomieniem REPAIR_ALLOW_DATA_LOSS, gdy baza zawiera ważne dokumenty, historię operacji lub dane, których nie da się łatwo odtworzyć. Pomoc jest szczególnie wskazana, gdy nie ma pewności, czy istniejący backup jest spójny, nie wiadomo, który plik należy zabezpieczyć, pojawiają się błędy odczytu dysku albo baza cyklicznie traci integralność. W takiej sytuacji pierwszym krokiem powinno być ograniczenie zmian i zebranie kopii diagnostycznych, a nie wykonywanie kolejnych poleceń naprawczych.

Warszawskie Pogotowie Komputerowe 24/7 może pomóc w uporządkowaniu kolejności działań związanych z zabezpieczeniem bazy, oceną komunikatów DBCC CHECKDB oraz przygotowaniem bezpieczniejszego scenariusza odzyskiwania. Przed przekazaniem sprzętu lub środowiska należy opisać moment wystąpienia problemu, wcześniejsze restarty, komunikaty błędów, dostępne kopie oraz operacje wykonane po awarii. Takie informacje ułatwiają odróżnienie uszkodzenia logicznego od problemu z nośnikiem lub innym elementem komputera.

Nie powinno się traktować REPAIR_ALLOW_DATA_LOSS jako uniwersalnego sposobu na przywrócenie sprawności. Jest to rozwiązanie awaryjne, którego skutki mogą być nieodwracalne. Najbezpieczniejsza kolejność obejmuje zatrzymanie niepotrzebnych zapisów, wykonanie i sprawdzenie kopii, analizę przyczyny, ocenę możliwości odtworzenia oraz dopiero późniejszy wybór metody naprawy. Jeżeli naprawa okaże się konieczna, należy zachować jej wyniki, wykonać ponowną kontrolę i potwierdzić z użytkownikiem, które dane są dostępne, a których może brakować.