Plik ERRORLOG

ERRORLOG to główny plik dziennika SQL Server, pierwsze miejsce do sprawdzenia przy problemach z uruchomieniem instancji.

ERRORLOG jako dziennik uruchamiania SQL Server

ERRORLOG to tekstowy plik dziennika tworzony przez aparat Microsoft SQL Server. Rejestrowane są w nim komunikaty generowane przez usługę aparatu baz danych, między innymi informacje o rozpoczęciu uruchamiania instancji, inicjalizacji baz systemowych, odczycie parametrów startowych, otwieraniu plików baz danych oraz zakończeniu procedury startowej. Wpisy są zapisywane chronologicznie, dlatego plik pozwala odtworzyć kolejność zdarzeń, która doprowadziła do prawidłowego uruchomienia instancji albo do jego przerwania.

Plik ERRORLOG nie jest dziennikiem wszystkich operacji wykonywanych przez użytkowników baz danych. Nie zawiera pełnej historii zapytań ani kompletnego audytu zmian w tabelach. Jego zadaniem jest przede wszystkim rejestrowanie komunikatów aparatu SQL Server, ostrzeżeń, błędów oraz wybranych zdarzeń związanych z pracą usługi. Przy analizie problemu trzeba odróżnić ERRORLOG aparatu bazy danych od dziennika SQL Server Agent, który korzysta z własnego pliku, zwykle nazywanego SQLAGENT.OUT.

Jak SQL Server zapisuje i przełącza pliki błędów

Bieżący plik nosi nazwę ERRORLOG. Podczas przełączenia dziennika poprzedni plik otrzymuje nazwę archiwalną, na przykład ERRORLOG.1, a SQL Server tworzy nowy plik ERRORLOG. Mechanizm ten ogranicza niekontrolowane powiększanie jednego pliku i pozwala zachować starsze komunikaty do późniejszego porównania. Przełączenie może nastąpić podczas ponownego uruchomienia usługi albo zostać wykonane ręcznie za pomocą procedury systemowej sp_cycle_errorlog.

Procedurę przełączenia można wywołać w kontekście bazy systemowej, na przykład poleceniem EXEC master.dbo.sp_cycle_errorlog;, o ile konto wykonujące operację ma odpowiednie uprawnienia administracyjne. Samo przełączenie nie naprawia błędu i nie usuwa przyczyny problemu. Zmienia jedynie plik, do którego będą trafiały nowe wpisy. Przed wykonaniem tej czynności warto zachować dotychczasowy dziennik, ponieważ może zawierać informacje potrzebne do ustalenia momentu wystąpienia awarii.

Odczyt wpisów i szukanie przyczyny awarii

ERRORLOG można otworzyć w SQL Server Management Studio przez węzeł zarządzania dziennikami SQL Server albo odczytać z systemu plików, jeżeli znana jest lokalizacja katalogu dzienników instancji. Lokalizacja bieżącego pliku może wynikać z konfiguracji usługi. SQL Server używa między innymi parametru startowego -e, który wskazuje ścieżkę pliku dziennika błędów. Z tego powodu nie należy zakładać jednej stałej lokalizacji dla wszystkich instancji, edycji i sposobów instalacji.

Do odczytu komunikatów z poziomu T-SQL stosuje się również procedurę rozszerzoną xp_readerrorlog. Przykładowo polecenie EXEC master.dbo.xp_readerrorlog 0, 1; odczytuje bieżący dziennik aparatu SQL Server, natomiast pierwszy parametr może wskazywać archiwalny plik, taki jak ERRORLOG.1. Drugi parametr rozróżnia typ dziennika; wartość 1 oznacza dziennik aparatu SQL Server, a wartość 2 dotyczy dziennika SQL Server Agent. Przy filtrowaniu można przekazać tekst wyszukiwany, na przykład nazwę bazy, komunikat o braku dostępu albo fragment ścieżki.

Podczas analizy należy zwrócić uwagę na komunikaty występujące tuż przed zatrzymaniem usługi. Szczególne znaczenie mają błędy otwarcia plików MDF i LDF, odmowa dostępu do katalogu, brak wolnego miejsca, nieprawidłowa ścieżka, uszkodzenie strony danych, niezgodność wersji pliku bazy oraz błędy inicjalizacji baz systemowych. Pojedyncze ostrzeżenie nie zawsze oznacza przyczynę awarii. Wiarygodna diagnoza wymaga powiązania treści wpisu z czasem zdarzenia, stanem usługi, konfiguracją instancji i dostępnością wskazanych zasobów.

Postępowanie serwisowe z plikiem ERRORLOG

Jeżeli SQL Server nie uruchamia się, najpierw należy ustalić, czy analizowany jest dziennik właściwej instancji oraz czy plik nie został obrócony po ostatniej próbie startu. Następnie sprawdza się końcowe wpisy bieżącego ERRORLOG i wcześniejsze pliki archiwalne. Ważne jest zachowanie oryginalnej treści przed czyszczeniem, zmianą uprawnień lub ponownym uruchamianiem usługi. Wpis z ERRORLOG powinien być traktowany jako dowód zdarzenia, a nie jako samodzielna instrukcja naprawy.

Diagnostyka może obejmować porównanie ścieżek zapisanych w konfiguracji z rzeczywistą strukturą dysków, sprawdzenie dostępu konta usługi do katalogów, ocenę stanu nośnika oraz analizę powiązanych komunikatów systemu Windows. W przypadku podejrzenia uszkodzenia bazy danych nie należy wykonywać przypadkowych operacji naprawczych bez kopii plików i ustalenia zakresu problemu. Po usunięciu przyczyny kolejne uruchomienie usługi powinno zostać potwierdzone nowym wpisem startowym w ERRORLOG, a nie wyłącznie zmianą statusu usługi w panelu systemowym.