System Health Session

System Health Session to domyślna, zawsze aktywna sesja Extended Events zbierająca podstawowe dane diagnostyczne.

Rola sesji System Health Session w SQL Server

System Health Session, znana w dokumentacji SQL Server jako sesja system_health, jest domyślną sesją Extended Events uruchamianą przez aparat bazy danych. Extended Events to wbudowany mechanizm obserwowania zdarzeń zachodzących w silniku SQL Server. Sesja jest tworzona i włączana automatycznie, dlatego podstawowe dane diagnostyczne mogą być dostępne bez wcześniejszego projektowania własnej konfiguracji monitorowania.

Zakres zbieranych informacji obejmuje między innymi błędy o wysokim poziomie ważności, informacje o zakleszczeniach, problemy z planowaniem pracy zadań oraz wybrane sygnały wskazujące na przeciążenie lub nieprawidłowe działanie silnika. Nie jest to pełny dziennik wszystkich zapytań wykonywanych na serwerze. System Health Session ma dostarczać krótkiego obrazu stanu instancji i pomóc wskazać kierunek dalszej analizy, a nie zastępować profilowanie obciążenia ani szczegółowy audyt zapytań.

Jakie zdarzenia trafiają do system_health

Jednym z najważniejszych zastosowań tej sesji jest rejestrowanie zakleszczeń. SQL Server publikuje informacje o zakleszczeniu w postaci zdarzenia xml_deadlock_report, które zawiera graf zależności między procesami i zasobami. Na jego podstawie można ustalić, które transakcje wzajemnie oczekiwały na blokady, jaki typ zasobu był objęty konfliktem oraz który proces został wybrany jako ofiara zakleszczenia. Taki materiał jest bardziej użyteczny niż sam komunikat o błędzie, ponieważ pokazuje relacje między uczestnikami zdarzenia.

Sesja rejestruje również wybrane błędy silnika, w tym zdarzenia error_reported spełniające warunki zdefiniowane w konfiguracji system_health. W praktyce można tam znaleźć informacje o poważnych problemach z działaniem instancji, ostrzeżenia dotyczące zasobów oraz dane związane z diagnostyką wewnętrznych komponentów SQL Server. W konfiguracji występują także zdarzenia używane do obserwowania pracy schedulerów, blokowania procesów, oczekiwania na pamięć i długotrwałych operacji, jednak dokładny zestaw oraz predykaty mogą różnić się między wersjami SQL Server.

Ważnym ograniczeniem jest selektywny charakter sesji. Brak wpisu w system_health nie oznacza, że w instancji nie wystąpiło żadne zdarzenie, lecz tylko że zdarzenie nie należało do monitorowanego zakresu, nie spełniło predykatu albo zostało usunięte w wyniku ograniczonej pojemności celu. Dlatego diagnostyka powinna uwzględniać także SQL Server Error Log, dzienniki systemu operacyjnego, konfigurację blokowania procesów oraz dane z innych narzędzi Extended Events.

Odczyt danych z celów Extended Events

System Health Session wykorzystuje cele Extended Events przeznaczone do przechowywania wyników sesji. Dane mogą być dostępne w buforze pierścieniowym oraz w plikach zdarzeń XEL, zależnie od wersji SQL Server i aktualnej definicji sesji. Bufor pierścieniowy przechowuje ograniczoną liczbę najnowszych wpisów w pamięci. Po zapełnieniu starsze informacje są zastępowane nowszymi, więc nie powinien być traktowany jako archiwum długoterminowe.

Stan sesji można sprawdzić w widoku dynamicznym sys.dm_xe_sessions, natomiast jej definicję zapisano w katalogowym widoku sys.server_event_sessions. W tych miejscach można potwierdzić, czy sesja istnieje, czy jest włączona, jakie zdarzenia obserwuje oraz jakie cele zostały przypisane. Podczas analizy trzeba odróżnić definicję sesji od jej bieżącego stanu: wpis w sys.server_event_sessions potwierdza konfigurację, ale nie musi oznaczać, że sesja aktualnie działa.

Pliki XEL można odczytywać za pomocą funkcji tabelowej sys.fn_xe_file_target_read_file, podając ścieżkę do plików celu event_file. Wynik zawiera między innymi nazwę zdarzenia, czas jego wystąpienia oraz dokument XML z atrybutami i akcjami zarejestrowanymi przez sesję. Przy interpretacji należy zachować oryginalną strefę czasową i kolejność zdarzeń, a także sprawdzić, czy kilka wpisów nie opisuje tego samego incydentu. Powtarzające się komunikaty mogą wynikać z jednego problemu obserwowanego przez różne komponenty.

Wykorzystanie sesji podczas analizy awarii SQL Server

Analizę warto rozpocząć od określenia przedziału czasu, w którym wystąpiła awaria, spowolnienie albo utrata dostępności. Następnie należy wyszukać zdarzenia xml_deadlock_report, poważne wpisy error_reported, informacje o schedulerach oraz zdarzenia wskazujące na blokowanie lub oczekiwanie na zasoby. Sam czas wystąpienia nie dowodzi jeszcze przyczyny problemu. Trzeba porównać go z logiem błędów SQL Server, obciążeniem procesora, dostępnością pamięci, opóźnieniami dyskowymi i stanem połączeń aplikacyjnych.

Przy podejrzeniu zakleszczenia należy przeanalizować graf XML, a nie tylko nazwę zdarzenia. Istotne są identyfikatory sesji, typy blokad, kolejność uzyskiwania zasobów i zapytania wykonywane przez uczestniczące transakcje. Przy podejrzeniu blokowania trzeba sprawdzić, czy długie oczekiwanie wynika z otwartej transakcji, braku odpowiedniego indeksu, dużej operacji modyfikującej dane czy przeciążenia zasobu. System Health Session pomaga uchwycić symptomy, ale decyzja o zmianie zapytania, indeksu lub konfiguracji wymaga dodatkowych dowodów.

Podczas serwisowej diagnostyki instancji SQL Server należy zachować kopię dostępnych plików XEL przed ich nadpisaniem oraz odnotować wersję silnika, czas rozpoczęcia problemu i zmiany wykonane w tym okresie. Trzeba też zweryfikować, czy domyślna sesja nie została wyłączona, zmodyfikowana albo ograniczona przez ręczną zmianę celu. Prawidłowo zinterpretowane dane z system_health pozwalają zawęzić obszar poszukiwań, lecz nie stanowią samodzielnego dowodu każdej diagnozy.