Log File Viewer

Log File Viewer to narzędzie Management Studio umożliwiające przeglądanie i filtrowanie dzienników serwera.

Log File Viewer w SQL Server Management Studio

Log File Viewer jest składnikiem SQL Server Management Studio przeznaczonym do odczytu dzienników związanych z instancją Microsoft SQL Server. Otwiera się go w Eksploratorze obiektów po rozwinięciu węzła zarządzania instancją, wybraniu pozycji „SQL Server Logs” i użyciu polecenia „View SQL Server Log”. Okno może prezentować bieżący dziennik błędów SQL Server oraz dostępne dzienniki archiwalne. Wpisy są uporządkowane według czasu i zawierają między innymi datę, źródło oraz treść komunikatu.

Narzędzie nie analizuje dowolnych plików tekstowych jak ogólny edytor logów. Jego działanie zależy od typu dziennika udostępnianego przez SQL Server, SQL Server Agent albo system Windows oraz od uprawnień konta użytego do połączenia. Przy pracy ze zdalną instancją odczytywane są dane z serwera, a nie z dysku komputera, na którym uruchomiono samo Management Studio. Z tego powodu wynik obserwacji zależy od właściwej instancji, wybranej bazy połączenia i konfiguracji usług.

Filtrowanie wpisów według czasu, źródła i treści

Podstawową funkcją Log File Viewer jest zawężanie listy komunikatów. Administrator może ograniczyć zakres dat, wskazać źródło wpisu i wyszukać określony tekst w komunikacie. Takie filtrowanie ułatwia odseparowanie zdarzeń dotyczących uruchamiania usługi, uwierzytelniania, kopii zapasowych, połączeń sieciowych, blokad lub błędów wejścia i wyjścia. W praktyce warto rozpocząć od dokładnego przedziału czasu odpowiadającego wystąpieniu problemu, ponieważ nieograniczony widok może zawierać wiele niezwiązanych zdarzeń.

Filtrowanie nie zmienia zawartości dziennika i nie naprawia przyczyny błędu. Ukrywa jedynie wpisy, które nie spełniają podanych kryteriów. Trzeba również odróżniać komunikat ostrzegawczy od błędu oraz sprawdzać wpisy sąsiadujące czasowo. Pojedynczy komunikat o nieudanym połączeniu może być skutkiem wcześniejszego zatrzymania usługi, problemu z DNS, braku miejsca na dysku albo niedostępności systemu uwierzytelniania. Dlatego sam tekst znaleziony w wyszukiwarce nie powinien być interpretowany bez kontekstu zdarzeń poprzedzających i następujących po nim.

Dziennik błędów SQL Server i pliki archiwalne

SQL Server zapisuje informacje diagnostyczne w swoim dzienniku błędów. Po ponownym uruchomieniu usługi bieżący plik nie musi być jedynym źródłem informacji, ponieważ wcześniejsze wpisy mogą znajdować się w plikach archiwalnych oznaczonych kolejnymi numerami. Z poziomu T-SQL można wymusić rozpoczęcie nowego dziennika poleceniem EXEC sys.sp_cycle_errorlog;. Operacja zamyka bieżący plik i tworzy następny, ale nie rozwiązuje problemu technicznego oraz może utrudnić analizę, jeżeli zostanie wykonana przed zabezpieczeniem istotnych wpisów.

W Log File Viewer należy sprawdzić, czy analizowana jest właściwa instancja i właściwy typ logu. W środowisku SQL Server mogą występować osobno komunikaty silnika bazy danych, wpisy SQL Server Agent oraz zdarzenia systemu Windows. Ścieżka pliku dziennika błędów SQL Server jest ustalana przez konfigurację uruchomieniową usługi; parametr startowy -e wskazuje lokalizację pliku error log. Samo okno Management Studio nie gwarantuje dostępu do wszystkich logów Windows, ponieważ odczyt części dzienników wymaga odpowiednich praw systemowych i zależy od ustawień audytu.

Wykorzystanie odczytu logów podczas diagnostyki instancji

Log File Viewer pomaga ustalić kolejność zdarzeń, ale diagnoza wymaga zestawienia logów z innymi danymi: stanem usługi SQL Server, konfiguracją instancji, obciążeniem zasobów i wynikami zapytań administracyjnych. Wpis o błędzie 823, 824 lub 825 może wskazywać na problemy z podsystemem wejścia i wyjścia, lecz wymaga weryfikacji stanu dysków, kontrolera, systemu plików i kopii zapasowych. Komunikat o nieudanym logowaniu trzeba rozpatrywać razem z nazwą konta, typem uwierzytelniania oraz konfiguracją dostępu do instancji.

Podczas dokumentowania usterki warto zapisać nazwę serwera, nazwę instancji, przedział czasu, dokładną treść komunikatu i identyfikator procesu lub sesji, jeżeli został pokazany. Przydatne jest również zachowanie powiązanych wpisów z kilku minut przed i po zdarzeniu. Tak przygotowany materiał pozwala porównać awarie powtarzalne z incydentami jednorazowymi, sprawdzić, czy problem pojawia się po restarcie usługi lub zadaniu agenta, oraz ocenić, czy konieczne jest dalsze badanie konfiguracji albo sprzętu serwera.