Rejestrowanie zdarzeń SQL w systemie

Rejestrowanie zdarzeń SQL w systemie obejmuje zapis komunikatów silnika w dzienniku aplikacji Windows.

Zakres rejestrowania zdarzeń SQL w systemie Windows

Rejestrowanie zdarzeń SQL polega na zapisywaniu komunikatów generowanych przez silnik bazy danych, sterownik albo warstwę aplikacyjną w dzienniku zdarzeń systemu Windows. W zależności od konfiguracji mogą tam trafiać informacje o uruchomieniu i zatrzymaniu usługi, błędach połączeń, nieudanych operacjach zapisu lub odczytu, przekroczeniu limitów czasu oraz problemach z plikami bazy danych. Dziennik nie przechowuje automatycznie całej treści wykonywanych zapytań. Zakres zapisu zależy od ustawień konkretnego silnika, aplikacji i mechanizmu integrującego komunikaty z usługą Windows Event Log.

W standardowym narzędziu Podgląd zdarzeń takie wpisy są zwykle dostępne w dzienniku „Application”, czyli „Aplikacja”. Każde zdarzenie może zawierać między innymi datę i godzinę, poziom ważności, nazwę źródła, identyfikator zdarzenia, nazwę komputera oraz opis komunikatu. Nazwa źródła wskazuje komponent, który przekazał wpis do dziennika. Przy analizie trzeba odróżnić komunikaty generowane przez sam silnik SQL od ostrzeżeń pochodzących z aplikacji korzystającej z bazy.

Jak odczytywać wpisy z dziennika Aplikacja

Podstawowym miejscem analizy jest Podgląd zdarzeń systemu Windows. Po otwarciu gałęzi „Dzienniki systemu Windows” i wybraniu „Aplikacja” można filtrować wpisy według poziomu, zakresu czasu, źródła oraz identyfikatora zdarzenia. Poziom „Informacje” opisuje prawidłowe działania lub zmiany stanu, „Ostrzeżenie” sygnalizuje sytuację wymagającą uwagi, a „Błąd” wskazuje nieudaną operację albo stan, który może wpływać na działanie systemu. Sam poziom zdarzenia nie określa jeszcze przyczyny problemu, dlatego należy czytać pełny opis i porównywać go z innymi wpisami z tego samego okresu.

Istotna jest kolejność zdarzeń. Na przykład błąd połączenia aplikacji z bazą może być skutkiem wcześniejszego zatrzymania usługi silnika, braku dostępnego pliku, błędu uwierzytelniania albo chwilowego przeciążenia. Pojedynczy wpis nie zawsze pokazuje pełny przebieg awarii. Pomocne jest zestawienie czasu zdarzenia SQL z dziennikiem „System”, stanem usługi bazy danych oraz logami aplikacji. Jeżeli kilka komponentów zapisuje czas w różnych strefach lub korzysta z niesynchronizowanych zegarów, kolejność komunikatów może być trudniejsza do ustalenia.

Co można ustalić na podstawie komunikatów SQL

Logi pozwalają rozpoznać, czy problem powstaje podczas startu silnika, na etapie nawiązywania połączenia, przy wykonywaniu operacji na danych, czy podczas zamykania usługi. Komunikat o odmowie dostępu może wskazywać na brak uprawnień konta usługi do katalogu z plikami bazy lub do zasobu systemowego. Informacja o niedostępności pliku może wiązać się z błędną ścieżką, usunięciem pliku, odłączeniem dysku albo brakiem miejsca. Z kolei powtarzające się przekroczenia czasu operacji mogą wskazywać na blokady, przeciążenie procesora, wolny nośnik danych albo błędną konfigurację limitu czasu w aplikacji.

Wpisy trzeba interpretować zgodnie z dokumentacją używanego silnika i aplikacji. Identyfikator zdarzenia ma znaczenie dopiero razem z nazwą źródła, pełnym tekstem komunikatu i kontekstem wykonania. Nie należy zakładać, że każdy błąd zapisany w dzienniku Aplikacja oznacza uszkodzenie samej bazy. Źródłem problemu może być sterownik, biblioteka klienta, usługa systemowa, konfiguracja sieciowa albo program, który nieprawidłowo obsługuje odpowiedź serwera SQL. Przydatne jest zachowanie oryginalnego wpisu wraz z identyfikatorem, czasem wystąpienia i informacjami o powiązanych zdarzeniach.

Konfiguracja, retencja i diagnostyka wpisów

Skuteczność rejestrowania zależy od tego, czy zapisywanie komunikatów jest włączone i czy dziennik ma wystarczającą pojemność. Dziennik Windows ma określony maksymalny rozmiar oraz sposób postępowania po jego zapełnieniu. Przy ustawieniu nadpisywania starszych zdarzeń nowe wpisy mogą usunąć informacje potrzebne do analizy wcześniejszej awarii. Przy ustawieniu blokowania zapisu system może przestać przyjmować kolejne komunikaty. Dlatego podczas diagnostyki należy sprawdzić właściwości dziennika, czas przechowywania wpisów i to, czy w badanym okresie nie doszło do nadpisania danych.

Zmiany konfiguracji logowania powinny być wykonywane ostrożnie, ponieważ większa szczegółowość może zwiększyć liczbę wpisów i zużycie miejsca. Warto ustalić przedział czasu, źródła zdarzeń oraz rodzaje komunikatów potrzebne do rozwiązania konkretnego problemu. Jeżeli komunikaty SQL nie pojawiają się w dzienniku Aplikacja, należy sprawdzić stan usługi Windows Event Log, konfigurację używanego silnika, uprawnienia konta usługi oraz to, czy dany komponent rzeczywiście obsługuje zapis do systemowego dziennika Windows. Dopiero po potwierdzeniu tych warunków można uznać brak wpisów za istotną informację diagnostyczną.