sys.dm_db_log_stats prezentuje zbiorcze statystyki dziennika transakcji od ostatniej kopii zapasowej.
Co pokazuje widok sys.dm_db_log_stats
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. Wynik obejmuje między innymi całkowity rozmiar pliku dziennika, ilość aktywnie używanego miejsca, procent zajętości, liczbę wirtualnych plików dziennika VLF oraz przyczynę, która może blokować obcinanie dziennika. Widok zwraca jeden wiersz dla każdej bazy objętej zapytaniem.
Dane z DMV pomagają ocenić bieżący stan logu bez analizowania każdego wpisu transakcyjnego. Można dzięki nim sprawdzić, ile danych zapisano od ostatniej kopii zapasowej dziennika, kiedy wykonano tę kopię, jak długo trwały operacje wzrostu pliku oraz jaki powód zatrzymuje ponowne wykorzystanie miejsca. Informacje są szczególnie przydatne podczas diagnozowania szybko rosnącego pliku LDF, problemów z miejscem na dysku i opóźnień w wykonywaniu kopii zapasowych.
Najważniejsze informacje o dzienniku transakcji
Kolumny total_log_size_in_bytes i active_log_size_in_bytes pokazują odpowiednio całkowity rozmiar dziennika oraz część zajętą przez aktywne rekordy, które nadal są potrzebne SQL Serverowi. used_log_space_in_percent przedstawia procent wykorzystania pliku. Wysoka wartość tego pola nie zawsze oznacza błąd, ponieważ jej znaczenie zależy od modelu odzyskiwania, trwających transakcji, replikacji, funkcji Always On oraz innych mechanizmów korzystających z dziennika.
Pola total_vlf_count i active_vlf_count informują o liczbie wirtualnych plików dziennika. VLF są wewnętrznymi obszarami pliku logu używanymi przez silnik do zarządzania jego strukturą. Nadmierna liczba VLF może zwiększać koszt operacji związanych z uruchamianiem bazy, odzyskiwaniem i obsługą dziennika, dlatego te wartości warto analizować razem z historią zmian rozmiaru pliku. Kolumny log_growths oraz log_growth_time_ms pozwalają sprawdzić liczbę wzrostów i łączny czas przeznaczony na te operacje.
Przykładowe zapytania diagnostyczne
Stan dziennika dla wszystkich baz można odczytać za pomocą zapytania:
SELECT DB_NAME(database_id) AS database_name, recovery_model, total_log_size_in_bytes, active_log_size_in_bytes, used_log_space_in_percent, log_truncation_holdup_reason, total_vlf_count, active_vlf_count FROM sys.dm_db_log_stats(NULL);
Argument NULL oznacza pobranie danych dla wszystkich baz, do których użytkownik ma dostęp. Dla jednej bazy można przekazać jej identyfikator, na przykład DB_ID(N'MojaBaza'). Przy analizie należy zwracać uwagę na log_truncation_holdup_reason. Wartość wskazuje mechanizm lub stan uniemożliwiający obcięcie niepotrzebnej części logu, ale sama w sobie nie jest poleceniem naprawczym. Usunięcie pliku LDF, ręczne kasowanie jego zawartości albo cykliczne zmniejszanie pliku nie rozwiązuje przyczyny problemu i może pogorszyć działanie bazy.
Interpretacja wyników i diagnostyka
Jeżeli dziennik rośnie, najpierw trzeba ustalić model odzyskiwania i oczekiwany sposób wykonywania kopii zapasowych. W modelu pełnym lub bulk-logged regularne kopie zapasowe dziennika są elementem prawidłowego łańcucha backupów. Brak takich kopii może powodować stały wzrost aktywnej części logu. W modelu simple obcinanie przebiega według innych zasad, ale również może być opóźnione przez długo trwającą transakcję, proces odzyskiwania lub operację wymagającą dalszego dostępu do zapisów.
Warto zestawić wynik sys.dm_db_log_stats z informacjami o aktywnych transakcjach, historią zadań SQL Server Agent, komunikatami z dziennika oraz stanem wolnego miejsca na woluminie. DMV jest migawką aktualnego stanu, a nie pełnym dziennikiem historycznym, dlatego pojedynczy odczyt nie pokazuje tempa wzrostu. Powtarzane pomiary wykonywane w stałych odstępach pozwalają ocenić, czy problemem jest stała aktywność transakcyjna, zbyt rzadkie kopie logu, nieprawidłowo dobrany rozmiar początkowy pliku czy nagłe operacje wymagające dużej ilości miejsca.
