Awaria pliku LDF

Awaria pliku LDF to problem uniemożliwiający prawidłowy dostęp do pliku dziennika transakcji bazy danych.

Rola pliku LDF w bazie Microsoft SQL Server

Plik z rozszerzeniem LDF jest plikiem dziennika transakcji używanym przez Microsoft SQL Server. Każda baza danych SQL Server ma dziennik transakcji, który rejestruje zmiany wykonywane na danych i strukturach bazy. Zapis w dzienniku powstaje przed utrwaleniem zmodyfikowanych stron danych w pliku danych MDF lub NDF. Mechanizm ten jest związany z zasadą WAL (write-ahead logging): SQL Server powinien najpierw zapisać odpowiednią informację w dzienniku, a dopiero później może zapisać zmienioną stronę danych na dysku.

Plik LDF nie jest zwykłą kopią bazy ani plikiem tymczasowym, który można usunąć po zakończeniu pracy programu. Zawiera między innymi rekordy potrzebne do odtworzenia lub cofnięcia transakcji oraz informacje wykorzystywane podczas odzyskiwania bazy po awarii procesu, systemu operacyjnego albo zasilania. Podczas uruchamiania SQL Server analizuje stan dziennika i wykonuje fazy odzyskiwania: ponawia zatwierdzone zmiany, wycofuje zmiany transakcji niezakończonych oraz doprowadza bazę do spójnego stanu.

Jak wygląda awaria dziennika transakcji

Awaria pliku LDF może oznaczać brak dostępu do pliku, uszkodzenie jego struktur, niespójność metadanych bazy, brak wolnego miejsca na woluminie albo niemożność zwiększenia pliku do rozmiaru wymaganego przez kolejne transakcje. Przyczyną bywa również uszkodzenie systemu plików, błędny nośnik, nagłe odłączenie dysku, nieprawidłowa migracja plików lub ręczne usunięcie albo przeniesienie pliku bez odpowiedniej zmiany konfiguracji SQL Server.

Jednym z typowych skutków zapełnienia dziennika jest błąd SQL Server 9002, informujący o zapełnieniu dziennika transakcji dla wskazanej bazy. Sama zmiana rozmiaru pliku LDF nie zawsze rozwiązuje problem. Jeżeli baza działa w modelu odzyskiwania FULL albo BULK_LOGGED, dziennik zwykle wymaga regularnych kopii zapasowych logu. Jeżeli log nie może zostać obcięty, przyczyną może być między innymi długo trwająca transakcja, oczekiwanie na replikację lub dostępność, niezakończone operacje oraz inne stany wskazywane przez kolumnę log_reuse_wait_desc w widoku sys.databases.

Rozpoznanie przyczyny bez naruszania danych

Diagnostykę należy rozpocząć od ustalenia, czy problem dotyczy braku miejsca, dostępu do pliku, czy logicznej spójności dziennika. Przydatne są komunikaty z dziennika błędów SQL Server, dziennika systemowego oraz informacje o stanie bazy w widoku sys.databases. Warto sprawdzić kolumny state_desc, recovery_model_desc i log_reuse_wait_desc, a także faktyczną lokalizację pliku przez sys.master_files. Pozwala to odróżnić sytuację, w której log jest duży, ale poprawnie używany, od sytuacji, w której SQL Server nie może zapisać kolejnych rekordów.

Rozmiar i wykorzystanie dziennika można sprawdzić między innymi za pomocą DBCC SQLPERF(LOGSPACE) lub widoków dynamicznych dostępnych dla konkretnej wersji SQL Server, takich jak sys.dm_db_log_space_usage. Kontrolę logicznej spójności bazy wykonuje się poleceniem DBCC CHECKDB, zgodnie z procedurą dobraną do środowiska i posiadanych kopii zapasowych. Nie należy zaczynać od usunięcia pliku LDF, zmiany jego nazwy ani przypadkowego użycia opcji REPAIR_ALLOW_DATA_LOSS. Takie działania mogą uniemożliwić normalne uruchomienie bazy albo doprowadzić do utraty części danych.

Odtwarzanie działania i bezpieczne zarządzanie plikiem LDF

Sposób naprawy zależy od przyczyny i modelu odzyskiwania. Gdy problemem jest brak wolnego miejsca, można zwolnić miejsce na woluminie, dodać kolejny plik dziennika na właściwym dysku albo zwiększyć istniejący plik, wcześniej sprawdzając konfigurację autowzrostu. W bazie pracującej w modelu FULL lub BULK_LOGGED należy wykonywać kopie zapasowe dziennika zgodnie z przyjętym harmonogramem. Kopia logu może pozwolić na obcięcie nieaktywnych fragmentów dziennika, ale nie zastępuje pełnej kopii zapasowej bazy i nie naprawia fizycznie uszkodzonego pliku.

Zmniejszanie pliku za pomocą DBCC SHRINKFILE nie powinno być rutynową metodą zarządzania dziennikiem. Po jednorazowym, uzasadnionym wzroście log może ponownie zwiększać się, powodując fragmentację wewnętrzną i dodatkowe operacje wejścia-wyjścia. Jeżeli plik został przeniesiony, procedura powinna obejmować zmianę jego ścieżki w metadanych SQL Server, kontrolowane zatrzymanie lub odłączenie bazy zgodnie z dokumentacją oraz weryfikację uprawnień konta usługi do nowej lokalizacji. W przypadku rzeczywistego uszkodzenia konieczne jest odtworzenie bazy z poprawnych kopii zapasowych, a przy modelu FULL także odtworzenie dostępnego łańcucha kopii dziennika. Przed każdą ingerencją warto zabezpieczyć istniejące pliki, zebrać komunikaty błędów i ustalić, czy baza jest objęta procedurą odzyskiwania punktu w czasie.