SQL Server Error Log

Error Log to główny dziennik SQL Server, pierwsze miejsce diagnostyki problemów z uruchomieniem instancji.

Rola SQL Server Error Log w uruchamianiu instancji

SQL Server Error Log to tekstowy dziennik zdarzeń generowany przez aparaturową część silnika Microsoft SQL Server. Zawiera informacje powstające podczas uruchamiania, pracy i zatrzymywania instancji, dlatego jest jednym z podstawowych źródeł danych przy analizie problemów z usługą SQL Server. Wpisy mogą dotyczyć między innymi inicjalizacji baz systemowych, odtwarzania transakcji po nieprawidłowym zamknięciu, otwierania plików baz danych, uruchamiania punktów końcowych oraz błędów komunikacji z systemem operacyjnym.

Podczas startu instancja zapisuje w dzienniku między innymi wersję produktu, numer kompilacji, tryb uwierzytelniania, używane parametry uruchomieniowe, ścieżki plików baz systemowych i adresy nasłuchujących punktów końcowych. Jeżeli usługa nie może wystartować, Error Log często pokazuje przyczynę bardziej szczegółowo niż sam komunikat usługi Windows. Przykładami są brak dostępu do pliku master, zajęty port TCP, nieprawidłowa ścieżka pliku, błąd otwarcia urządzenia dyskowego albo nieudane odzyskiwanie bazy danych.

Gdzie znajduje się plik ERRORLOG i jak działa rotacja

Główny plik dziennika nosi nazwę ERRORLOG. Kolejne, starsze pliki otrzymują nazwy ERRORLOG.1, ERRORLOG.2 i następne. Lokalizacja zależy od konfiguracji instancji oraz wersji SQL Server, dlatego nie należy zakładać jednej stałej ścieżki dla każdego komputera. Bieżącą lokalizację można sprawdzić w SQL Server Management Studio w sekcji właściwości serwera dotyczącej parametrów uruchomieniowych albo w SQL Server Configuration Manager. Lokalizacja pliku jest także określana parametrem uruchomieniowym -e.

Nowy plik można utworzyć bez zatrzymywania instancji, wykonując procedurę systemową sp_cycle_errorlog. Operacja zamyka bieżący plik, zmienia jego nazwę na kolejną pozycję archiwalną i otwiera nowy ERRORLOG. Rotacja ułatwia ograniczenie rozmiaru bieżącego dziennika oraz oddzielenie zdarzeń z różnych okresów. Liczba przechowywanych plików i sposób ich utrzymywania powinny być zgodne z przyjętą konfiguracją administracyjną; sam fakt istnienia starszych plików nie oznacza, że obejmują one cały wymagany okres.

Filtrowanie wpisów przez SSMS i procedury systemowe

W SQL Server Management Studio dziennik można otworzyć przez węzeł Management, a następnie SQL Server Logs. Przeglądarka pozwala wybrać bieżący lub archiwalny plik, filtrować wpisy według tekstu, źródła, daty i poziomu, a także wyszukiwać fragmenty komunikatów. Przy analizie awarii istotne jest porównanie czasu wpisów z czasem zgłoszenia problemu, logiem aplikacji oraz dziennikiem systemowym Windows. Sam wpis informacyjny nie musi oznaczać awarii, a komunikat o błędzie może być skutkiem wcześniejszego problemu infrastrukturalnego.

Z poziomu zapytania T-SQL można użyć procedury sp_readerrorlog, która odczytuje zawartość dziennika SQL Server. Jej parametry umożliwiają wskazanie numeru pliku, rodzaju logu, tekstu wyszukiwania oraz języka komunikatu. Przykładowo zapytanie EXEC sys.sp_readerrorlog 0, 1, N'error'; odczytuje bieżący dziennik SQL Server i filtruje wyniki według podanego tekstu. Procedura xp_readerrorlog jest rozszerzoną procedurą systemową używaną do bardziej szczegółowego filtrowania. Dostęp do tych danych zależy od uprawnień konta wykonującego zapytanie, dlatego brak wyników nie zawsze oznacza brak wpisów.

Interpretacja błędów i bezpieczny tok diagnostyki

Przy problemie ze startem SQL Server należy najpierw ustalić nazwę instancji, czas ostatniej próby uruchomienia oraz konto, na którym działa usługa. Następnie trzeba odczytać bieżący i poprzedni plik ERRORLOG, ponieważ po restarcie najnowsze komunikaty mogą znajdować się dopiero w nowo utworzonym pliku. Wpisy dotyczące błędów 5, 32 lub 3 systemu Windows mogą wskazywać odpowiednio na odmowę dostępu, użycie pliku przez inny proces albo nieprawidłową ścieżkę. Takie komunikaty należy wiązać z konkretnym plikiem i kontem usługi, a nie traktować jako ogólną awarię silnika.

Jeżeli dziennik wskazuje problem z bazą master, plikiem dziennika transakcji, portem lub parametrem startowym, zmiany należy wykonywać dopiero po zachowaniu kopii konfiguracji i potwierdzeniu ścieżek w systemie. Nie powinno się usuwać plików baz danych ani ręcznie zmieniać nazw plików ERRORLOG w celu ukrycia komunikatu. Warto zestawić Error Log z Podglądem zdarzeń Windows, logiem SQL Server Agent, jeżeli dotyczy on tego komponentu, oraz stanem miejsca na woluminach. Powtarzający się wpis po każdym restarcie może oznaczać skutek, natomiast pierwszy chronologicznie błąd często prowadzi do właściwej przyczyny.