SYS.DM_DB_LOG_STATS

sys.dm_db_log_stats prezentuje zbiorcze statystyki dziennika transakcji od ostatniej kopii zapasowej.

Rola widoku sys.dm_db_log_stats w SQL Server

sys.dm_db_log_stats to funkcja dynamicznego zarządzania w Microsoft SQL Server, która zwraca zbiorcze informacje o dzienniku transakcji wskazanej bazy danych. Parametrem jest identyfikator bazy, dlatego typowe wywołanie ma postać sys.dm_db_log_stats(DB_ID()). Funkcja opisuje między innymi rozmiar pliku dziennika, wykorzystanie dziennika, liczbę wirtualnych plików dziennika oraz informacje związane z ostatnią kopią zapasową dziennika.

Dane zwracane przez tę funkcję są przydatne podczas diagnozowania przyrostu pliku LDF, długiego odzyskiwania bazy, opóźnionego ponownego użycia miejsca w dzienniku oraz problemów z regularnością kopii zapasowych logu. DMV nie zastępuje DBCC SQLPERF(LOGSPACE), monitorowania kopii zapasowych ani analizy aktywnej części dziennika, lecz dostarcza zestaw pól przeznaczonych do szybkiego przeglądu stanu dziennika dla konkretnej bazy.

Jak odczytywać najważniejsze kolumny

Wynik zawiera między innymi identyfikator bazy danych, rozmiar dziennika w megabajtach, procent użycia dziennika oraz czas ostatniej kopii zapasowej dziennika. Istotne są także pola dotyczące aktywnego dziennika, takie jak numer sekwencyjny pierwszego rekordu aktywnego dziennika, numer sekwencyjny ostatniego rekordu dziennika i liczba wirtualnych plików dziennika. Wirtualny plik dziennika, określany skrótem VLF, jest wewnętrzną częścią pliku transakcyjnego logu. SQL Server zapisuje rekordy dziennika w VLF-ach, a ich ponowne wykorzystanie zależy od tego, czy nie są już potrzebne do odzyskiwania lub innych operacji wymagających zachowania logu.

Przykładowe zapytanie diagnostyczne można wykonać w następujący sposób: SELECT * FROM sys.dm_db_log_stats(DB_ID());. W praktyce lepiej wybierać jawnie potrzebne kolumny, aby wynik był stabilniejszy dla skryptów monitorujących. Wysoki procent wykorzystania nie oznacza automatycznie uszkodzenia bazy ani konieczności natychmiastowego zmniejszania pliku. Trzeba ustalić przyczynę zajęcia logu, sprawdzając między innymi wartość log_reuse_wait_desc w sys.databases, aktywne transakcje, trwające operacje oraz konfigurację modelu odzyskiwania.

Zastosowanie w diagnostyce dziennika transakcji

Jeżeli plik dziennika stale rośnie, sam rozmiar pliku nie wskazuje jeszcze, czy problemem jest zbyt mała początkowa alokacja, brak kopii zapasowych logu, długa transakcja, replikacja, zmiana śledzona przez mechanizmy wysokiej dostępności albo inny proces blokujący ponowne użycie fragmentów dziennika. sys.dm_db_log_stats pomaga zestawić bieżący rozmiar, stopień wykorzystania, liczbę VLF-ów i znaczniki czasowe kopii zapasowych. Porównanie wyników w czasie pozwala rozróżnić jednorazowy skok wynikający z dużej operacji od ciągłego narastania aktywnej części logu.

Funkcja jest także użyteczna przy analizie czasu uruchamiania bazy po awarii lub restarcie usługi. Odzyskiwanie obejmuje fazę analizy, ponownego wykonania zapisanych zmian i wycofania zmian należących do niezatwierdzonych transakcji. Ilość rekordów wymagających przetworzenia zależy od stanu dziennika i momentu awarii, dlatego duży aktywny log może wydłużyć odzyskiwanie. W takim przypadku diagnostyka powinna obejmować również komunikaty SQL Server, stan sesji, aktywne transakcje oraz konfigurację kopii zapasowych. Nie należy traktować pojedynczego odczytu DMV jako samodzielnego dowodu przyczyny problemu.

Uprawnienia, ograniczenia i bezpieczna interpretacja

Odczyt informacji z funkcji DMV może wymagać odpowiednich uprawnień serwera lub bazy danych, zależnie od wersji SQL Server i kontekstu wykonania. W środowisku produkcyjnym konto monitorujące powinno otrzymać wyłącznie uprawnienia potrzebne do odczytu danych diagnostycznych, zgodnie z przyjętym modelem bezpieczeństwa. Zapytanie warto uruchamiać w kontekście właściwej instancji i sprawdzić, czy DB_ID() zwraca identyfikator oczekiwanej bazy, ponieważ funkcja analizuje bazę wskazaną argumentem.

Zmniejszanie pliku dziennika poleceniem DBCC SHRINKFILE nie jest uniwersalną metodą naprawy. Jednorazowe zmniejszenie może być uzasadnione po wyjątkowo dużej operacji, gdy wiadomo, że zaalokowane miejsce nie będzie ponownie potrzebne, ale cykliczne kurczenie i ponowne powiększanie pliku może zwiększać fragmentację VLF i pogarszać stabilność pracy. Prawidłowa diagnostyka zaczyna się od ustalenia przyczyny oczekiwania ponownego użycia logu, dobrania rozmiaru pliku do przewidywanego obciążenia oraz zaplanowania kopii zapasowych dziennika, jeśli baza działa w modelu odzyskiwania pełnym lub bulk-logged. Dla serwerowego SQL Server analiza powinna być prowadzona przez administratora znającego konfigurację instancji, harmonogram backupów i zależności między bazą a systemami korzystającymi z jej danych.