sys.dm_xe_session_targets

sys.dm_xe_session_targets pokazuje cele zdefiniowane dla aktywnej sesji Extended Events.

sys.dm_xe_session_targets jako widok celów sesji Extended Events

sys.dm_xe_session_targets to dynamiczny widok zarządzania dostępny w SQL Server, przeznaczony do odczytywania informacji o celach przypisanych do aktywnych sesji Extended Events. Cel, określany także jako target, odbiera dane generowane przez zdarzenia zarejestrowane w sesji. Może je przechowywać w pamięci, zapisywać w pliku albo udostępniać w innej formie zależnej od konfiguracji sesji. Sam widok nie służy do definiowania nowych zdarzeń ani do uruchamiania sesji. Umożliwia sprawdzenie, jakie cele są obecnie powiązane z działającą sesją oraz jakie właściwości opisują ich konfigurację.

W praktyce sys.dm_xe_session_targets jest używany razem z innymi widokami systemowymi Extended Events. Najczęściej łączy się go z sys.dm_xe_sessions, aby ustalić nazwę sesji, jej stan oraz czas uruchomienia, a także z sys.server_event_sessions, który zawiera definicje sesji zapisane w konfiguracji instancji. Taki zestaw pozwala rozróżnić konfigurację zaplanowaną od stanu faktycznie działającego w pamięci. Jest to istotne podczas diagnostyki, ponieważ zmiana definicji sesji nie zawsze oznacza, że identyczna konfiguracja została już uruchomiona.

Widok zwraca informacje o celach, a nie pełną zawartość zgromadzonych danych. Jeżeli celem jest plik, same rekordy zdarzeń należy odczytywać odpowiednimi funkcjami lub narzędziami dla plików Extended Events. Jeżeli zastosowano cel pamięciowy, dane mogą być dostępne przez mechanizmy właściwe dla danego typu celu. sys.dm_xe_session_targets pomaga więc ustalić, gdzie szukać wyników, jaki cel został użyty oraz z jakimi parametrami został uruchomiony.

sys.dm_xe_session_targets w kontekście konfiguracji i diagnostyki

Extended Events składa się z kilku współpracujących elementów: sesji, zdarzeń, predykatów, akcji oraz celów. Zdarzenie opisuje sytuację, która ma zostać zarejestrowana, akcja rozszerza zebrane informacje, a cel określa sposób ich przechowywania lub udostępniania. sys.dm_xe_session_targets znajduje się po stronie obserwacji aktywnego środowiska i pokazuje relację między uruchomioną sesją a jej celami. Dzięki temu można zweryfikować, czy analiza jest kierowana do właściwego miejsca.

Warto odróżnić ten widok od katalogowych widoków systemowych, które opisują definicje zapisane w metadanych. Widok dynamiczny odpowiada na pytanie, co jest aktualnie uruchomione, natomiast widok katalogowy pomaga sprawdzić, co zostało skonfigurowane. Różnica ma znaczenie po zmianach administracyjnych, ponownym uruchomieniu sesji albo wdrożeniu skryptu konfiguracyjnego. Przy porównywaniu obu źródeł można wykryć sytuację, w której cel istnieje w definicji, lecz nie jest obecny w uruchomionej sesji, albo odwrotnie.

Nie każdy cel działa według tego samego modelu. Cele buforujące dane w pamięci są przydatne przy krótkich obserwacjach i szybkiej analizie, ale ich zawartość może zostać utracona po zatrzymaniu sesji lub wyczerpaniu dostępnego bufora. Cele plikowe lepiej nadają się do dłuższej obserwacji, porównywania okresów i zachowania materiału do późniejszej analizy. Z kolei cel agregujący może ograniczać szczegółowość pojedynczych zdarzeń, ale za to zmniejszać ilość danych i ułatwiać ocenę częstotliwości występowania określonych sytuacji.

W porównaniu z klasycznym śledzeniem zdarzeń Extended Events pozwala precyzyjniej dobierać zakres obserwacji. Odpowiednio wybrane cele ograniczają narzut związany z gromadzeniem danych, lecz wymagają świadomego dopasowania do celu diagnostycznego. sys.dm_xe_session_targets nie jest zatem jedynie pomocniczym wykazem obiektów. Stanowi punkt kontrolny, w którym można sprawdzić, czy dane są kierowane do mechanizmu zgodnego z założeniami analizy.

sys.dm_xe_session_targets a typowe problemy z sesjami

Jednym z częstszych problemów jest brak oczekiwanych danych mimo uruchomionej sesji. Przyczyną może być niewłaściwie dobrany cel, nieaktywny cel, zbyt restrykcyjny filtr zdarzeń albo odczytywanie danych z innego miejsca niż to, które wskazuje konfiguracja. sys.dm_xe_session_targets pozwala rozpocząć sprawdzanie od podstawowej informacji: jakie cele są faktycznie przypisane do sesji działającej w danym momencie.

Inny problem pojawia się wtedy, gdy cel pamięciowy szybko traci starsze rekordy. Nie musi to oznaczać błędu sesji. Bufor może być nadpisywany, gdy napływ zdarzeń jest większy niż możliwości przechowywania. W takiej sytuacji należy ocenić częstotliwość zdarzeń, zastosowane predykaty, sposób dystrybucji buforów oraz przydatność innego celu. Sam odczyt z sys.dm_xe_session_targets może potwierdzić obecność celu, ale nie odpowie samodzielnie na pytanie, czy jego bufor jest wystarczający dla konkretnego scenariusza.

Problemy z celem plikowym mogą wynikać z lokalizacji, uprawnień, pełnego woluminu, ograniczeń zapisu albo różnicy między nazwą pliku zdefiniowaną w konfiguracji a miejscem, z którego próbuje się pobrać dane. Weryfikacja celu za pomocą sys.dm_xe_session_targets pomaga uniknąć analizy niewłaściwej sesji. Należy też pamiętać, że plik może być tworzony według schematu nazw i rozmiaru określonego przez ustawienia celu, dlatego jeden oczekiwany plik nie zawsze oznacza całość zgromadzonego materiału.

Na uwagę zasługuje również różnica między sesją uruchomioną a samą definicją sesji. Po edycji konfiguracji mogą wystąpić rozbieżności, jeżeli sesja nie została ponownie uruchomiona. Weryfikacja dynamicznych widoków zarządzania powinna wtedy poprzedzać wyciąganie wniosków z dokumentacji lub ze skryptu wdrożeniowego. Przydatne jest porównanie nazwy sesji, nazwy celu, typu celu oraz parametrów widocznych w aktualnym stanie.

sys.dm_xe_session_targets w praktyce odczytu danych

Najprostszy odczyt powinien ograniczać się do niezbędnych kolumn i obejmować tylko aktywne sesje. Przykładowe zapytanie może wyglądać następująco:

• SELECT s.name AS session_name, t.target_name, t.target_data FROM sys.dm_xe_session_targets AS t JOIN sys.dm_xe_sessions AS s ON t.event_session_address = s.address;

Znaczenie poszczególnych pól zależy od wersji SQL Server i rodzaju celu. Nazwa sesji pozwala przypisać wynik do konkretnej konfiguracji, nazwa celu wskazuje mechanizm odbioru danych, a właściwości celu zawierają informacje opisowe zapisane w formacie odpowiednim dla danego obiektu. Zawartość pola opisującego dane celu nie powinna być bezrefleksyjnie traktowana jako gotowa lista zdarzeń. W wielu przypadkach jest to struktura XML wymagająca dalszego odczytu, filtrowania lub interpretacji.

Przy analizie warto zachować kolejność: najpierw potwierdzenie, że sesja działa, następnie identyfikacja celu, później sprawdzenie jego parametrów, a dopiero na końcu odczyt zgromadzonych zdarzeń. Takie podejście zmniejsza ryzyko pomylenia sesji diagnostycznej z inną sesją o podobnej nazwie. Pomocne bywa także zapisanie wyniku kontrolnego przed rozpoczęciem testu oraz ponowienie odczytu po wystąpieniu badanego problemu.

Należy unikać uruchamiania wielu szerokich sesji jednocześnie bez wyraźnej potrzeby. Nadmiar zdarzeń może zwiększać obciążenie, utrudniać analizę i szybciej zapełniać cele buforujące. Lepsze rezultaty daje ograniczenie zakresu do konkretnych zdarzeń, dodanie warunków filtrujących oraz dobranie celu do przewidywanego czasu obserwacji. W przypadku dłuższego monitorowania należy uwzględnić rotację plików, dostępne miejsce i sposób archiwizacji.

Kiedy sprawdzać sys.dm_xe_session_targets w serwisie komputerowym

Weryfikacja sys.dm_xe_session_targets jest uzasadniona wtedy, gdy występują trudności z interpretacją danych Extended Events, sesja nie rejestruje oczekiwanych zdarzeń albo wyniki znikają szybciej, niż zakładano. Dotyczy to również sytuacji, w której konfiguracja została zmieniona, ale nie ma pewności, czy aktywny stan odpowiada nowym ustawieniom. Przed dalszą analizą warto zabezpieczyć definicję sesji, ustalić jej nazwę i sprawdzić aktualnie przypisane cele.

Jeżeli problem dotyczy konfiguracji, odczytu plików, uprawnień lub interpretacji danych, może być potrzebna kontrola całego środowiska, a nie tylko pojedynczego zapytania. W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić ocenę działania komputera i przygotowanie dalszych czynności serwisowych; naprawy są z reguły realizowane do 3 dni roboczych.

Przed zgłoszeniem warto zanotować moment wystąpienia problemu, nazwę sesji, użyty typ celu oraz objawy obserwowane w aplikacji lub systemie. Nie powinno się usuwać plików diagnostycznych ani zatrzymywać sesji bez potrzeby, ponieważ może to utrudnić odtworzenie przyczyny. Jeżeli dane są wrażliwe, należy przygotować tylko fragment niezbędny do analizy i usunąć informacje niezwiązane ze zgłoszeniem. Tak przygotowany materiał ułatwia rozpoznanie, czy problem wynika z konfiguracji Extended Events, ograniczeń środowiska, czy z innej usterki komputera.