Log SQL Server

Log SQL Server to dziennik komunikatów silnika bazodanowego, podstawowe źródło informacji przy diagnozowaniu awarii.

Rola dziennika błędów w SQL Server

Log SQL Server, nazywany także dziennikiem błędów SQL Server, jest plikiem tekstowym zapisywanym przez aparat bazodanowy Microsoft SQL Server. Zawiera komunikaty dotyczące uruchamiania i zatrzymywania usługi, uwierzytelniania, połączeń, błędów zapisu i odczytu, problemów z plikami baz danych oraz zdarzeń związanych z odzyskiwaniem po awarii. Nie jest to dziennik transakcji. Dziennik transakcji przechowuje informacje potrzebne do odtwarzania zmian i zapewnienia spójności bazy, natomiast log SQL Server służy przede wszystkim do obserwacji działania silnika i analizy zdarzeń.

Wpisy w dzienniku są generowane przez silnik SQL Server, a ich treść może obejmować numer komunikatu, poziom ważności, stan, nazwę procesu lub komponentu oraz opis problemu. Szczególnie istotne są komunikaty o błędach otwierania plików MDF, NDF i LDF, braku uprawnień do katalogu, niedostępności urządzenia magazynującego, nieudanym odzyskiwaniu bazy oraz błędach logowania. Sam wpis nie zawsze wskazuje jedną przyczynę awarii, ale pozwala powiązać objaw z momentem wystąpienia i innymi zdarzeniami zapisanymi w systemie.

Gdzie SQL Server zapisuje swoje komunikaty

Domyślnie dziennik błędów znajduje się w katalogu logów konkretnej instancji SQL Server, w podkatalogu MSSQL\Log. Nazwa aktywnego pliku to zwykle ERRORLOG, a kolejne archiwalne pliki otrzymują nazwy ERRORLOG.1, ERRORLOG.2 i następne. Rzeczywista lokalizacja zależy od wersji, typu instalacji oraz konfiguracji instancji, dlatego nie należy zakładać, że każda instalacja korzysta z identycznej ścieżki. Lokalizację można sprawdzić między innymi w SQL Server Management Studio w sekcji zarządzania logami SQL Server albo w konfiguracji uruchomionej instancji.

Do odczytu zawartości logu można użyć procedury systemowej sp_readerrorlog. Przykładowe wywołanie EXEC sys.sp_readerrorlog; zwraca wpisy z bieżącego pliku, a parametr określający numer pliku pozwala odczytać archiwum, na przykład EXEC sys.sp_readerrorlog 1;. Procedura może również filtrować wyniki według tekstu lub źródła komunikatu. Dostęp do tych informacji zależy od uprawnień konta, a zakres widocznych danych może być ograniczony przez konfigurację zabezpieczeń instancji.

Jak interpretować wpisy przed naprawą

Analiza logu SQL Server powinna uwzględniać kolejność zdarzeń, a nie tylko pojedynczy komunikat. Powtarzający się błąd 823, 824 lub 825 może wskazywać na problem z operacją wejścia-wyjścia, integralnością odczytanych stron albo ponawianymi próbami odczytu. Błąd 9001 informuje o niedostępności dziennika transakcji bazy, natomiast komunikaty o błędzie 5120 często dotyczą braku możliwości dołączenia lub otwarcia pliku bazy przez usługę. Znaczenie numeru trzeba zawsze odczytywać razem z pełnym tekstem, nazwą bazy, ścieżką pliku i informacjami o urządzeniu.

Ważne jest porównanie czasu wpisu z dziennikiem aplikacji, Podglądem zdarzeń systemu Windows oraz stanem miejsca na dysku. Komunikat o braku miejsca może być skutkiem zapełnienia woluminu przez pliki baz danych, dziennik transakcji lub inne dane, ale może też pojawić się podczas operacji odzyskiwania. Z kolei błąd logowania nie musi oznaczać uszkodzenia bazy; przyczyną może być nieprawidłowe hasło, wyłączone uwierzytelnianie SQL Server, brak mapowania użytkownika do loginu albo odrzucenie połączenia przez konfigurację instancji.

Przed usuwaniem plików logu należy zachować ich kopię i ustalić, czy zawierają informacje potrzebne do odtworzenia przebiegu awarii. Rotacja dzienników może ograniczyć dostępność starszych wpisów, dlatego w przypadku powtarzających się problemów warto zabezpieczyć bieżący ERRORLOG oraz najnowsze archiwa. Samo wyczyszczenie lub ponowne utworzenie pliku nie usuwa przyczyny błędu i może utrudnić późniejszą analizę.

Znaczenie logu przy ocenie stanu instancji

Dziennik SQL Server jest jednym z elementów diagnostyki, ale nie zastępuje kopii zapasowych, kontroli integralności ani analizy konfiguracji. Przy podejrzeniu uszkodzenia danych wyniki logu należy zestawić z rezultatem polecenia DBCC CHECKDB, stanem baz w widoku sys.databases oraz informacjami o plikach i woluminach. Przy problemach z uruchomieniem usługi trzeba dodatkowo sprawdzić konto usługi, uprawnienia do katalogów, parametry startowe instancji i komunikaty zapisane przez system Windows.

Podczas diagnostyki nie należy zmieniać plików MDF, NDF ani LDF, przenosić ich ręcznie ani uruchamiać naprawy bez wcześniejszego ustalenia procedury i zabezpieczenia danych. Niektóre błędy mogą wynikać z awarii dysku, kontrolera, systemu plików lub zasilania, a nie z samego SQL Server. Dlatego poprawna interpretacja wymaga rozdzielenia problemu silnika bazodanowego od problemu infrastruktury, która dostarcza mu pliki i obsługuje operacje wejścia-wyjścia.