Przepełnienie dziennika transakcji wynika zwykle z braku regularnych kopii dziennika przy modelu odzyskiwania pełnego.
Jak dochodzi do przepełnienia dziennika transakcji w SQL Server
Przepełnienie dziennika transakcji w Microsoft SQL Server oznacza, że plik dziennika osiągnął rozmiar, w którym nie może już przyjąć kolejnych zapisów. Dziennik transakcji przechowuje informacje potrzebne do odtworzenia zmian oraz wycofania niezatwierdzonych operacji. Każda instrukcja modyfikująca dane, między innymi INSERT, UPDATE i DELETE, generuje wpisy w dzienniku. Dotyczy to również operacji wykonywanych przez indeksy, wyzwalacze i inne elementy obsługujące modyfikację danych.
W modelu odzyskiwania FULL samo wykonanie punktu kontrolnego nie zwalnia miejsca w dzienniku w sposób pozwalający na jego ponowne użycie. Do obcięcia nieaktywnych fragmentów dziennika potrzebna jest regularna kopia dziennika transakcji wykonywana poleceniem BACKUP LOG. Jeżeli takie kopie nie są wykonywane, kolejne wpisy pozostają wymagane z punktu widzenia łańcucha kopii zapasowych, a plik dziennika może stale rosnąć aż do osiągnięcia limitu ustalonego przez konfigurację dysku lub właściwości pliku.
Model odzyskiwania a możliwość ponownego użycia miejsca
Model odzyskiwania bazy można sprawdzić w widoku katalogowym sys.databases, w kolumnie recovery_model_desc. Dla modelu FULL dziennik należy regularnie kopiować, jeśli wymagane jest odtwarzanie do określonego punktu w czasie. Pierwsza kopia dziennika po przełączeniu bazy na model pełny tworzy podstawę łańcucha kopii dziennika, o ile wcześniej wykonano odpowiednią pełną kopię zapasową bazy. Późniejsze kopie powinny być wykonywane w sposób ciągły i przechowywane zgodnie z przyjętą polityką odzyskiwania.
W modelu SIMPLE SQL Server może automatycznie oznaczać nieaktywne fragmenty dziennika jako możliwe do ponownego użycia po punktach kontrolnych. Ten model nie obsługuje jednak kopii dziennika ani odtwarzania do dowolnego momentu pomiędzy kopiami pełnymi lub różnicowymi. Zmiana modelu odzyskiwania nie jest neutralnym zabiegiem diagnostycznym: wpływa na dostępne scenariusze odtwarzania i może przerwać dotychczasowy łańcuch kopii dziennika. Dlatego najpierw należy ustalić wymagania dotyczące odzyskiwania, a dopiero później dobierać model i harmonogram kopii.
Rozpoznawanie przyczyny blokującej obcięcie dziennika
Informację o przyczynie oczekiwania na ponowne użycie miejsca można odczytać z kolumny log_reuse_wait_desc w widoku sys.databases. Wartości takie jak LOG_BACKUP wskazują na brak wymaganej kopii dziennika, natomiast ACTIVE_TRANSACTION oznacza, że otwarta transakcja nadal wymaga zachowania określonych wpisów. Przyczyną może być również oczekiwanie związane z replikacją, grupą dostępności, tworzeniem kopii zapasowej albo innym mechanizmem korzystającym z dziennika.
Przykładowe zapytanie diagnostyczne może obejmować nazwę bazy, model odzyskiwania i przyczynę oczekiwania:
SELECT name, recovery_model_desc, log_reuse_wait_desc FROM sys.databases;
Samo sprawdzenie procentowego zapełnienia pliku nie wskazuje jeszcze przyczyny problemu. Do oceny wykorzystania dziennika można użyć między innymi sys.dm_db_log_space_usage uruchomionego w kontekście konkretnej bazy. Przy podejrzeniu długiej transakcji pomocny jest widok sys.dm_exec_requests oraz informacje o czasie rozpoczęcia transakcji dostępne w widokach dynamicznych SQL Server. Należy odróżnić aktywną transakcję od dużej, lecz zakończonej operacji: zakończenie instrukcji nie zawsze oznacza, że wszystkie zasoby związane z transakcją zostały już zwolnione.
Bezpieczne działania po osiągnięciu limitu pliku
Po potwierdzeniu wartości LOG_BACKUP należy wykonać prawidłową kopię dziennika, o ile baza pozostaje w modelu FULL lub BULK_LOGGED i istnieją warunki do kontynuowania łańcucha kopii. Jeżeli brakuje miejsca na dysku, konieczne może być wcześniejsze udostępnienie przestrzeni albo powiększenie pliku dziennika zgodnie z możliwościami środowiska. Rozmiar pliku powinien być dobrany do rzeczywistego obciążenia, wielkości operacji wsadowych i wymaganego okna odzyskiwania, a przyrosty należy ustawić w sposób ograniczający częste, małe rozszerzenia.
Zmniejszenie pliku poleceniem DBCC SHRINKFILE nie usuwa przyczyny przepełnienia. Po kolejnym dużym obciążeniu plik może ponownie urosnąć, a częste zmniejszanie i rozszerzanie zwiększa narzut operacyjny oraz może pogorszyć układ fragmentów wewnątrz pliku. Najpierw należy ustalić wartość log_reuse_wait_desc, sprawdzić harmonogram kopii dziennika, znaleźć ewentualne długie transakcje i zweryfikować dostępne miejsce na woluminie. Przy diagnostyce środowiska SQL Server można także przeanalizować konfigurację pliku dziennika, liczbę wirtualnych plików dziennika oraz historię operacji, aby rozróżnić jednorazowy skok zapotrzebowania od trwałego błędu w procesie odzyskiwania.
