Extended Events vs SQL Trace

Extended Events vs SQL Trace to porównanie nowszego mechanizmu diagnostyki ze starszym, opartym na technologii SQL Trace.

Różnica między Extended Events a SQL Trace w SQL Server

Extended Events i SQL Trace są mechanizmami śledzenia zdarzeń generowanych przez aparat Microsoft SQL Server, ale pochodzą z różnych etapów rozwoju tego silnika. SQL Trace jest starszą technologią, wykorzystywaną między innymi przez SQL Server Profiler oraz ślady uruchamiane po stronie serwera. Extended Events to nowszy, bardziej elastyczny system instrumentacji, zaprojektowany do rejestrowania zdarzeń przy mniejszym narzucie na pracę serwera i z większym wyborem warunków filtrowania oraz miejsc zapisu.

SQL Trace pozwala obserwować między innymi rozpoczęcia i zakończenia poleceń, wywołania procedur składowanych, logowania oraz błędy. W praktyce konfiguracja śladu opiera się na wyborze klas zdarzeń, kolumn danych, filtrów i miejsca docelowego. Extended Events korzysta z sesji, zdarzeń, predykatów, akcji oraz celów. Zdarzenie opisuje sytuację wykrytą przez silnik, akcja dołącza dodatkowe informacje, predykat ogranicza liczbę rejestrowanych przypadków, a cel określa sposób przechowywania danych.

Zakres danych i sposób filtrowania zdarzeń

W SQL Trace wybiera się określone kolumny dla wybranych klas zdarzeń, na przykład nazwę bazy danych, tekst polecenia, identyfikator sesji, nazwę aplikacji lub nazwę logowania. Filtry mogą ograniczać rejestrowanie według wartości tych kolumn. Takie podejście jest użyteczne przy prostych obserwacjach, ale lista zdarzeń i dostępnych danych zależy od modelu SQL Trace. Nie każda informacja dostępna w Extended Events ma bezpośredni odpowiednik w starszym mechanizmie.

Extended Events umożliwia filtrowanie na poziomie predykatu, zanim pełne dane zdarzenia zostaną przekazane do celu. Może to zmniejszać ilość generowanych danych, szczególnie gdy sesja obserwuje często występujące zdarzenia. W sesji można rejestrować na przykład błędy, zakleszczenia, zakończenia zapytań, oczekiwania, problemy z wejściem-wyjściem oraz informacje dotyczące wydajności. Konkretna dostępność zdarzeń, pól i akcji zależy od wersji SQL Server, dlatego konfigurację trzeba sprawdzić dla używanego wydania silnika.

Ważną cechą Extended Events jest możliwość dołączania akcji do zdarzeń. Akcja może dostarczyć kontekst, którego samo zdarzenie nie zawiera, na przykład tekst polecenia, identyfikator sesji, nazwę aplikacji lub plan zapytania, jeżeli dana akcja jest obsługiwana przez wybrane zdarzenie i wersję silnika. Nie należy jednak dodawać wszystkich możliwych akcji bez analizy, ponieważ część z nich wymaga dodatkowego przetwarzania i może zwiększyć narzut sesji.

Cele zapisu, narzut i analiza wyników

SQL Trace może zapisywać dane do pliku śladu albo przekazywać je do narzędzi analizujących aktywność. Pliki można później odczytywać i filtrować, lecz przy dużej liczbie zdarzeń szybko rośnie ich objętość. SQL Server Profiler jest wygodny do krótkiej, interaktywnej obserwacji, ale uruchamianie długotrwałego śledzenia za jego pomocą może niepotrzebnie obciążać serwer. Ślad po stronie serwera jest zwykle właściwszy dla zaplanowanego zbierania danych, ponieważ działa niezależnie od otwartego interfejsu Profiler.

Extended Events udostępnia między innymi cele plikowe oraz pamięciowe. Często stosowanym celem plikowym jest event_file, który zapisuje dane sesji do plików możliwych do późniejszej analizy. Cel ring_buffer przechowuje ograniczony zestaw danych w pamięci i może być przydatny przy krótkich obserwacjach, ale jego zawartość jest nietrwała po restarcie i może zostać nadpisana po zapełnieniu bufora. Przy analizie trzeba uwzględnić rozmiar plików, sposób rotacji oraz uprawnienia do katalogu, w którym zapisywane są dane.

Niższy narzut Extended Events nie oznacza, że każda sesja jest bezkosztowa. Rejestrowanie bardzo częstych zdarzeń, dołączanie ciężkich akcji, zbieranie planów zapytań lub zapisywanie dużych ilości tekstu może zwiększać zużycie procesora, pamięci i operacji wejścia-wyjścia. Dlatego sesję projektuje się od celu diagnostycznego: najpierw określa się objaw, następnie dobiera zdarzenia, predykaty, akcje i cel zapisu. Po zakończeniu pomiaru sesję należy zatrzymać albo odpowiednio ograniczyć.

Przejście ze starszego śladu do sesji Extended Events

SQL Trace i SQL Server Profiler są oznaczone przez Microsoft jako funkcje przeznaczone do wycofania z przyszłych wersji SQL Server. Oznacza to, że istniejące konfiguracje mogą nadal działać w obsługiwanych wydaniach, ale nowe rozwiązania diagnostyczne powinny być projektowane z użyciem Extended Events. Migracja nie polega na mechanicznym przepisaniu nazwy mechanizmu, ponieważ klasy zdarzeń SQL Trace, zdarzenia Extended Events, kolumny danych i akcje mają różne mapowania.

Przy odtwarzaniu konkretnego śladu należy najpierw ustalić, jakie pytanie diagnostyczne miał rozstrzygać. Jeśli chodzi o wykrycie zakleszczeń, warto użyć sesji Extended Events przeznaczonej do zbierania informacji o deadlockach. Jeśli problem dotyczy wolnych zapytań, trzeba dobrać zdarzenie i predykat zgodnie z używaną wersją SQL Server oraz jasno określić, czy mierzony jest czas wykonania, czas oczekiwania, liczba odczytów czy inny parametr. Nie każdy filtr znany z SQL Trace ma identyczne znaczenie w Extended Events.

Po utworzeniu sesji należy zweryfikować, czy jest ona uruchomiona, gdzie zapisuje dane i czy zebrane pola rzeczywiście odpowiadają badanemu problemowi. Analiza powinna odróżniać czas trwania zapytania od czasu oczekiwania, błędy od ostrzeżeń oraz zdarzenia pojedyncze od powtarzalnych. W przypadku diagnostyki komputera lub oprogramowania klienckiego przydatne jest także ustalenie, czy problem leży w samym urządzeniu, połączeniu z usługą SQL Server, konfiguracji aplikacji czy w pracy instancji bazy danych. Sam zapis zdarzenia nie jest jeszcze dowodem przyczyny; wymaga korelacji z czasem wystąpienia, identyfikatorem sesji, tekstem polecenia i pozostałymi objawami.