Extended Events

Extended Events to lekki, wydajny mechanizm SQL Server służący do rejestrowania i diagnostyki zdarzeń serwera.

Extended Events w architekturze SQL Server

Extended Events to wbudowany w Microsoft SQL Server mechanizm obserwowania zdarzeń zachodzących w silniku bazy danych. Służy do rejestrowania informacji potrzebnych podczas diagnozowania problemów z wydajnością, błędami zapytań, blokadami, przekroczeniami czasu wykonania oraz zachowaniem poszczególnych komponentów serwera. Mechanizm działa na poziomie silnika SQL Server, dlatego nie jest ogólnym narzędziem systemu Windows ani niezależnym monitorem dowolnej bazy danych.

Podstawowym elementem konfiguracji jest sesja Extended Events. Sesja określa, jakie zdarzenia mają być przechwytywane, jakie dane dodatkowe należy do nich dołączyć, jakie warunki filtrowania zastosować oraz gdzie zapisywać wyniki. Zdarzenie opisuje konkretną sytuację wykrytą przez silnik, na przykład zakończenie wykonywania instrukcji, wystąpienie błędu albo oczekiwanie związane z blokadą. Dzięki filtrom można ograniczyć rejestrowanie do określonej bazy danych, nazwy aplikacji, identyfikatora sesji lub czasu trwania operacji.

Sesja, zdarzenie, predykat i cel zapisu

Sesja Extended Events korzysta z obiektów dostępnych w konkretnej instalacji i wersji SQL Server. Zdarzenia są wybierane z katalogu metadanych silnika, a ich szczegółowy zestaw pól zależy od definicji danego zdarzenia. Do zdarzenia można dołączyć tak zwane actions, czyli dodatkowe informacje zbierane w momencie jego wystąpienia, na przykład identyfikator procesu serwera, nazwę bazy danych, nazwę aplikacji, login lub tekst instrukcji. Actions nie są tym samym co pola podstawowe zdarzenia.

Warunek ograniczający liczbę rejestrowanych zdarzeń nazywa się predykatem. Przykładowo sesja może zapisywać tylko instrukcje, których wykonanie trwało dłużej od określonego progu, albo tylko zdarzenia związane z wybraną bazą. Wyniki trafiają do celu, czyli targetu. Często używanym targetem jest event_file, zapisujący dane w plikach rozszerzenia .xel. Innym sposobem obserwacji jest ring_buffer, który przechowuje zdarzenia w pamięci serwera, lecz jego zawartość ma charakter nietrwały i może zostać utracona po ponownym uruchomieniu instancji lub wyczerpaniu przydzielonego bufora.

Analiza plików XEL i dobór zakresu rejestracji

Pliki zapisane przez target event_file można analizować w SQL Server Management Studio albo odczytywać za pomocą funkcji systemowej sys.fn_xe_file_target_read_file. Funkcja ta zwraca między innymi nazwę pliku, numer pliku, numer zdarzenia oraz dane zdarzenia w formacie XML. XML zawiera nazwę zdarzenia, czas jego wystąpienia, pola zdarzenia i wartości zebranych actions. Podczas analizy należy uwzględnić, że pojedyncza sesja może tworzyć wiele plików, zgodnie z ustawieniami maksymalnego rozmiaru pliku i liczby plików przechowywanych przez target.

Skuteczna konfiguracja wymaga dobrania zdarzeń do konkretnego problemu. Rejestrowanie bardzo dużej liczby zdarzeń, zwłaszcza bez predykatów i bez ograniczenia zbieranych actions, może zwiększać obciążenie procesora, pamięci masowej oraz samego mechanizmu diagnostycznego. Z drugiej strony zbyt wąski filtr może pominąć informacje potrzebne do odtworzenia przebiegu błędu. Przed uruchomieniem sesji warto ustalić, czy celem jest analiza długich zapytań, deadlocków, błędów, kompilacji planów, wykorzystania zasobów czy problemu występującego tylko w określonym kontekście.

Wykorzystanie Extended Events przy diagnozie SQL Server

Extended Events jest narzędziem diagnostycznym dla administratora i osoby analizującej działanie instancji SQL Server. Może pomóc ustalić, kiedy wystąpiło zdarzenie, którego bazy dotyczyło, jaka sesja je wywołała oraz jakie parametry towarzyszyły problemowi. W przypadku deadlocków używa się zdarzeń dostarczających opis konfliktu blokad. Przy analizie powolnych instrukcji przydatne są zdarzenia zawierające czas trwania, zużycie procesora, liczbę odczytów logicznych lub tekst wykonywanej instrukcji, o ile dane te zostały wybrane w konfiguracji sesji.

Podczas diagnostyki należy odróżniać fakt zarejestrowania zdarzenia od przyczyny problemu. Sam wpis informujący o długim wykonaniu nie dowodzi jeszcze, że winne jest konkretne urządzenie, dysk albo sieć. Wymagana jest korelacja czasu zdarzenia z logami SQL Server, stanem systemu operacyjnego, obciążeniem zasobów, planem wykonania i konfiguracją aplikacji. Po zakończeniu zbierania danych sesję należy ocenić pod kątem dalszej przydatności, ponieważ niepotrzebne sesje diagnostyczne i zbyt szerokie zakresy rejestracji utrudniają analizę oraz zwiększają ilość danych do przechowywania.