Serwisanci dostępni teraz · czynne całą dobę, także w weekendy i świętaWarszawa i okolice · dojazd bezpłatny
Darmowa diagnoza laptopa
Darmowa diagnoza laptopa
Dojazd do klienta bezpłatnie
Dojazd do klienta bezpłatnie
Laptopy zastępcze bezpłatnie
Laptopy zastępcze bezpłatnie
Odbiór i zwrot sprzętu bezpłatnie
Odbiór i zwrot sprzętu bezpłatnie

system_health

Termin Definicja
system_health

system_health to domyślna sesja Extended Events uruchamiana automatycznie przy starcie każdej instancji.

Czym jest sesja system_health w SQL Server

system_health to wbudowana sesja Extended Events dostępna w silniku Microsoft SQL Server. Extended Events jest mechanizmem śledzenia zdarzeń wykonywanych przez silnik, takich jak błędy, zakleszczenia, problemy z planowaniem zadań, nietypowe oczekiwania oraz wybrane ostrzeżenia dotyczące zasobów. Sesja jest tworzona podczas instalacji instancji i standardowo uruchamiana automatycznie przy starcie SQL Server. Jej zadaniem jest zebranie podstawowych informacji diagnostycznych bez konieczności wcześniejszego projektowania własnego monitoringu.

Nie jest to test kondycji systemu operacyjnego ani raport opisujący stan każdego podzespołu komputera. Nazwa wskazuje na obserwowanie istotnych zdarzeń wewnątrz aparatu SQL Server. Sesja działa w tle i zapisuje ograniczony wycinek aktywności, dlatego jej dane należy interpretować razem z dziennikiem błędów SQL Server, logami systemu Windows, informacjami o stanie dysków oraz wynikami zapytań diagnostycznych.

Jakie zdarzenia rejestruje system_health

Zakres sesji obejmuje między innymi wybrane błędy silnika, w tym poważne błędy o wysokim poziomie ważności, informacje o problemach z pamięcią oraz sygnały dotyczące działania schedulerów SQL Server. W konfiguracji domyślnej rejestrowane są także zdarzenia związane z zakleszczeniami, czyli sytuacjami, w których co najmniej dwie transakcje wzajemnie oczekują na zasoby zablokowane przez drugą stronę. Szczególnie przydatny jest event xml_deadlock_report, ponieważ zawiera graficznie interpretowalny opis uczestników zakleszczenia, blokad i wybranej ofiary.

Sesja może również zawierać informacje o długotrwałych blokadach, nieoczekiwanych zakończeniach połączeń, błędach systemu plików oraz innych zdarzeniach uznanych przez producenta za istotne dla ogólnej diagnostyki instancji. Dokładny zestaw eventów i predykatów zależy od wersji SQL Server oraz od tego, czy administrator zmodyfikował sesję. Z tego powodu przed analizą warto sprawdzić jej rzeczywistą definicję w katalogu systemowym, zamiast zakładać, że każda instancja ma identyczną konfigurację.

Odczyt danych z bufora i plików XEL

Wyniki system_health są przechowywane w celach diagnostycznych przez cele Extended Events. Domyślna konfiguracja wykorzystuje bufor pierścieniowy oraz pliki zdarzeń Extended Events z rozszerzeniem .xel. Bufor pierścieniowy przechowuje ograniczoną liczbę najnowszych danych w pamięci, więc starsze wpisy mogą zostać zastąpione. Pliki XEL umożliwiają odczyt zapisanych zdarzeń po czasie wystąpienia problemu, ale również podlegają limitom rozmiaru i liczby zachowywanych plików.

Do analizy można użyć widoków katalogowych, na przykład sys.dm_xe_sessions i sys.dm_xe_session_targets, aby sprawdzić, czy sesja działa oraz jakie ma cele. Zawartość plików XEL odczytuje się funkcją sys.fn_xe_file_target_read_file, wskazując ścieżkę plików i wzorzec nazw. Przy interpretacji należy uwzględnić czas serwera, filtrację eventów, identyfikator sesji, nazwę bazy danych, identyfikator procesu oraz informacje o zasobie. Sam fakt wystąpienia wpisu nie dowodzi jeszcze awarii; konieczne jest ustalenie, czy zdarzenie było przyczyną problemu, jego skutkiem, czy tylko równoczesnym sygnałem ostrzegawczym.

Wykorzystanie system_health w diagnostyce instancji

system_health jest punktem wyjścia przy badaniu nagłego zatrzymania usługi, powtarzających się błędów zapytań, zakleszczeń i nieprawidłowości związanych z pamięcią lub schedulerami. Kolejność zdarzeń pomaga porównać moment pojawienia się błędu z rozpoczęciem blokowania, zmianą obciążenia i komunikatami w error logu. W przypadku deadlocka XML może wskazać konkretne transakcje, typy blokad i obiekty, ale nie zastępuje analizy kodu aplikacji oraz kolejności uzyskiwania blokad. W przypadku błędów pamięci trzeba dodatkowo rozróżnić pamięć przydzielaną przez SQL Server od pamięci dostępnej dla całego systemu.

Podczas przeglądu technik powinien sprawdzić, czy sesja jest uruchomiona, czy nie została wyłączona oraz czy nie zmieniono jej celów albo filtrów. Wyłączenie sesji usuwa jedno z domyślnych źródeł informacji, natomiast jej nadmierne rozszerzenie może zwiększyć ilość rejestrowanych danych i utrudnić selekcję właściwych zdarzeń. system_health nie naprawia blokad, nie optymalizuje zapytań i nie potwierdza sprawności sprzętu. Dostarcza śladów, które trzeba zestawić z konfiguracją SQL Server, planami wykonania, metrykami zasobów i objawami zgłoszonymi przez użytkowników.

+48 22 100 48 29Zadzwoń teraz · serwisant w 1 godzinę