Polecenie CREATE EVENT SESSION tworzy sesję rozszerzonych zdarzeń wykorzystywaną do diagnostyki serwera SQL.
Rola polecenia CREATE EVENT SESSION w SQL Server
CREATE EVENT SESSION jest poleceniem języka T-SQL używanym w Microsoft SQL Server do zdefiniowania sesji Extended Events, czyli mechanizmu rejestrowania wybranych zdarzeń zachodzących w silniku bazy danych. Sesja określa, jakie zdarzenia mają być obserwowane, jakie dane kontekstowe należy zebrać, jakie warunki filtrowania zastosować oraz gdzie zapisać wyniki. Samo utworzenie sesji nie uruchamia jeszcze zbierania zdarzeń. Po wykonaniu polecenia sesja pozostaje zatrzymana, dopóki administrator nie zmieni jej stanu.
Sesja może być utworzona na poziomie serwera za pomocą klauzuli ON SERVER. W takim przypadku może obserwować zdarzenia dotyczące instancji SQL Server, w tym aktywności wielu baz danych. W środowiskach obsługujących sesje o zakresie bazy danych stosuje się również ON DATABASE, lecz dostępne zdarzenia, uprawnienia i możliwości zależą od konkretnej edycji oraz wersji SQL Server. Definicja sesji jest przechowywana w metadanych silnika, a jej konfigurację można później zmieniać poleceniem ALTER EVENT SESSION.
Elementy definicji sesji Extended Events
Podstawowa definicja wskazuje co najmniej nazwę sesji i jedno zdarzenie dodane przez klauzulę ADD EVENT. Zdarzenie należy podać wraz z nazwą pakietu, na przykład sqlserver.sql_statement_completed albo sqlserver.rpc_completed. Pierwsze z nich dotyczy zakończenia wykonania instrukcji języka SQL, a drugie zakończenia wywołania procedury zdalnej, typowego między innymi dla komunikacji aplikacji z SQL Server. Dokładny zestaw zdarzeń zależy od wersji silnika i zainstalowanych pakietów. Listę dostępnych zdarzeń można sprawdzić w widoku katalogowym sys.dm_xe_objects, filtrując obiekty typu event.
Przy zdarzeniu można zdefiniować akcje oraz predykaty. Akcje rozszerzają zapis o dodatkowe informacje, takie jak identyfikator sesji, nazwa aplikacji, nazwa hosta, tekst instrukcji lub identyfikator użytkownika. Predykat, zapisany w klauzuli WHERE, ogranicza rejestrowanie do sytuacji spełniających warunek, na przykład do określonej bazy danych, czasu trwania albo identyfikatora sesji. Ograniczenie zbieranych danych ma znaczenie praktyczne, ponieważ rejestrowanie bardzo często występujących zdarzeń bez filtrów może zwiększyć zużycie procesora, pamięci i operacji wejścia-wyjścia.
Wyniki sesji są kierowane do obiektów docelowych przez klauzulę ADD TARGET. Target package0.event_file zapisuje zdarzenia do pliku, który można później odczytać funkcją sys.fn_xe_file_target_read_file. Target package0.ring_buffer przechowuje dane w pamięci w postaci bufora cyklicznego, więc starsze wpisy mogą zostać nadpisane po zapełnieniu bufora. Inne targety, takie jak package0.histogram, służą do agregowania wartości, a nie do zachowania pełnej historii każdego zdarzenia. Wybór targetu powinien odpowiadać celowi diagnostycznemu i przewidywanej ilości danych.
Uruchamianie, odczyt i kontrola zebranych danych
Po utworzeniu sesję uruchamia się osobnym poleceniem ALTER EVENT SESSION nazwa ON SERVER STATE = START, a zatrzymuje przez ustawienie STATE = STOP. Jeżeli sesja ma działać po ponownym uruchomieniu usługi SQL Server, można użyć opcji STARTUP_STATE = ON w definicji sesji. Ta opcja nie oznacza natychmiastowego startu; określa zachowanie podczas kolejnego uruchomienia instancji. Stan aktywnych sesji można sprawdzić w sys.dm_xe_sessions, natomiast definicje sesji utworzonych na poziomie serwera znajdują się w sys.server_event_sessions.
Przykładowa sesja diagnostyczna może rejestrować zakończone zapytania trwające co najmniej określony czas, dodawać tekst instrukcji oraz nazwę bazy danych i zapisywać dane do pliku. Warto pamiętać, że jednostki używane w predykatach muszą odpowiadać dokumentacji danego zdarzenia. Dla zdarzeń związanych z czasem trwania SQL Server często przekazuje wartość w mikrosekundach, dlatego warunek dla jednej sekundy może wymagać wartości 1000000, a nie 1000. Błędne przyjęcie jednostki prowadzi do sesji, która rejestruje za dużo albo za mało zdarzeń.
Plik zdarzeń można analizować po zatrzymaniu sesji lub równolegle z jej działaniem. Przy konfiguracji targetu plikowego określa się między innymi ścieżkę pliku, maksymalny rozmiar pojedynczego pliku oraz liczbę plików przechowywanych w ramach mechanizmu rollover. Ścieżka musi być dostępna dla konta usługi SQL Server, a nie tylko dla administratora uruchamiającego narzędzie. W przeciwnym razie sesja może zostać utworzona, lecz zapis do targetu zakończy się błędem. Dane z bufora pierścieniowego odczytuje się z pamięci sesji, lecz ten target nie jest odpowiedni do długotrwałego przechowywania kompletnej historii.
Uprawnienia, obciążenie i bezpieczne użycie
Utworzenie sesji o zakresie serwera wymaga odpowiednich uprawnień administracyjnych, w szczególności uprawnienia ALTER ANY EVENT SESSION na serwerze. Uprawnienia do tworzenia sesji o zakresie bazy danych są odrębne i zależą od kontekstu wykonania oraz wersji SQL Server. Samo posiadanie prawa do odczytu danych z bazy nie daje automatycznie możliwości tworzenia sesji Extended Events. Przy diagnostyce należy także ocenić uprawnienia do odczytu plików wynikowych i do wykonywania zapytań w widokach systemowych.
Sesję powinno się projektować pod konkretny problem: blokowanie, błędy, nieudane logowania, długie zapytania, zakleszczenia albo nadmierny czas kompilacji. Rejestrowanie zdarzeń o wysokiej częstotliwości, zwłaszcza z akcjami zwracającymi pełny tekst instrukcji, może generować znaczny strumień danych. Filtry powinny być możliwie selektywne, a sesja testowa powinna mieć jasno określony czas działania. Po zakończeniu diagnostyki sesję można zatrzymać, zmodyfikować lub usunąć poleceniem DROP EVENT SESSION, aby nie pozostawić niepotrzebnego obciążenia instancji.
W praktyce nie należy utożsamiać obecności definicji w sys.server_event_sessions z faktycznym działaniem monitoringu. Pierwszy widok opisuje konfigurację, natomiast sys.dm_xe_sessions pokazuje sesje uruchomione w pamięci. Również brak plików wynikowych nie musi oznaczać braku zdarzeń, jeśli sesja używa targetu pamięciowego albo zapis nie może zostać wykonany z powodu problemu ze ścieżką. Poprawna weryfikacja obejmuje sprawdzenie definicji, stanu sesji, konfiguracji targetu i rzeczywistego odczytu zebranych danych.
