Baza danych w stanie RECOVERY_PENDING

Baza danych w stanie RECOVERY_PENDING to baza oczekująca na dokończenie procesu odzyskiwania, zablokowana przed problemem uniemożliwiającym jego kontynuację.

Czym jest stan RECOVERY_PENDING w bazie danych

Stan RECOVERY_PENDING oznacza, że system zarządzania bazą danych rozpoznał konieczność wykonania odzyskiwania, lecz nie może rozpocząć go albo kontynuować w normalny sposób. Baza pozostaje wtedy niedostępna dla użytkowników lub działa w sposób ograniczony, ponieważ silnik nie ma wystarczających warunków do odtworzenia spójnego stanu danych. Sam komunikat nie wskazuje jeszcze jednej, konkretnej przyczyny. Informuje przede wszystkim o tym, że proces przywracania bazy został zatrzymany na etapie oczekiwania na rozwiązanie problemu blokującego.

Odzyskiwanie jest procedurą, podczas której analizowany jest dziennik transakcji, porządkowane są zapisane operacje i sprawdzana jest zgodność danych z informacjami znajdującymi się w plikach bazy. Jeżeli po awarii zasilania, przerwaniu procesu zapisu, błędzie urządzenia magazynującego albo nagłym zatrzymaniu usługi nie można uzyskać dostępu do wymaganych plików, baza może przejść właśnie do stanu RECOVERY_PENDING. W tej sytuacji przed wykonaniem jakichkolwiek poleceń naprawczych trzeba ustalić, czy dostępne są pliki danych, dziennik transakcji, kopia zapasowa oraz wystarczająca ilość wolnego miejsca.

Kontekst techniczny i porównanie z innymi stanami - Baza danych w stanie RECOVERY_PENDING

RECOVERY_PENDING należy odróżnić od stanu RECOVERING. W pierwszym przypadku odzyskiwanie jeszcze się nie rozpoczęło albo zostało zablokowane przed właściwym etapem. W drugim silnik faktycznie wykonuje czynności odtwarzające i potrzebuje czasu na ich zakończenie. Różnicę widać również względem stanu RESTORING, który zwykle oznacza trwające odtwarzanie kopii zapasowej, oraz SUSPECT, wskazującego na poważny problem z integralnością lub możliwością odczytu bazy.

Znaczenie ma także stan EMERGENCY, używany w sytuacjach diagnostycznych, gdy próbuje się uzyskać ograniczony dostęp do danych w uszkodzonej bazie. Nie jest on jednak równoznaczny z naprawą. Próba przełączenia bazy do innego stanu może zmienić sposób jej obsługi, ale nie usuwa przyczyny awarii i nie zastępuje odtworzenia sprawdzonej kopii zapasowej. Z tego powodu decyzja o użyciu poleceń naprawczych powinna być poprzedzona zabezpieczeniem plików oraz oceną ryzyka utraty części danych.

W praktyce diagnoza obejmuje między innymi weryfikację ścieżek do plików, uprawnień procesu, dostępności woluminu, integralności systemu plików, komunikatów w dziennikach oraz kolejności zdarzeń poprzedzających awarię. Sprawdzane jest, czy nie doszło do zapełnienia nośnika, uszkodzenia woluminu, odłączenia zasobu, blokady pliku przez inne oprogramowanie albo niedokończonej operacji przywracania. Dopiero po takim rozpoznaniu można rozsądnie ocenić, czy właściwe będzie odtworzenie kopii, naprawa logiczna, odzyskanie plików czy odtworzenie działania z zachowaniem istniejącej struktury danych.

Typowe problemy prowadzące do RECOVERY_PENDING

Jedną z częstych przyczyn jest nagłe przerwanie pracy podczas intensywnych operacji zapisu. Dotyczy to między innymi zaniku zasilania, wymuszonego restartu, zawieszenia systemu albo zatrzymania usługi w trakcie dużej transakcji. Jeżeli po ponownym uruchomieniu nie można odczytać wszystkich wymaganych fragmentów dziennika lub plików danych, proces odzyskiwania może nie przejść do kolejnego etapu.

Problem może wynikać również z uszkodzenia nośnika. Błędy odczytu, niestabilne sektory, problemy z kontrolerem lub nieprawidłowe działanie macierzy mogą sprawić, że część danych pozostaje niedostępna. W takim przypadku kolejne próby uruchamiania bazy mogą pogłębiać trudności, zwłaszcza gdy urządzenie działa niestabilnie i każde odczytanie pliku wiąże się z błędem. Najpierw powinno się ocenić stan nośnika i, jeśli jest to możliwe, wykonać kopię sektorową lub inną bezpieczną formę zabezpieczenia materiału.

Przyczyną bywa także brak miejsca na woluminie, na którym znajdują się pliki danych, dziennik lub pliki tymczasowe. Odzyskiwanie wymaga przestrzeni roboczej, dlatego pozornie niezwiązane z bazą zapełnienie dysku może uniemożliwić zakończenie procedury. Podobny skutek może mieć utrata uprawnień do katalogu, zmiana litery dysku, niedostępna ścieżka sieciowa albo przeniesienie plików bez odpowiedniej aktualizacji konfiguracji.

Nie należy pomijać błędów wynikających z niepełnego odtwarzania kopii zapasowej. Jeżeli przywrócono tylko część wymaganych elementów, zastosowano niezgodną kolejność kopii różnicowych lub pominięto dziennik transakcji, baza może nie osiągnąć spójnego stanu. Kłopotliwe są również uszkodzone kopie, nieudokumentowane ręczne zmiany w plikach oraz brak informacji o tym, jakie operacje wykonano bezpośrednio przed pojawieniem się komunikatu.

Typowym błędem jest wielokrotne uruchamianie przypadkowych poleceń znalezionych w internecie bez wcześniejszego wykonania kopii plików i bez rozpoznania rodzaju awarii. Niektóre działania mogą usunąć informacje potrzebne do odzyskania, zresetować dziennik albo zaakceptować utratę niespójnych fragmentów. Jeżeli dane mają znaczenie dla pracy, najbezpieczniejsza kolejność obejmuje zatrzymanie chaotycznych prób, zebranie komunikatów, zabezpieczenie kopii oraz dopiero późniejszą naprawę na podstawie ustalonego scenariusza.

W jakich sytuacjach warto umówić wizytę serwisową - Baza danych w stanie RECOVERY_PENDING

Zgłoszenie do serwisu jest uzasadnione wtedy, gdy baza pozostaje w stanie RECOVERY_PENDING mimo przywrócenia dostępności nośnika, gdy brakuje pewności co do poprawności kopii zapasowej albo gdy próby naprawy mogą narazić dane na dalsze uszkodzenie. Szczególnej ostrożności wymaga sytuacja, w której występują jednocześnie błędy odczytu, nietypowe dźwięki urządzenia, samoczynne restarty, znikające woluminy lub powtarzające się komunikaty o uszkodzeniu plików.

Przed przekazaniem sprzętu warto przygotować opis momentu wystąpienia problemu, ostatnich wykonywanych operacji, informacji o zaniku zasilania oraz dostępnych kopii bezpieczeństwa. Przydatne są także zrzuty komunikatów, logi, nazwy plików bazy i informacje o zmianach w konfiguracji. Nie powinno się kasować plików dziennika, przenosić danych na przypadkowy nośnik ani uruchamiać narzędzi czyszczących bez ustalenia, czy mogą one zmienić materiał potrzebny do odzyskania.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić ocenę komputera, na którym pojawiły się objawy utraty dostępu do danych lub niestabilnej pracy. Analiza pozwala rozdzielić problem sprzętowy od logicznego, ustalić zakres możliwego odzysku i dobrać dalsze działania z uwzględnieniem wartości przechowywanych informacji. Im wcześniej zostaną przerwane przypadkowe próby naprawy, tym większa szansa na zachowanie plików oraz odtworzenie działania bez niepotrzebnego pogłębiania uszkodzeń.