9002 – Brak miejsca w pliku dziennika transakcji

Błąd 9002 sygnalizuje brak wolnego miejsca w pliku dziennika transakcji, uniemożliwiający dalsze zapisywanie operacji.

Co oznacza błąd 9002 w SQL Server

Błąd 9002 w Microsoft SQL Server oznacza, że dziennik transakcji bazy danych osiągnął limit dostępnego miejsca i nie może przyjąć kolejnych zapisów. Dziennik transakcji, czyli transaction log, rejestruje zmiany wykonywane w bazie przed ich trwałym zatwierdzeniem w plikach danych. Dzięki temu SQL Server może wycofać niezatwierdzoną transakcję albo odtworzyć zatwierdzone operacje po awarii. Gdy plik dziennika jest pełny, operacje wymagające zapisania kolejnych wpisów logu mogą zostać zatrzymane.

Komunikat 9002 nie wskazuje samodzielnie, że uszkodzony jest plik danych lub cały dysk. Opisuje stan dziennika konkretnej bazy, ale przyczyną może być zarówno zbyt mały rozmiar pliku, brak miejsca na woluminie, brak kopii zapasowych logu, długo trwająca transakcja, jak i problem z ponownym wykorzystaniem zapisanych fragmentów dziennika. Po usunięciu objawu warto ustalić, dlaczego SQL Server nie mógł zwolnić miejsca, ponieważ samo jednorazowe zwiększenie pliku może nie rozwiązać problemu.

Dlaczego dziennik transakcji przestaje się ponownie wykorzystywać

Plik logu jest podzielony na fragmenty, w których znajdują się rekordy opisujące operacje. Po zakończeniu odpowiednich transakcji fragmenty mogą zostać oznaczone jako możliwe do ponownego użycia. O tym, kiedy stanie się to możliwe, decyduje między innymi model odzyskiwania bazy danych. W modelu FULL oraz BULK_LOGGED regularne kopie zapasowe dziennika transakcji są konieczne do zwalniania jego wcześniejszych części. Jeżeli zadanie wykonywania log backup nie działa, kopie nie są tworzone albo nie mogą zostać zapisane, dziennik może rosnąć aż do wyczerpania przydzielonego miejsca.

W modelu SIMPLE SQL Server może ponownie wykorzystywać zatwierdzone fragmenty logu po punkcie kontrolnym, jednak także tutaj dziennik może się zapełnić. Powodem może być pojedyncza bardzo duża transakcja, która nadal jest aktywna, blokada uniemożliwiająca zakończenie operacji albo proces odzyskiwania po awarii. Znaczenie ma również stan bazy w systemach korzystających z mechanizmów wysokiej dostępności lub replikacji, ponieważ oczekiwanie na potwierdzenie lub przesłanie zmian może opóźniać możliwość ponownego użycia części dziennika.

Najważniejszą informacją diagnostyczną jest przyczyna oczekiwania na ponowne wykorzystanie logu, a nie tylko procent zajętego miejsca. SQL Server udostępnia ją między innymi w widoku sys.databases, w kolumnie log_reuse_wait_desc. Wartość wskazuje, czy problem wiąże się na przykład z aktywną transakcją, koniecznością wykonania kopii zapasowej logu, procesem odzyskiwania albo innym mechanizmem zależnym od konfiguracji danej bazy.

Rozpoznanie źródła przepełnienia logu

Analizę należy rozpocząć od ustalenia, która baza zgłasza błąd 9002, jaki jest rozmiar jej pliku dziennika oraz ile miejsca zajmuje log. Informacje o plikach można odczytać z katalogowych widoków systemowych, takich jak sys.database_files, a szczegółowe dane o wykorzystaniu dziennika zwraca funkcja sys.dm_db_log_space_usage uruchamiana w kontekście właściwej bazy. Dla przeglądu wielu baz przydatna jest także funkcja sys.dm_db_log_info, która pokazuje informacje o fragmentach dziennika.

Trzeba odróżnić trzy sytuacje: brak wolnego miejsca na całym woluminie, osiągnięcie maksymalnego rozmiaru ustawionego dla pliku logu oraz brak możliwości logicznego zwolnienia zajętych fragmentów. W pierwszym przypadku powiększenie pliku nie powiedzie się albo pogorszy sytuację. W drugim należy sprawdzić właściwości pliku i ustawienia autowzrostu. W trzecim samo dodanie przestrzeni może jedynie odsunąć kolejny błąd, jeżeli aktywna transakcja lub niesprawne kopie zapasowe nadal blokują ponowne użycie logu.

Przydatne jest sprawdzenie aktywnych transakcji za pomocą DBCC OPENTRAN oraz obserwacja sesji, blokad i czasu trwania operacji w dynamicznych widokach zarządzania. Nie należy automatycznie zabijać sesji ani przerywać transakcji bez oceny skutków. Przerwanie dużej operacji może samo wymagać zapisania wielu wpisów wycofania i przez pewien czas zwiększać obciążenie dziennika. Analiza powinna uwzględniać wykonywane zadania, harmonogram kopii zapasowych i moment rozpoczęcia wzrostu pliku.

Bezpieczne przywrócenie miejsca w dzienniku

Postępowanie zależy od ustalonej wartości log_reuse_wait_desc i modelu odzyskiwania. Jeżeli baza pracuje w modelu FULL lub BULK_LOGGED, a przyczyną jest brak kopii logu, należy najpierw przywrócić poprawne wykonywanie kopii zapasowych dziennika i zweryfikować ich zakończenie. Następnie można ocenić, czy zwolniły się fragmenty logu. Jeżeli plik nadal jest za mały dla normalnego obciążenia, można zwiększyć jego rozmiar w kontrolowany sposób, zapewniając wolne miejsce na woluminie.

Autowzrost powinien mieć przewidywalny przyrost dobrany do charakteru obciążenia, a nie bardzo mały przyrost procentowy powodujący częste rozszerzanie pliku. Rozmiar dziennika warto ustalić na podstawie rzeczywistych okresów największej aktywności, pełnych operacji konserwacyjnych i wymaganego czasu przechowywania kopii. Zmniejszanie pliku poleceniem DBCC SHRINKFILE nie jest ogólną metodą naprawy błędu 9002. Może odzyskać niewykorzystaną przestrzeń po jednorazowym zdarzeniu, ale częste zmniejszanie i ponowne powiększanie prowadzi do niestabilnego zarządzania plikiem.

Jeżeli problem dotyczy aktywnej transakcji, konieczne jest ustalenie, dlaczego nie została zakończona, i dopiero wtedy podjęcie decyzji o jej kontynuowaniu, zatwierdzeniu lub kontrolowanym wycofaniu. Po przywróceniu działania należy obserwować rozmiar logu, wykorzystanie jego przestrzeni, powodzenie kopii zapasowych oraz kolejne wartości log_reuse_wait_desc. Diagnostyka i naprawa powinny odbywać się na kopii zapasowej lub w ramach zatwierdzonej procedury administracyjnej, ponieważ błędna zmiana modelu odzyskiwania albo pochopne przerwanie operacji może wpłynąć na możliwość odtworzenia danych.