Uszkodzony plik logu (LDF)

Uszkodzony plik logu (LDF) może wymagać dołączenia bazy z pominięciem dziennika i jego ponownym utworzeniem.

Rola pliku LDF w bazie Microsoft SQL Server

Plik LDF jest plikiem dziennika transakcji używanym przez Microsoft SQL Server. Zawiera informacje potrzebne do odtworzenia zmian wykonanych w bazie danych oraz do wycofania operacji, które nie zostały zatwierdzone. W typowej bazie SQL Server plik danych ma rozszerzenie MDF lub NDF, natomiast plik dziennika ma rozszerzenie LDF. Oba rodzaje plików są elementami jednej bazy, ale pełnią różne funkcje i nie można traktować LDF jak zwykłego pliku pomocniczego.

Silnik zapisuje w dzienniku między innymi operacje modyfikujące wiersze, strony danych i struktury bazy. Dzięki zasadzie WAL (Write-Ahead Logging) odpowiednie wpisy dziennika muszą zostać utrwalone przed zapisaniem zmian danych na dysku. Po awarii SQL Server korzysta z LDF podczas fazy odzyskiwania: analizuje zapisane operacje, ponownie wykonuje potrzebne zmiany i wycofuje transakcje, które nie zostały zatwierdzone. Uszkodzenie logu może więc uniemożliwić prawidłowe otwarcie bazy albo spowodować przejście bazy w stan RECOVERY_PENDING, SUSPECT lub EMERGENCY.

Objawy i przyczyny uszkodzenia dziennika transakcji

Problem z LDF może pojawić się po nagłym wyłączeniu komputera lub serwera, awarii nośnika, błędach systemu plików, nieudanym procesie kopiowania albo usunięciu pliku dziennika poza SQL Server. Przyczyną bywa także uszkodzenie sektorów dysku, błędy kontrolera pamięci masowej lub brak miejsca podczas rozbudowy pliku. Sam komunikat o braku pliku LDF nie zawsze oznacza uszkodzenie danych MDF; wskazuje jednak, że SQL Server utracił element wymagany do spójnego uruchomienia konkretnej bazy.

Diagnostykę rozpoczyna się od sprawdzenia stanu bazy poleceniem SELECT name, state_desc, recovery_model_desc FROM sys.databases; oraz analizy dziennika błędów SQL Server. Integralność struktur danych można zweryfikować poleceniem DBCC CHECKDB (N'NazwaBazy') WITH NO_INFOMSGS;. Wynik CHECKDB należy zachować przed podejmowaniem naprawy, ponieważ może wskazać uszkodzone strony, niespójności metadanych albo problemy wykraczające poza sam plik LDF. Nie należy wielokrotnie uruchamiać poleceń naprawczych bez kopii plików i bez oceny dostępnych kopii zapasowych.

Odbudowa LDF a ryzyko utraty transakcji

Jeżeli plik dziennika został utracony, SQL Server może w określonych warunkach utworzyć nowy log podczas dołączania bazy. Służy do tego składnia CREATE DATABASE ... FOR ATTACH_REBUILD_LOG. Mechanizm ten jest przeznaczony dla sytuacji, w której baza została poprawnie odłączona, a plik LDF jest niedostępny lub uszkodzony. Wymagane są między innymi dostępne pliki danych oraz możliwość ustalenia poprawnego stanu bazy na podstawie tych plików. Nie jest to uniwersalna metoda naprawy dowolnej bazy po awarii.

Przykładowa składnia może wyglądać następująco: CREATE DATABASE [BazaNaprawiana] ON (FILENAME = N'D:\SQLData\BazaNaprawiana.mdf') FOR ATTACH_REBUILD_LOG;. Ścieżkę trzeba zastąpić rzeczywistą lokalizacją pliku, a konto usługi SQL Server musi mieć odpowiednie uprawnienia do katalogu. Odbudowany dziennik nie zawiera historycznych wpisów z poprzedniego LDF, dlatego nie wolno utożsamiać tej operacji z odzyskaniem pełnej historii transakcji. Po udanym dołączeniu należy wykonać CHECKDB, zweryfikować liczbę obiektów i kluczowe dane oraz natychmiast utworzyć nową kopię zapasową.

Jeżeli baza była w trakcie aktywnych transakcji, została odłączona niepoprawnie albo uszkodzeniu uległy również pliki danych, wymuszenie odbudowy logu może zakończyć się błędem lub utratą części niezatwierdzonych zmian. Polecenia DBCC CHECKDB ... REPAIR_ALLOW_DATA_LOSS nie powinno się stosować jako pierwszy krok. Nazwa tej opcji wskazuje, że SQL Server może usunąć uszkodzone lub niespójne elementy, aby doprowadzić bazę do stanu możliwego do otwarcia. Preferowaną drogą pozostaje odtworzenie bazy z poprawnej kopii zapasowej wraz z odpowiednimi kopiami dziennika.

Bezpieczna kolejność czynności serwisowych

Przed próbą naprawy należy zatrzymać procesy korzystające z bazy, ustalić pełne ścieżki MDF, NDF i LDF oraz wykonać kopię plików na osobnym nośniku. Nie należy kasować oryginałów ani nadpisywać ich nowo utworzonymi plikami. Warto sprawdzić stan dysku, dostępne miejsce i komunikaty systemu Windows, a także upewnić się, że badana baza nie jest jedynie odłączona lub przeniesiona do innego katalogu. Jeżeli istnieje pełna kopia zapasowa, kopia różnicowa albo ciąg kopii logu, najpierw ocenia się możliwość odtworzenia na oddzielnej lokalizacji.

Po odzyskaniu dostępu do bazy wykonuje się kontrolę spójności, test odczytu ważnych tabel i indeksów oraz kopię zapasową. Trzeba także zweryfikować model odzyskiwania i zaplanować prawidłowe kopie dziennika, jeżeli baza działa w modelu FULL albo BULK_LOGGED. Samo ponowne uruchomienie aplikacji nie potwierdza poprawności danych, ponieważ część problemów może ujawnić się dopiero przy odczycie konkretnych stron lub podczas wykonywania zapytań. Dokumentacja powinna zawierać stan początkowy, użyte polecenia, komunikaty SQL Server i wynik kontroli CHECKDB.

Uszkodzony LDF jest problemem integralności bazy Microsoft SQL Server, a nie zwykłą usterką nazwy pliku. Dobór metody zależy od stanu bazy, sposobu zakończenia pracy silnika, dostępności kopii zapasowych i wyników kontroli spójności. Odbudowę logu traktuje się jako działanie awaryjne o ograniczonym zastosowaniu; przed jej wykonaniem trzeba zaakceptować możliwość utraty części informacji, których nie da się odtworzyć bez oryginalnego dziennika lub kopii zapasowej.