sys.dm_xe_session_events

sys.dm_xe_session_events zwraca listę zdarzeń zarejestrowanych w danej sesji Extended Events.

sys.dm_xe_session_events jako element sesji Extended Events

sys.dm_xe_session_events jest widokiem dynamicznym SQL Server, który pozwala sprawdzić, jakie zdarzenia zostały przypisane do określonej sesji Extended Events. Zdarzenie w tym kontekście oznacza zdefiniowany punkt obserwacji działania silnika, na przykład wykonanie instrukcji, wystąpienie błędu, zmianę stanu połączenia albo zakończenie określonej operacji. Sam widok nie pokazuje pełnej historii zdarzeń i nie zastępuje pliku docelowego, bufora pierścieniowego ani innego mechanizmu przechowywania danych. Jego zadaniem jest opis konfiguracji sesji, a nie odczyt zapisanych wystąpień zdarzeń.

W praktyce widok przydaje się przede wszystkim podczas sprawdzania, czy sesja została skonfigurowana zgodnie z założeniami. Można dzięki niemu potwierdzić, że wybrane zdarzenie rzeczywiście należy do sesji, odczytać ustawione predykaty oraz przeanalizować opcje związane z przechwytywaniem danych. Jest to szczególnie ważne wtedy, gdy sesja działa, lecz nie dostarcza oczekiwanych informacji. Przyczyną może być niepoprawny filtr, brak interesującego zdarzenia w definicji albo ograniczenie zakresu zbieranych pól.

Widok odnosi się do metadanych sesji Extended Events. Wiersz opisuje powiązanie sesji z konkretnym zdarzeniem, dlatego jedna sesja może zwrócić wiele wierszy, a ta sama definicja zdarzenia może występować w różnych sesjach. Odczyt nie powinien być interpretowany jako lista zdarzeń, które faktycznie wystąpiły w czasie pracy systemu. Jest to lista zdarzeń zarejestrowanych w konfiguracji danej sesji.

sys.dm_xe_session_events w kontekście diagnostyki SQL Server

Extended Events służy do obserwowania działania silnika przy mniejszym narzucie niż starsze mechanizmy śledzenia, jednak skuteczność obserwacji zależy od poprawnej konfiguracji. sys.dm_xe_session_events tworzy jeden z punktów kontrolnych takiej konfiguracji. Najpierw warto ustalić nazwę sesji, następnie sprawdzić, czy sesja istnieje i czy zawiera zdarzenie odpowiadające badanemu problemowi. Dopiero później można analizować miejsce docelowe oraz odczytane dane.

Ważne jest rozróżnienie pomiędzy nazwą sesji, nazwą zdarzenia i nazwą pakietu. Sesja jest kontenerem konfiguracji. Zdarzenie definiuje moment, który ma zostać przechwycony. Pakiet grupuje elementy rozszerzeń i udostępnia ich opis. W zapytaniach diagnostycznych łatwo pomylić te poziomy, zwłaszcza gdy nazwa zdarzenia jest podobna do nazwy pakietu lub gdy korzysta się z narzędzia graficznego, które ukrywa część szczegółów.

W odróżnieniu od tabel użytkownika widoki dynamiczne mogą prezentować stan zależny od aktualnej instancji i uprawnień. Oznacza to, że brak oczekiwanego wiersza nie zawsze dowodzi, że obiekt nie istnieje w dokumentacji albo że sesja była źle zaprojektowana. Należy uwzględnić nazwę instancji, wersję SQL Server, dostępne pakiety oraz poziom uprawnień konta wykonującego zapytanie. Przy porównywaniu środowisk warto sprawdzać nie tylko same nazwy, lecz również predykaty, akcje i konfigurację celu.

sys.dm_xe_session_events jest więc odpowiednikiem spisu elementów obserwacyjnych, a nie dziennika pomiarowego. Jeżeli potrzebne jest ustalenie, jakie zdarzenia rzeczywiście wystąpiły, należy odczytać odpowiedni cel sesji. Dopiero połączenie informacji o konfiguracji z zapisanymi wystąpieniami pozwala ocenić, czy problem nie pojawia się, czy też jest odfiltrowywany albo nie jest utrwalany w oczekiwany sposób.

sys.dm_xe_session_events a porównanie konfiguracji sesji

Przy porównywaniu dwóch sesji Extended Events widok sys.dm_xe_session_events może ujawnić różnice, których nie widać na pierwszy rzut oka. Jedna sesja może zawierać to samo zdarzenie co druga, lecz mieć inny predykat, inny zestaw akcji dodatkowych albo inną konfigurację celu. Sama obecność zdarzenia nie oznacza więc identycznego sposobu zbierania informacji.

Przykładowo sesja przeznaczona do analizy błędów może przechwytywać zdarzenia tylko dla wybranej bazy danych, aplikacji lub identyfikatora sesji. Sesja o szerszym zakresie może rejestrować więcej danych, lecz generować większy narzut i większy wolumen zapisu. Z kolei sesja ustawiona z bardzo restrykcyjnym warunkiem może pozostać aktywna, ale nie zapisać żadnego pasującego wystąpienia. Analiza sys.dm_xe_session_events pomaga wykryć, czy filtr jest przypisany do właściwego zdarzenia i czy jest odczytywany w odpowiednim kontekście.

Warto również odróżnić pola zdarzenia od akcji dołączanych podczas przechwytywania. Pola opisują dane naturalnie związane z danym zdarzeniem, natomiast akcje mogą dostarczać dodatkowy kontekst, taki jak identyfikator połączenia, nazwa aplikacji lub tekst instrukcji. Zbyt mały zestaw informacji utrudnia późniejsze ustalenie przyczyny, a zbyt szeroki może zwiększyć obciążenie i rozmiar danych. Dlatego porównanie konfiguracji powinno obejmować pełną definicję, a nie wyłącznie nazwę zdarzenia.

Przy migracji albo odtwarzaniu sesji z jednej instancji na drugą należy zweryfikować dostępność zdarzeń i pól. Definicje mogą różnić się między wersjami produktu, edycjami lub zainstalowanymi składnikami. Jeżeli skrypt tworzący sesję kończy się błędem, pomocne jest sprawdzenie metadanych dostępnych w danym środowisku oraz ponowne odczytanie sys.dm_xe_session_events po utworzeniu sesji. Taka kontrola ogranicza ryzyko uznania za działającą sesji, która formalnie została uruchomiona, lecz nie obserwuje właściwego zjawiska.

sys.dm_xe_session_events przy typowych problemach z obserwacją

Jednym z częstych problemów jest przekonanie, że aktywna sesja musi zawierać właściwe zdarzenie. Stan uruchomienia mówi tylko, że mechanizm pracuje. Nie potwierdza, że wybrano odpowiedni punkt obserwacji ani że warunki filtrowania pozwalają zobaczyć interesujące przypadki. Odczyt sys.dm_xe_session_events pozwala rozpocząć kontrolę od podstawowej listy zdarzeń przypisanych do sesji.

Innym problemem jest analiza nie tej sesji, której dotyczy badanie. W środowisku może działać kilka sesji o podobnych nazwach, tworzonych do różnych celów. Przed wyciągnięciem wniosków trzeba ustalić dokładną nazwę, stan oraz konfigurację celu. Dobrą praktyką jest używanie jednoznacznych nazw i dokumentowanie przeznaczenia każdej sesji. W zapytaniach warto jawnie filtrować po nazwie sesji, zamiast zakładać kolejność wierszy albo domyślne sortowanie wyników.

Może też wystąpić rozbieżność między widokiem konfiguracji a zawartością celu. Jeżeli sesję zmodyfikowano, część danych w celu może pochodzić z wcześniejszego ustawienia. W takim przypadku należy odnotować moment zmiany, wyczyścić lub wymienić cel zgodnie z przyjętą procedurą i dopiero potem przeprowadzić kontrolowany test. Bez tego stare oraz nowe zdarzenia mogą zostać odczytane razem, co utrudnia ocenę rezultatu.

Problemy z brakiem danych mogą wynikać także z ograniczeń uprawnień, niezgodności nazwy zdarzenia, błędnego predykatu, braku odpowiedniego pola albo niewłaściwego celu. Każdą hipotezę najlepiej sprawdzać osobno. Najpierw należy potwierdzić obecność zdarzenia w sys.dm_xe_session_events, potem skontrolować warunki, następnie stan sesji i na końcu zawartość celu. Takie rozdzielenie etapów zmniejsza ryzyko przypisania przyczyny niewłaściwemu elementowi.

sys.dm_xe_session_events i praktyczne wskazówki przed zgłoszeniem

Przed rozpoczęciem analizy warto zapisać cel diagnostyczny prostym zdaniem: jakie zjawisko ma zostać zauważone, w jakim czasie i dla jakiego zakresu obiektów. Następnie należy dobrać możliwie precyzyjne zdarzenie, ograniczyć zakres filtrem i wybrać tylko te dodatkowe dane, które będą potrzebne do interpretacji. Po utworzeniu sesji odczyt sys.dm_xe_session_events powinien być jednym z pierwszych testów kontrolnych.

Przydatne jest zachowanie zapytania, wyniku kontrolnego oraz informacji o wersji SQL Server. W dokumentacji można zanotować nazwę sesji, przypisane zdarzenia, warunki, akcje i cel. Dzięki temu późniejsze porównanie jest szybsze, a osoba przejmująca diagnostykę nie musi odtwarzać założeń wyłącznie na podstawie bieżącego stanu.

Nie należy uruchamiać szerokiego przechwytywania bez określenia czasu i kryteriów zakończenia. Sesja obserwacyjna powinna mieć jasno opisany zakres, ponieważ nadmiar danych utrudnia analizę tak samo jak ich brak. Po zakończeniu testu warto sprawdzić, czy zapisane informacje odpowiadają pytaniu diagnostycznemu, a następnie ocenić, czy sesja powinna pozostać aktywna.

Jeżeli analiza dotyczy komputera, na którym działa narzędzie bazodanowe, a problem może wynikać również z konfiguracji systemu, sprzętu albo połączeń, można skorzystać z pomocy serwisu Warszawskie Pogotowie Komputerowe 24/7. Przed zgłoszeniem dobrze przygotować opis objawu, moment jego występowania, podstawowe wyniki zapytań oraz informację, czy problem jest stały, czy pojawia się sporadycznie. Tak przygotowany materiał ułatwia rozdzielenie problemu konfiguracji SQL Server od problemu środowiska, w którym działa komputer.

Najważniejsza zasada pozostaje prosta: sys.dm_xe_session_events odpowiada na pytanie, jakie zdarzenia przypisano do sesji, lecz nie odpowiada samodzielnie na pytanie, co wydarzyło się w systemie. Pełna diagnoza wymaga zestawienia konfiguracji z predykatami, akcjami, stanem sesji oraz rzeczywistymi danymi zapisanymi przez wybrany cel.