Ryzyko dalszego uszkodzenia

Ryzyko dalszego uszkodzenia towarzyszy każdej operacji naprawczej wykonywanej na niespójnej bazie danych.

Skąd bierze się ryzyko dalszego uszkodzenia bazy danych

Ryzyko dalszego uszkodzenia pojawia się wtedy, gdy baza danych nie zachowuje spójności między strukturą tabel, indeksami, rekordami i informacjami pomocniczymi zapisanymi w plikach kontrolnych. Przyczyną może być nagłe odłączenie zasilania, zawieszenie systemu, uszkodzenie sektora dysku, błędna aktualizacja programu, przerwanie zapisu przez sterownik magazynu danych albo jednoczesna praca kilku procesów na tych samych plikach. Uszkodzenie nie musi oznaczać całkowitej utraty danych. Częściej występują częściowo zapisane rekordy, brakujące fragmenty indeksów, niezgodność liczników identyfikatorów lub rozbieżność między dziennikiem transakcji a właściwymi stronami danych.

Operacja naprawcza może pogłębić problem, jeżeli zostanie wykonana bez rozpoznania typu uszkodzenia i bez zachowania kopii źródłowej. Przykładowo odbudowanie indeksu nie naprawi brakujących danych w tabeli, a usunięcie pliku indeksu może utrudnić późniejsze ustalenie, które rekordy były dostępne przed awarią. Próba otwarcia bazy w trybie zapisu może z kolei zmienić metadane, wykonać automatyczną korektę albo nadpisać fragmenty potrzebne do analizy. Dlatego każde działanie powinno być poprzedzone ustaleniem, czy problem dotyczy pliku, systemu plików, urządzenia pamięci masowej, aplikacji czy samej logiki danych.

Dlaczego kolejność czynności ma znaczenie

Pierwszym bezpiecznym krokiem jest zatrzymanie programu korzystającego z bazy i ograniczenie operacji zapisu. Nie należy uruchamiać wielokrotnie narzędzia naprawczego ani kasować plików pomocniczych tylko dlatego, że aplikacja zgłasza błąd otwarcia. Należy ustalić lokalizację wszystkich elementów bazy, ich rozmiary, daty modyfikacji oraz zależności między plikiem głównym, dziennikami i kopiami zapasowymi. Warto również sprawdzić, czy system operacyjny raportuje błędy odczytu, problemy z systemem plików albo niestabilne połączenie z dyskiem zewnętrznym.

Przed naprawą wykonuje się kopię sektorową lub przynajmniej wierną kopię wszystkich plików związanych z bazą, o ile nośnik pozwala na ich odczyt. Praca na kopii ogranicza ryzyko nieodwracalnej zmiany danych i umożliwia porównanie wyników kilku metod. Jeżeli urządzenie wydaje nietypowe dźwięki, znika z systemu, zgłasza błędy wejścia-wyjścia lub wielokrotnie ponawia odczyt, dalsze próby programowe mogą zwiększać zużycie nośnika. W takiej sytuacji priorytetem jest stabilne pozyskanie danych, a nie szybkie uruchomienie aplikacji za wszelką cenę.

Naprawa logiczna a odzyskanie rekordów

Naprawa logiczna polega na przywróceniu zgodności struktur, relacji i mechanizmów wyszukiwania przewidzianych przez konkretny program. Narzędzie powinno być dobrane do formatu bazy, ponieważ procedura przeznaczona dla jednego silnika nie jest uniwersalna dla innych. Wynik naprawy trzeba zweryfikować niezależnie: sprawdzić możliwość odczytu tabel, liczbę rekordów, klucze główne, relacje, zakresy dat oraz działanie zapytań używanych przez aplikację. Sam komunikat „naprawa zakończona pomyślnie” nie dowodzi, że wszystkie dane zostały zachowane.

Jeżeli część rekordów jest nieczytelna, bezpieczniejszym celem może być eksport poprawnych danych do nowej, pustej bazy zamiast dalszego modyfikowania uszkodzonego pliku. Trzeba wtedy odnotować pominięte rekordy, błędne pola i elementy, których nie udało się odtworzyć. Po imporcie należy sprawdzić typy danych, kodowanie znaków, wartości puste, unikalność identyfikatorów i zgodność sum kontrolnych, jeżeli aplikacja ich używa. Osobno testuje się operacje odczytu i zapisu, ponieważ baza może poprawnie wyświetlać dane, ale nie zapisywać nowych transakcji albo tworzyć uszkodzone indeksy.

Jak ograniczyć skutki awarii podczas serwisowania

Po zakończeniu prac należy sprawdzić stan nośnika, wolne miejsce, stabilność zasilania i poprawność zamykania aplikacji. Warto skonfigurować automatyczne kopie zapasowe z kontrolą ich odtwarzania, ponieważ sama obecność pliku kopii nie potwierdza jego użyteczności. Kopie powinny mieć oznaczoną datę, pochodzić z momentu, w którym baza była zamknięta lub poprawnie zabezpieczona przez aplikację, i być przechowywane niezależnie od uszkodzonego dysku. Przywrócenie kopii testuje się na osobnej lokalizacji, aby nie nadpisać materiału potrzebnego do dalszej diagnostyki.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, w ramach której można ocenić objawy awarii nośnika, problemy z uruchamianiem aplikacji bazodanowej oraz ryzyko pogorszenia stanu danych. Przed przekazaniem sprzętu warto opisać moment wystąpienia problemu, ostatnie wykonywane czynności, używane kopie zapasowe i komunikaty błędów. Nie należy samodzielnie instalować przypadkowych programów „naprawczych”, formatować dysku ani zapisywać nowych plików na nośniku, z którego mają być odzyskiwane dane. Takie działania mogą nadpisać obszary zawierające rekordy lub metadane potrzebne do odtworzenia bazy.