Error Log

Error Log to plik dziennika rejestrujący błędy i istotne zdarzenia zachodzące podczas pracy serwera SQL.

Co zawiera Error Log w SQL Server

Error Log w Microsoft SQL Server jest tekstowym dziennikiem pracy silnika bazy danych. SQL Server zapisuje w nim między innymi komunikaty uruchamiania i zatrzymywania usługi, informacje o otwieraniu baz, błędach operacji wejścia i wyjścia, problemach z plikami baz danych oraz zdarzeniach związanych z mechanizmem odzyskiwania po awarii. Dziennik może również zawierać komunikaty dotyczące połączeń, uwierzytelniania, konfiguracji instancji i działania procesów wewnętrznych.

Wpis w Error Log zwykle ma znacznik czasu, poziom lub numer komunikatu oraz opis zdarzenia. W zależności od rodzaju problemu pojawia się także nazwa bazy danych, identyfikator procesu, numer sesji, ścieżka pliku albo kod błędu systemu Windows. Sam dziennik nie jest bazą danych ani historią wszystkich zapytań wykonywanych przez użytkowników. Rejestruje przede wszystkim komunikaty wybrane przez silnik SQL Server jako istotne dla administracji i diagnostyki.

Pliki dziennika i rotacja zapisów

SQL Server przechowuje bieżący dziennik błędów w pliku ERRORLOG, a starsze pliki otrzymują kolejne numery, na przykład ERRORLOG.1, ERRORLOG.2 i następne. Lokalizacja pliku zależy od instancji oraz sposobu instalacji SQL Server. Z tego powodu nie należy zakładać jednej stałej ścieżki dla wszystkich komputerów. Aktualną lokalizację można sprawdzić w konfiguracji usługi lub odczytać z właściwości uruchomionej instancji.

Podczas ponownego uruchomienia usługi SQL Server bieżący plik Error Log może zostać zamknięty i przeniesiony do pliku archiwalnego, a silnik rozpoczyna zapis do nowego ERRORLOG. Administrator może także wykonać rotację ręcznie za pomocą procedury systemowej sp_cycle_errorlog, uruchamianej w kontekście instancji SQL Server. Liczba przechowywanych plików i ich rozmiar mają znaczenie praktyczne: zbyt krótka retencja utrudnia analizę awarii, natomiast bardzo duże pliki mogą wydłużać wyszukiwanie komunikatów.

Przy analizie należy zachować kolejność zdarzeń. Najnowszy komunikat nie zawsze jest przyczyną problemu, ponieważ może być tylko skutkiem wcześniejszego błędu. Warto porównać kilka kolejnych plików, sprawdzić moment rozpoczęcia nieprawidłowości i zestawić go z restartem usługi, zmianą konfiguracji, utratą dostępu do dysku lub innym zdarzeniem infrastrukturalnym.

Odczytywanie komunikatów i łączenie faktów

Error Log można przeglądać w SQL Server Management Studio w obszarze zarządzania instancją, korzystając z widoku SQL Server Logs. Do odczytu wpisów z poziomu T-SQL służy procedura sp_readerrorlog. Pozwala ona pobrać wpisy z bieżącego lub archiwalnego pliku oraz ograniczyć wyniki według tekstu komunikatu albo źródła. Przykładowo administrator może wyszukać wpisy zawierające słowa error, failed, login lub nazwę konkretnej bazy.

Numer błędu trzeba interpretować razem z pełną treścią komunikatu. Informacja o błędzie 823, 824 lub 825 wskazuje na problemy związane z operacjami wejścia i wyjścia oraz integralnością odczytywanych stron danych, ale każdy z tych przypadków wymaga sprawdzenia dodatkowego kontekstu. Komunikat o braku możliwości otwarcia pliku bazy może oznaczać niedostępny wolumin, zmienione uprawnienia do katalogu, usunięty plik albo błędną ścieżkę. Sam wpis w dzienniku nie rozstrzyga automatycznie, która z tych przyczyn wystąpiła.

Podczas diagnostyki Error Log warto zestawić z dziennikiem zdarzeń systemu Windows, stanem usługi SQL Server, informacjami o wolnym miejscu na woluminach oraz wynikami kontroli spójności baz danych. Do sprawdzenia logicznej spójności służy między innymi polecenie DBCC CHECKDB, uruchamiane zgodnie z procedurą utrzymania danej bazy. Jeżeli wpis wskazuje na błędy logowania, należy rozróżnić nieudaną próbę uwierzytelnienia, zablokowane konto, brak mapowania użytkownika na bazę i problem z dostępnością instancji. Takie rozróżnienie zapobiega usuwaniu objawów bez usunięcia przyczyny.

Wykorzystanie Error Log przy naprawie awarii

Przed zmianą konfiguracji lub ponownym uruchomieniem serwera należy zabezpieczyć kopię odpowiedniego pliku Error Log, ponieważ nowe wpisy mogą utrudnić późniejsze odtworzenie kolejności zdarzeń. Analiza powinna obejmować czas pierwszego błędu, powtarzalność komunikatu, nazwy zasobów, których dotyczy problem, oraz zdarzenia pojawiające się bezpośrednio przed i po nim. Szczególnie ważne są wpisy powtarzające się cyklicznie, ponieważ mogą wskazywać na stały problem z dyskiem, usługą, uprawnieniami lub konfiguracją instancji.

W przypadku podejrzenia uszkodzenia nośnika nie należy ograniczać się do kasowania komunikatów ani do samego restartu SQL Server. Trzeba sprawdzić stan systemu plików, dostępność woluminu, parametry sprzętu magazynującego i komunikaty systemowe. Gdy problem dotyczy uruchamiania bazy, należy zweryfikować obecność plików danych i dziennika transakcji oraz możliwość ich otwarcia przez konto usługi SQL Server. Przy błędach odzyskiwania istotne są również wcześniejsze kopie zapasowe i poprawność przyjętego planu odtwarzania.

Error Log jest więc punktem wyjścia do technicznej diagnozy, a nie samodzielnym raportem o stanie całego komputera. Prawidłowy wniosek powstaje dopiero po połączeniu komunikatów z czasem wystąpienia, konfiguracją instancji, kondycją systemu operacyjnego i wynikami kontrolowanych testów. Takie podejście pomaga odróżnić chwilową anomalię od awarii wymagającej naprawy plików, nośnika, usługi lub konfiguracji SQL Server.