XE – skrót od Extended Events

XE to powszechnie stosowany skrót od Extended Events, mechanizmu zbierania zdarzeń diagnostycznych SQL Server.

XE jako mechanizm Extended Events w SQL Server

XE jest skrótem od Extended Events, czyli mechanizmu diagnostycznego dostępnego w Microsoft SQL Server. Służy do przechwytywania informacji o zdarzeniach zachodzących w silniku bazy danych. Zdarzeniem może być między innymi wykonanie instrukcji Transact-SQL, zakończenie procedury składowanej, wystąpienie błędu, blokowanie zasobu, oczekiwanie na zasób albo zmiana stanu określonego komponentu silnika. Extended Events nie jest osobnym silnikiem bazy danych ani narzędziem do przechowywania tabel użytkownika. Jest częścią infrastruktury monitorowania i diagnostyki SQL Server.

Konfiguracja XE opiera się na sesji zdarzeń, zwanej event session. Sesja określa, jakie zdarzenia mają być obserwowane, jakie dodatkowe dane mają zostać do nich dołączone oraz gdzie zebrane informacje będą zapisywane. W praktyce pozwala to ograniczyć obserwację do konkretnego problemu, na przykład błędów o określonym numerze, zapytań wykonywanych przez wskazaną aplikację albo instrukcji przekraczających ustalony próg czasu. Dzięki filtrom można zmniejszyć ilość danych i ograniczyć wpływ monitorowania na działanie serwera.

Budowa sesji zdarzeń i zakres zbieranych danych

Sesja Extended Events składa się przede wszystkim ze zdarzeń, predykatów, akcji i celu zapisu. Zdarzenie opisuje sytuację wykrywaną przez SQL Server, natomiast predykat określa warunek, po którego spełnieniu zdarzenie zostanie zapisane. Przykładowo filtr może obejmować identyfikator bazy danych, nazwę aplikacji, nazwę użytkownika, tekst instrukcji lub czas trwania operacji, o ile konkretne zdarzenie udostępnia odpowiednią właściwość. Akcja dodaje do zdarzenia dodatkowy kontekst, taki jak identyfikator sesji, identyfikator zapytania, adres planu wykonania lub nazwa hosta.

Dane z sesji są przekazywane do celu, czyli obiektu odbierającego zdarzenia. Często używanym celem jest event_file, który zapisuje dane do plików przeznaczonych do późniejszej analizy. ring_buffer przechowuje zdarzenia w pamięci w formacie XML, dlatego nadaje się głównie do krótkotrwałej obserwacji i analizy bieżącego stanu. W zależności od wersji SQL Server oraz konfiguracji dostępne są także inne cele, między innymi histogram służący do agregowania wartości oraz mechanizmy przydatne przy analizie dopasowanych par zdarzeń. Wybór celu wpływa na trwałość danych, sposób ich odczytu i zużycie zasobów.

Sesję można utworzyć poleceniem CREATE EVENT SESSION, zmienić za pomocą ALTER EVENT SESSION, a następnie uruchomić lub zatrzymać. Sesja utworzona w zakresie serwera jest widoczna w katalogu sys.server_event_sessions. Informacje o sesjach działających w danej chwili można sprawdzać za pomocą widoku dynamicznego sys.dm_xe_sessions, a informacje o aktywnych celach między innymi przez sys.dm_xe_session_targets. Do odczytu konfiguracji i danych potrzebne są odpowiednie uprawnienia, których zakres zależy od rodzaju wykonywanej operacji oraz wersji SQL Server.

Wykorzystanie XE przy szukaniu przyczyn problemów

Extended Events jest przydatne wtedy, gdy sam komunikat błędu albo ogólny pomiar wydajności nie wskazuje przyczyny problemu. Sesja może rejestrować wystąpienia błędów wraz z numerem, poziomem i treścią komunikatu. Przy analizie opóźnień można obserwować zdarzenia związane z wykonaniem zapytań i zapisywać informacje o czasie trwania, zużyciu procesora, liczbie odczytanych stron lub liczbie zapisanych stron, jeśli takie pola są dostępne dla wybranego zdarzenia. W przypadku blokowania można zestawić identyfikator sesji, zasób i czas oczekiwania z innymi informacjami z SQL Server.

Ważne jest odróżnienie danych zdarzenia od danych dodawanych przez akcje. Nie każda akcja jest dostępna dla każdego zdarzenia, a nie każda właściwość zdarzenia opisuje ten sam etap wykonania operacji. Rejestrowanie pełnego tekstu instrukcji, planów wykonania lub dużej liczby dodatkowych pól może zwiększyć ilość danych i koszt monitorowania. Z tego powodu sesję projektuje się pod konkretne pytanie diagnostyczne. Jeżeli celem jest znalezienie zapytań przekraczających próg czasu, filtr powinien ograniczać zdarzenia według czasu trwania albo innych właściwości, zamiast zapisywać wszystkie operacje wykonywane przez silnik.

W SQL Server Management Studio sesje XE można tworzyć i przeglądać przy użyciu graficznego interfejsu, ale konfiguracja może być również zapisana jako skrypt Transact-SQL. Analiza plików celu event_file wymaga odczytania zapisanych zdarzeń i uwzględnienia zakresu czasowego oraz ustawień rotacji plików. Dane z ring_buffer należy traktować jako bufor ograniczony rozmiarem, ponieważ starsze zdarzenia mogą zostać zastąpione przez nowsze. Sama obecność sesji nie oznacza jeszcze, że rejestrowane są właściwe informacje; trzeba sprawdzić jej stan, wybrane zdarzenia, predykaty, akcje i cel.

XE a inne sposoby obserwacji SQL Server

Extended Events zastąpiło w wielu zastosowaniach starszy mechanizm SQL Trace i narzędzie SQL Server Profiler. Nie oznacza to jednak, że każda konfiguracja XE jest automatycznie poprawna albo że każda analiza powinna obejmować wszystkie możliwe zdarzenia. XE działa na poziomie zdarzeń udostępnianych przez SQL Server, dlatego wynik zależy od wybranej definicji sesji. Do oceny bieżących liczników, blokad i aktywnych żądań mogą być potrzebne także widoki dynamiczne, takie jak widoki dotyczące żądań, sesji, oczekiwań i transakcji. XE dostarcza śladu konkretnych zdarzeń, ale nie zastępuje całego modelu monitorowania instancji.

Przy interpretacji danych trzeba zachować zgodność między zdarzeniem, akcją i wnioskiem. Na przykład identyfikator sesji pozwala powiązać zdarzenie z połączeniem, ale nie musi samodzielnie wyjaśniać, dlaczego operacja była wolna. Czas trwania jednej instrukcji nie jest tym samym co czas całego żądania aplikacji, a wystąpienie oczekiwania nie musi oznaczać awarii. Rzetelna diagnoza wymaga zestawienia danych z XE z konfiguracją sesji, tekstem zapytania, planem wykonania, stanem zasobów i kolejnością zdarzeń. Należy również sprawdzić, czy sesja była uruchomiona w czasie występowania problemu oraz czy jej filtry nie pominęły istotnych przypadków.

W środowisku SQL Server warto dokumentować cel sesji, zakres przechwytywanych zdarzeń, zastosowane filtry, lokalizację plików i sposób zakończenia monitorowania. Po zakończeniu diagnostyki niepotrzebna sesja może generować zbędne dane, dlatego jej stan i przeznaczenie powinny być świadomie zarządzane. Poprawnie zaprojektowane XE pomaga odtworzyć przebieg problemu na podstawie konkretnych zdarzeń, ale jakość wniosku zależy od prawidłowego doboru obserwowanych elementów oraz ostrożnej interpretacji wyników.