SQL Server Error Log – diagnostyka

Analiza Error Log to podstawowy krok diagnostyki, ujawniający przyczyny błędów startu lub działania serwera.

Rola SQL Server Error Log w rozpoznawaniu awarii

SQL Server Error Log jest tekstowym dziennikiem zdarzeń generowanym przez aparat Microsoft SQL Server. Rejestruje między innymi uruchamianie i zatrzymywanie usługi, inicjowanie baz systemowych, odzyskiwanie baz po nieprawidłowym zamknięciu, błędy zapisu i odczytu, problemy z plikami baz danych, nieudane logowania, komunikaty dotyczące kopii zapasowych oraz zdarzenia zgłaszane przez mechanizmy DBCC. Analiza tego pliku pozwala ustalić, czy problem wystąpił podczas startu instancji, otwierania konkretnej bazy, obsługi połączenia czy wykonywania operacji wejścia-wyjścia.

Wpisy mają znacznik czasu, poziom komunikatu, numer błędu i opis techniczny. Sam numer błędu nie zawsze wystarcza do postawienia diagnozy, ponieważ istotne są również kolejność komunikatów, nazwa bazy, ścieżka pliku, kod systemu Windows oraz wpisy pojawiające się bezpośrednio przed i po błędzie. Przykładowo komunikat o nieudanym uruchomieniu bazy może być skutkiem wcześniejszego braku dostępu do pliku, uszkodzenia struktury danych albo niedostępności woluminu.

Lokalizacja pliku i odczyt komunikatów instancji

Położenie aktywnego dziennika zależy od konfiguracji instancji. Dla instancji domyślnej plik jest zwykle zapisywany jako ERRORLOG w podkatalogu MSSQL\Log katalogu instalacyjnego SQL Server, natomiast dla instancji nazwanej ścieżka zawiera nazwę instancji. Rzeczywiste położenie należy potwierdzić w SQL Server Configuration Manager, w parametrach uruchamiania usługi. Parametr -e wskazuje katalog i nazwę pliku Error Log; nie należy zakładać, że ścieżka z typowej instalacji jest aktualna.

Dziennik można przeglądać w SQL Server Management Studio przez węzeł Management i sekcję SQL Server Logs albo zapytać z poziomu T-SQL za pomocą procedury sys.sp_readerrorlog. Przykładowe polecenie EXEC sys.sp_readerrorlog 0, 1, N'error'; odczytu bieżący log silnika i filtruje wyniki według tekstu. Pierwszy argument określa numer archiwum, gdzie 0 oznacza aktywny plik, a drugi wybiera typ dziennika; wartość 1 odnosi się do Error Log aparatu SQL Server. Przy analizie warto przeglądać również archiwa, ponieważ bieżący plik może nie zawierać komunikatów z chwili wcześniejszego incydentu.

Łączenie wpisów z etapem pracy SQL Server

Diagnostykę należy rozpocząć od ustalenia przedziału czasu i sprawdzenia pierwszego komunikatu wskazującego odchylenie od prawidłowego startu. Sekwencja uruchomieniowa zwykle zawiera informacje o wersji silnika, trybie uwierzytelniania, inicjalizacji baz systemowych i gotowości do przyjmowania połączeń. Jeżeli brakuje komunikatu o gotowości, trzeba sprawdzić ostatnią zakończoną fazę oraz kolejne błędy. Powtarzające się komunikaty o dostępie do plików, błędnych ścieżkach lub nieudanym otwarciu urządzenia wskazują na inny kierunek niż problemy z samymi zapytaniami.

W przypadku problemów z bazą użytkownika należy porównać wpisy dotyczące recovery z informacjami o plikach danych i dziennika transakcji. Komunikaty o odzyskiwaniu po awarii, oczekiwaniu na operację wejścia-wyjścia albo braku miejsca na dysku mogą wyjaśniać długi start lub niedostępność bazy. Błąd logowania, w tym komunikat 18456, należy interpretować razem ze stanem podanym w komunikacie, nazwą loginu i bazą docelową. Error Log może potwierdzić próbę logowania i czas zdarzenia, ale nie zastępuje sprawdzenia konfiguracji loginu, mapowania użytkownika i trybu uwierzytelniania.

Porządkowanie logów i bezpieczna dalsza diagnoza

Przed wyciągnięciem wniosków trzeba odróżnić Error Log aparatu SQL Server od dziennika SQL Server Agent oraz systemowego Application log w Podglądzie zdarzeń Windows. Każdy z nich opisuje inny składnik. Warto zestawić ich znaczniki czasu, a także sprawdzić stan usługi, dostępność woluminu, uprawnienia konta usługi do katalogów SQL Server i wolne miejsce na dysku. Nie należy kasować aktywnego pliku w celu jego „wyczyszczenia”, ponieważ może to utrudnić odtworzenie przebiegu awarii.

Nowy plik archiwalny można utworzyć poleceniem EXEC sys.sp_cycle_errorlog;. Operacja zamyka bieżący Error Log, przenosi go do archiwum i rozpoczyna zapis do nowego pliku; nie usuwa jednak przyczyny błędu ani nie naprawia bazy danych. Po rotacji należy zachować poprzedni plik, jeśli trwa analiza incydentu, oraz zanotować dokładny czas wykonania polecenia. Na podstawie pełnego ciągu komunikatów można dopiero zdecydować, czy potrzebne jest sprawdzenie konfiguracji usługi, test nośnika, kontrola integralności bazy poleceniem DBCC CHECKDB czy odtworzenie danych z poprawnej kopii zapasowej.