START EVENT SESSION

START EVENT SESSION uruchamia zdefiniowaną wcześniej sesję Extended Events, rozpoczynając zbieranie zdarzeń.

Uruchomienie sesji Extended Events w SQL Server

START EVENT SESSION oznacza rozpoczęcie działania wcześniej utworzonej sesji Extended Events w Microsoft SQL Server. Sama definicja sesji określa, jakie zdarzenia mają być obserwowane, jakie predykaty ograniczają ich wybór oraz gdzie zostaną zapisane zebrane dane. Uruchomienie nie tworzy nowej sesji i nie zmienia jej konfiguracji. Powoduje jedynie przejście istniejącej sesji do stanu aktywnego, w którym aparat Extended Events zaczyna reagować na występujące zdarzenia silnika.

W przypadku sesji o zasięgu instancji SQL Server typowa instrukcja ma postać ALTER EVENT SESSION [NazwaSesji] ON SERVER STATE = START;. Polecenie wykonuje się w bazie, z której dostępne jest zarządzanie sesjami serwera, a nazwa w nawiasach kwadratowych musi odpowiadać rzeczywiście istniejącej sesji. Jeżeli sesja nie została wcześniej utworzona albo jej definicja zawiera błąd, samo uruchomienie nie doprowadzi do prawidłowego zbierania danych.

Co dzieje się po zmianie stanu na START

Po uruchomieniu SQL Server aktywuje wybrane obiekty sesji: zdarzenia, predykaty, akcje oraz cel przechowywania danych. Zdarzenie może opisywać między innymi wykonanie zapytania, błąd, blokowanie, zmianę oczekiwania lub operację związaną z użyciem zasobów. Akcje dołączone do zdarzenia uzupełniają rekord o dodatkowe informacje, na przykład identyfikator sesji, nazwę bazy danych albo tekst instrukcji, o ile dana akcja jest dostępna dla konkretnego zdarzenia.

Ważnym elementem jest cel sesji, czyli obiekt odbierający zdarzenia. Często stosowanym celem jest event_file, który zapisuje dane do plików z rozszerzeniem .xel. Innym celem może być ring_buffer, przechowujący ograniczoną liczbę informacji w pamięci. Po rozpoczęciu pracy sesji zdarzenia mogą być kierowane do celu zgodnie z jego konfiguracją, dlatego brak oczekiwanych rekordów nie zawsze oznacza, że sesja nie działa. Przyczyną może być brak zdarzeń spełniających predykat, nieprawidłowa ścieżka pliku, zbyt mały bufor albo odczytywanie niewłaściwego celu.

Kontrola aktywności i odczyt zebranych zdarzeń

Stan sesji można sprawdzić w katalogowych widokach zarządzania SQL Server. Widok sys.server_event_sessions przedstawia definicje sesji o zasięgu serwera, natomiast sys.dm_xe_sessions pokazuje sesje aktualnie uruchomione. Po wykonaniu polecenia startującego nazwa sesji powinna być widoczna w drugim z tych widoków. W razie potrzeby można także użyć interfejsu SQL Server Management Studio, gdzie stan sesji jest prezentowany przy jej nazwie.

Dla celu plikowego dane odczytuje się funkcją sys.fn_xe_file_target_read_file, wskazującą pliki XEL oraz ewentualne pliki pomocnicze. Przykładowy odczyt może wyglądać tak: SELECT event_data FROM sys.fn_xe_file_target_read_file(N'C:\XE\sesja*.xel', NULL, NULL, NULL);. Zwracana kolumna zawiera dane XML, więc do analizy konkretnego zdarzenia trzeba wyodrębnić nazwę zdarzenia, czas wystąpienia i interesujące pola. Ścieżka musi istnieć z punktu widzenia systemu operacyjnego serwera, a konto usługi SQL Server musi mieć odpowiednie uprawnienia do zapisu.

Bezpieczne zatrzymanie i zastosowanie w diagnostyce

Sesja pozostaje aktywna do czasu jej zatrzymania albo do zakończenia pracy instancji, zależnie od konfiguracji uruchamiania. Zatrzymanie sesji o zasięgu serwera wykonuje się poleceniem ALTER EVENT SESSION [NazwaSesji] ON SERVER STATE = STOP;. Zatrzymanie nie usuwa definicji sesji ani wcześniej zapisanych plików XEL. Pozwala więc zachować konfigurację i później uruchomić ją ponownie bez tworzenia wszystkich zdarzeń od początku.

W praktycznej diagnostyce SQL Server uruchomienie sesji powinno być poprzedzone sprawdzeniem zakresu zbieranych danych. Szeroka sesja z wieloma zdarzeniami i dodatkowymi akcjami może generować duży narzut oraz szybko zapełnić skonfigurowany cel. Lepiej ograniczyć obserwację predykatami, na przykład do konkretnej bazy, identyfikatora sesji, czasu trwania lub rodzaju błędu, a po zebraniu materiału zatrzymać sesję i przeanalizować wynik. Przy diagnostyce środowiska serwerowego istotne jest także zapisanie nazwy sesji, czasu uruchomienia, wersji SQL Server oraz konfiguracji celu, ponieważ bez tych informacji późniejsze porównanie wyników może być niejednoznaczne.