SQL Server XEvent Profiler

XEvent Profiler to uproszczony interfejs Extended Events w SSMS, następca klasycznego SQL Server Profiler.

Rola SQL Server XEvent Profiler w monitorowaniu instancji

SQL Server XEvent Profiler jest funkcją programu SQL Server Management Studio (SSMS), która upraszcza uruchamianie i obserwowanie sesji Extended Events. Extended Events to wbudowany mechanizm rejestrowania zdarzeń generowanych przez aparat SQL Server, między innymi rozpoczęcia i zakończenia zapytań, wywołań procedur, błędów, blokad, zakleszczeń oraz zmian stanu połączeń. XEvent Profiler udostępnia te informacje przez interfejs graficzny SSMS, bez konieczności ręcznego budowania całej definicji sesji.

Mechanizm działa na poziomie konkretnej instancji SQL Server, do której połączono SSMS. Nie jest osobnym silnikiem śledzenia, usługą systemową ani niezależnym agentem instalowanym na komputerze. Interfejs tworzy lub uruchamia sesję Extended Events, a następnie otwiera podgląd zdarzeń na żywo. Dane pochodzą więc z infrastruktury XEvents działającej w SQL Server, a SSMS pełni rolę narzędzia konfiguracyjnego i wizualizacyjnego.

Sesje, zdarzenia i filtry dostępne w XEvent Profiler

W XEvent Profiler można wybrać gotowy scenariusz monitorowania, na przykład sesję ukierunkowaną na zapytania języka Transact-SQL albo bardziej ogólny profil aktywności serwera. Zakres obserwacji zależy od użytych zdarzeń, predykatów i akcji. Zdarzenie opisuje konkretny typ aktywności silnika, natomiast predykat ogranicza liczbę rejestrowanych wystąpień, na przykład do zapytań wykonywanych przez określoną aplikację, użytkownika lub bazę danych.

Wyniki są prezentowane w oknie podglądu danych na żywo. Administrator może analizować między innymi tekst instrukcji, czas rozpoczęcia, czas trwania, identyfikator sesji, nazwę bazy danych, nazwę aplikacji oraz informacje o błędzie, o ile dane pole jest dostarczane przez wybrane zdarzenie. Przy diagnostyce blokad szczególne znaczenie ma zdarzenie deadlock, które przedstawia informacje o zakleszczeniu wykrytym przez silnik. XEvent Profiler nie rekonstruuje jednak zdarzeń, które nie zostały objęte konfiguracją aktywnej sesji.

Sesje Extended Events mogą zapisywać dane do bufora pamięci albo do pliku zdarzeń. Podgląd na żywo korzysta z danych dostępnych podczas działania sesji i nie powinien być traktowany jako pełne, długoterminowe archiwum aktywności. Przy analizie problemu występującego okresowo właściwsze jest skonfigurowanie sesji z docelowym plikiem oraz ograniczeniem zdarzeń do potrzebnego zakresu. Zbyt szeroki profil zwiększa ilość danych i utrudnia odróżnienie istotnych zdarzeń od normalnego ruchu.

Uprawnienia i ograniczenia diagnostyki przez SSMS

Możliwość uruchomienia lub zmiany sesji Extended Events zależy od uprawnień przyznanych na instancji SQL Server. Do tworzenia sesji na poziomie serwera potrzebne jest uprawnienie obejmujące zarządzanie sesjami Extended Events, takie jak ALTER ANY EVENT SESSION, albo uprawnienia administracyjne zapewniające ten zakres. Samo posiadanie dostępu do bazy danych nie oznacza automatycznie prawa do monitorowania całej instancji.

Zakres informacji widocznych w podglądzie może również zależeć od uprawnień do obserwowania stanu serwera oraz od wersji SQL Server i SSMS. Nazwy dostępnych zdarzeń, pól i akcji są związane z konkretną wersją silnika, dlatego konfigurację należy sprawdzić na właściwej instancji, a nie tylko w dokumentacji dotyczącej innego wydania. Jeżeli sesja nie rejestruje oczekiwanego zdarzenia, przyczyną może być nieprawidłowy filtr, brak wymaganych uprawnień, zatrzymana sesja albo fakt, że wybrany profil nie obejmuje danego typu aktywności.

XEvent Profiler nie zastępuje analizy planów wykonania, widoków dynamicznego zarządzania ani dziennika błędów SQL Server. Pokazuje zdarzenia zarejestrowane przez aktywną sesję, ale nie wyjaśnia samodzielnie, dlaczego zapytanie korzysta z nieefektywnego planu, skąd wynika wzrost obciążenia dysków ani czy problem jest skutkiem konfiguracji sprzętowej. Wyniki trzeba zestawić z czasem wystąpienia problemu, obciążeniem procesora, opóźnieniami wejścia-wyjścia, blokadami i działaniem aplikacji klienckiej.

Praktyczne wykorzystanie XEvent Profiler przy awarii SQL Server

Podczas diagnostyki warto najpierw określić objaw i przedział czasu, a dopiero potem uruchomić profil obejmujący potrzebne zdarzenia. Dla wolnych operacji przydatne są zdarzenia zawierające czas trwania i tekst instrukcji. Dla błędów należy uwzględnić zdarzenia raportujące wyjątki lub błędy silnika. Dla zakleszczeń trzeba przeanalizować dane deadlock, w tym zasoby oraz procesy uczestniczące w konflikcie. Sam fakt pojawienia się zapytania na liście nie dowodzi jeszcze, że było ono przyczyną awarii; trzeba porównać jego czas wykonania i kontekst z innymi zdarzeniami.

Po zakończeniu obserwacji sesję należy zatrzymać albo ograniczyć jej zakres, jeżeli nie jest już potrzebna. Stałe rejestrowanie dużej liczby zdarzeń może zwiększać zużycie pamięci, generować dodatkowe operacje zapisu i utrudniać analizę. Bezpieczniejsza konfiguracja obejmuje selektywny wybór zdarzeń, filtr po bazie, aplikacji lub czasie trwania oraz ustalenie sposobu obsługi pełnego bufora. Przy pracy na systemie produkcyjnym zmiany powinny być wykonywane w uzgodnionym oknie diagnostycznym i dokumentowane.

Jeżeli komputer z SSMS nie pokazuje danych, trzeba rozdzielić problem interfejsu od problemu silnika. Należy sprawdzić, czy połączenie wskazuje właściwą instancję, czy sesja jest uruchomiona, czy wybrano prawidłowy profil oraz czy konto ma wymagane uprawnienia. Warto również zweryfikować, czy zdarzenie rzeczywiście wystąpiło po uruchomieniu sesji, ponieważ XEvent Profiler nie odtwarza automatycznie zdarzeń sprzed rozpoczęcia monitorowania. Tak uporządkowane dane mogą następnie posłużyć do oceny zapytań, blokad, błędów konfiguracji i zachowania aplikacji korzystających z SQL Server.