Widok sys.dm_xe_objects

sys.dm_xe_objects zwraca listę dostępnych obiektów Extended Events, w tym zdarzeń i akcji.

Widok sys.dm_xe_objects jako katalog obiektów Extended Events

Widok sys.dm_xe_objects stanowi katalog elementów dostępnych w mechanizmie Extended Events w Microsoft SQL Server. Służy do sprawdzania, jakie obiekty można wykorzystać podczas tworzenia sesji diagnostycznej, analizowania aktywnej konfiguracji oraz porównywania możliwości różnych instancji. W wynikach można znaleźć między innymi zdarzenia, akcje, cele, predykaty, typy danych i inne składniki rozpoznawane przez silnik Extended Events.

Znaczenie tego widoku polega na tym, że nie trzeba opierać konfiguracji wyłącznie na pamięci administratora ani na przykładach przygotowanych dla innej wersji SQL Server. Dostępne obiekty mogą różnić się zależnie od wersji silnika, zainstalowanych składników oraz kontekstu, w którym wykonywane jest zapytanie. Odczyt katalogu pozwala więc ustalić, czy konkretna nazwa zdarzenia lub akcji rzeczywiście występuje w danym środowisku.

Widok jest dynamicznym widokiem zarządzania, dlatego odczytywane informacje opisują możliwości aktualnie działającego silnika. Nie należy traktować go jak tabeli przeznaczonej do ręcznej modyfikacji. Wartości powinny być odczytywane za pomocą zapytań diagnostycznych, a sama konfiguracja sesji powinna być wykonywana przez instrukcje Extended Events.

Widok sys.dm_xe_objects a typy obiektów i ich zastosowanie

Jedną z najważniejszych kolumn jest object_type, która pomaga rozpoznać rodzaj zwracanego elementu. W zależności od wersji SQL Server mogą pojawić się między innymi obiekty typu event, action, target, pred_source, type oraz inne kategorie wewnętrzne. Dzięki tej klasyfikacji można ograniczyć wynik do elementów potrzebnych w konkretnym zadaniu, na przykład wyświetlić wyłącznie zdarzenia albo wyłącznie akcje możliwe do dołączenia do zdarzeń.

Obiekt typu zdarzenie opisuje moment lub sytuację obserwowaną przez silnik, taką jak wykonanie instrukcji, błąd, oczekiwanie, zmiana konfiguracji albo zakończenie określonej operacji. Akcja dostarcza dodatkowych informacji rejestrowanych w chwili wystąpienia zdarzenia, przykładowo identyfikatora sesji, nazwy bazy danych, nazwy użytkownika lub tekstu instrukcji, jeżeli dana akcja jest obsługiwana przez wybrane zdarzenie. Cel określa sposób przechowywania przechwyconych danych, na przykład w pamięci, w pliku albo w buforze pierścieniowym.

Przy analizie katalogu istotne są również pola opisujące nazwę, pakiet, obszar funkcjonalny, dostępność oraz właściwości obiektu. Nazwa techniczna powinna być traktowana dokładnie, ponieważ w konfiguracji sesji znaczenie ma pełna nazwa obiektu, a nie tylko jej fragment. W praktyce przydatne jest filtrowanie po name, object_type i description, gdy opis jest dostępny.

W porównaniu z dawnie stosowanym SQL Trace, Extended Events oferuje bardziej szczegółowy dobór zdarzeń, akcji, filtrów i celów, a także możliwość ograniczenia obciążenia przez precyzyjne predykaty. Widok sys.dm_xe_objects pomaga ustalić, jakie elementy są dostępne przed rozpoczęciem projektowania sesji. Nie zastępuje jednak dokumentacji konkretnego zdarzenia, ponieważ sam fakt obecności obiektu nie oznacza, że każda akcja pasuje do każdego zdarzenia.

Widok sys.dm_xe_objects przy typowych problemach diagnostycznych

Najczęstszy problem polega na próbie użycia nazwy zdarzenia znalezionej w przykładzie przygotowanym dla innej wersji SQL Server. Zapytanie do sys.dm_xe_objects pozwala szybko sprawdzić, czy nazwa występuje w bieżącej instalacji. Jeżeli wynik jest pusty, przyczyną może być inna wersja silnika, literówka, niewłaściwy typ obiektu albo ograniczenie wynikające z użytego kontekstu bezpieczeństwa.

Innym problemem jest wybór akcji, która nie jest dostępna dla danego zdarzenia. Sama akcja może znajdować się w katalogu, ale nie musi być dozwolona w połączeniu z każdym zdarzeniem. Przygotowując sesję, należy sprawdzić zarówno listę obiektów, jak i metadane opisujące powiązania oraz właściwości. Pominięcie tego etapu może zakończyć się błędem podczas tworzenia sesji albo uzyskaniem niepełnych danych.

Trudności pojawiają się także wtedy, gdy wynik jest interpretowany bez rozróżnienia obiektów publicznych i technicznych. Katalog może zawierać elementy przydatne głównie dla wewnętrznej diagnostyki silnika. Nie każdy wpis powinien być automatycznie umieszczany w produkcyjnej sesji. Przed użyciem należy ocenić częstotliwość występowania zdarzenia, koszt zbierania dodatkowych akcji, rozmiar danych oraz sposób ich odczytu.

W przypadku braku danych w oczekiwanym widoku warto zweryfikować uprawnienia, nazwę bazy, połączenie z właściwą instancją oraz wersję serwera. Przydatne jest także porównanie wyników z widokami sys.dm_xe_sessions i sys.dm_xe_session_targets, które pokazują aktywne sesje oraz przypisane do nich cele. Dzięki temu można odróżnić brak dostępnego obiektu od sytuacji, w której obiekt istnieje, lecz nie został wykorzystany w żadnej aktywnej sesji.

Widok sys.dm_xe_objects w praktyce zapytań kontrolnych

Podstawowe zapytanie może ograniczać wynik do nazw i typów obiektów:

SELECT name, object_type, description
FROM sys.dm_xe_objects
ORDER BY object_type, name;

Takie zestawienie jest pomocne podczas rozpoznawania środowiska, ale przy większej liczbie wpisów lepiej stosować filtr. Przykładowo, aby wyszukać obiekty związane z określonym fragmentem nazwy, można użyć warunku LIKE. Warto pamiętać, że opis może być pusty, a nazwa może nie zawierać wszystkich słów kojarzonych z danym problemem diagnostycznym.

Do wyszukiwania zdarzeń można zastosować zapytanie podobne do poniższego:

SELECT name, description
FROM sys.dm_xe_objects
WHERE object_type = N'event'
ORDER BY name;

Jeżeli potrzebne są akcje, należy zmienić filtr na odpowiednią wartość. W praktyce warto zapisać wynik przed zmianą wersji serwera lub przed migracją konfiguracji, a następnie porównać go z wynikiem uzyskanym po zmianie. Taka kontrola ujawnia różnice w nazwach, dostępności i zakresie funkcji bez konieczności zgadywania, dlaczego wcześniejszy skrypt nie działa.

Nie należy kopiować całego katalogu do sesji tylko dlatego, że obiekty są dostępne. Sesja powinna zbierać dane odpowiadające konkretnemu pytaniu diagnostycznemu. Jeżeli celem jest analiza długich zapytań, trzeba dobrać zdarzenia i akcje związane z czasem wykonania, planem, bazą oraz sesją. Jeżeli celem jest analiza błędów, bardziej przydatne będą zdarzenia opisujące wyjątki i niepowodzenia. Ograniczony zakres zwykle ułatwia późniejszą interpretację i zmniejsza ilość niepotrzebnych danych.

Widok sys.dm_xe_objects i praktyczne wskazówki bezpieczeństwa

Przed uruchomieniem sesji Extended Events powinno się określić zakres obserwacji, przewidywany czas działania oraz sposób zakończenia zbierania danych. Długotrwałe monitorowanie bez filtrów może generować duże ilości informacji, zwłaszcza gdy wybrane zdarzenie występuje często. Widok sys.dm_xe_objects pomaga przygotować listę dostępnych elementów, ale nie ocenia samodzielnie wpływu konfiguracji na obciążenie.

Warto testować konfigurację na ograniczonym zakresie i sprawdzać, czy przechwytywane dane rzeczywiście odpowiadają potrzebie. Przydatne jest rozpoczęcie od zdarzeń o mniejszej częstotliwości, dodanie tylko niezbędnych akcji oraz zastosowanie predykatów ograniczających wynik. Dane zawierające tekst instrukcji, identyfikatory użytkowników lub nazwy obiektów powinny być przechowywane zgodnie z zasadami dostępu obowiązującymi w danym środowisku.

Podczas porównywania obiektów między instancjami trzeba uwzględnić nie tylko samą wersję SQL Server, lecz także aktualizacje, poziom zgodności bazy oraz dostępne składniki. Identyczna nazwa w katalogu nie gwarantuje identycznego zestawu pól ani identycznego zachowania. Przed wdrożeniem skryptu na innym serwerze zalecane jest ponowne odczytanie metadanych i wykonanie krótkiego testu.

Wyniki sys.dm_xe_objects można wykorzystać jako część dokumentacji technicznej. Przy każdej sesji warto zapisać cel monitorowania, użyte zdarzenia, akcje, predykaty, cel zapisu oraz sposób odczytu wyników. Taka dokumentacja ułatwia odtworzenie konfiguracji, ocenę jej przydatności i bezpieczne wyłączenie sesji po zakończeniu analizy.

Widok sys.dm_xe_objects a moment zgłoszenia problemu

Po widok sys.dm_xe_objects warto sięgnąć wtedy, gdy nie jest jasne, czy określone zdarzenie lub akcja jest dostępne w używanej wersji SQL Server, gdy skrypt sesji zgłasza błąd albo gdy wyniki monitorowania nie zawierają oczekiwanych informacji. Jest to również dobry punkt wyjścia przy tworzeniu procedury diagnostycznej, która ma działać na kilku różnych instalacjach.

Jeżeli problem może wynikać z awarii sprzętu, uszkodzenia systemu, błędów nośnika lub nieprawidłowego działania komputera używanego do obsługi serwera baz danych, przydatna może być konsultacja techniczna z firmą Warszawskie Pogotowie Komputerowe 24/7. Przed przekazaniem sprzętu warto zabezpieczyć kopie danych, opisać objawy, zanotować komunikaty oraz wskazać, czy problem pojawił się po aktualizacji, zmianie konfiguracji lub przerwie w zasilaniu.

Wnioski z katalogu Extended Events powinny być łączone z obserwacją dzienników, parametrów systemu i zachowania aplikacji. Sam widok sys.dm_xe_objects pokazuje dostępne elementy, lecz nie wskazuje automatycznie przyczyny awarii. Najlepszy efekt daje połączenie poprawnie dobranej sesji, ograniczonych filtrów, czytelnej dokumentacji i ostrożnej interpretacji zebranych danych.