ERRORLOG

ERRORLOG to plik tekstowy zawierający historię błędów i komunikatów startowych instancji SQL Server.

ERRORLOG w SQL Server — co zawiera ten plik

ERRORLOG to bieżący plik dziennika błędów używany przez Microsoft SQL Server. Jest plikiem tekstowym, do którego silnik zapisuje komunikaty dotyczące uruchamiania instancji, zatrzymywania usług, inicjalizacji baz danych, ładowania komponentów oraz problemów występujących podczas pracy. Wpisy są zwykle opatrzone datą i godziną, a komunikat może zawierać także nazwę procesu, poziom ważności, numer błędu lub dodatkowe informacje diagnostyczne.

Plik nie jest dziennikiem wszystkich operacji wykonywanych przez użytkowników. Nie należy oczekiwać, że znajdzie się w nim pełna historia zapytań SQL, każda zmiana danych albo kompletny zapis ruchu sieciowego. ERRORLOG służy przede wszystkim do rejestrowania zdarzeń istotnych dla działania silnika. Mogą pojawić się w nim między innymi informacje o nieudanym otwarciu pliku bazy, błędach autoryzacji, problemach z odzyskiwaniem bazy po nieoczekiwanym zatrzymaniu oraz komunikaty o braku zasobów.

Jak SQL Server korzysta z dzienników błędów

SQL Server przechowuje aktualny dziennik pod nazwą ERRORLOG, a starsze pliki otrzymują nazwy ERRORLOG.1, ERRORLOG.2 i kolejne. Numerowane pliki są archiwalnymi cyklami tego samego dziennika. Przy uruchomieniu instancji silnik może rozpocząć pracę z nowym plikiem, zależnie od konfiguracji oraz sposobu uruchomienia usługi. Dzięki temu bieżący zapis nie musi stale rosnąć od momentu pierwszej instalacji.

W systemie Windows lokalizacja pliku zależy od instancji i wybranej ścieżki logów. Często znajduje się w podkatalogu Log należącym do katalogu instalacyjnego konkretnej instancji SQL Server, ale nie należy zakładać jednej stałej litery dysku ani identycznej ścieżki dla każdej instalacji. W SQL Server działającym w systemie Linux standardowy katalog logów instancji znajduje się zwykle pod /var/opt/mssql/log. Rzeczywistą lokalizację można sprawdzić w SQL Server Configuration Manager, w konfiguracji parametrów uruchomieniowych lub w właściwościach usługi.

Odczyt wpisów i interpretacja komunikatów

Administrator może przeglądać ERRORLOG bezpośrednio jako plik tekstowy, jeśli ma odpowiednie uprawnienia do systemu plików. W SSMS dziennik jest dostępny w węźle Management, w sekcji SQL Server Logs. Z poziomu T-SQL można użyć procedury systemowej sp_readerrorlog, która pozwala odczytywać wpisy oraz filtrować je według tekstu lub identyfikatora dziennika. Procedura xp_readerrorlog jest rozszerzoną procedurą systemową wykorzystywaną w wielu instalacjach do bardziej szczegółowego filtrowania, ale jej użycie powinno uwzględniać uprawnienia i zasady utrzymania konkretnej wersji SQL Server.

Sam numer błędu nie zawsze określa przyczynę awarii. Wpis należy analizować razem z czasem wystąpienia, poprzedzającymi go komunikatami, stanem usługi SQL Server, logami systemu Windows lub systemu Linux oraz stanem plików baz danych. Na przykład komunikat o oczekiwaniu na odzyskiwanie bazy może być normalnym elementem startu po nieoczekiwanym wyłączeniu, natomiast jego długie trwanie, powtarzające się błędy wejścia-wyjścia albo komunikaty o uszkodzeniu stron wymagają dalszej diagnostyki. ERRORLOG może również rejestrować nieudane próby logowania, lecz nie jest samodzielnym dowodem na przyczynę każdego problemu z dostępem.

Rotacja ERRORLOG i znaczenie dla diagnostyki

Jeżeli dziennik długo pozostaje otwarty, może urosnąć do znacznego rozmiaru i utrudnić szybkie wyszukiwanie zdarzeń. W SQL Server można rozpocząć nowy cykl dziennika za pomocą procedury sp_cycle_errorlog. Operacja zamyka bieżący plik i przenosi go do archiwalnego zestawu ERRORLOG.1, ERRORLOG.2 oraz następnych plików, zgodnie z mechanizmem obsługiwanym przez instancję. Rotacja nie usuwa automatycznie przyczyny problemu i nie zastępuje zabezpieczenia starszych logów przed nadpisaniem.

Przed rotacją warto zapisać kopię aktualnego ERRORLOG, jeżeli trwa analiza incydentu. Po wykonaniu cyklu trzeba sprawdzić, czy nowe wpisy trafiają do świeżego pliku oraz czy nie występują błędy uprawnień lub problemy z miejscem na dysku. W praktyce diagnostycznej istotne jest zachowanie spójnej osi czasu: momentu zatrzymania usługi, ponownego uruchomienia, rozpoczęcia odzyskiwania baz i pojawienia się pierwszego komunikatu krytycznego. ERRORLOG pomaga wtedy odróżnić objaw widoczny podczas startu od wcześniejszego zdarzenia, które faktycznie doprowadziło do nieprawidłowego działania instancji.