Trace SQL Server

Trace SQL Server to starszy mechanizm rejestrowania zdarzeń, stopniowo wypierany przez Extended Events.

Trace SQL Server — przeznaczenie i miejsce w architekturze silnika

Trace SQL Server, nazywany także SQL Trace, jest starszym mechanizmem przechwytywania zdarzeń generowanych przez aparat Microsoft SQL Server. Pozwala rejestrować między innymi wykonywanie instrukcji Transact-SQL, procedur składowanych, partii poleceń, logowania użytkowników, błędy oraz informacje związane z wydajnością zapytań. Zebrane dane mogą być używane do ustalenia, jakie operacje zostały wykonane, przez którą sesję, w jakim czasie i z jakim wynikiem czasowym. Mechanizm nie zmienia logiki zapytań ani planów wykonania; obserwuje zdarzenia zgłaszane przez działający silnik.

Trace SQL Server występuje w dwóch powiązanych formach. SQL Server Profiler jest graficznym narzędziem służącym do konfigurowania i oglądania śladów, natomiast ślad po stronie serwera może działać niezależnie od interfejsu użytkownika. Konfigurację śladu można utworzyć programowo za pomocą systemowych procedur rozszerzonych, których nazwy zaczynają się od sp_trace_. Przykładowo sp_trace_create tworzy ślad, sp_trace_setevent przypisuje mu zdarzenia i kolumny, a sp_trace_setstatus uruchamia lub zatrzymuje ślad. W praktyce oznacza to, że rejestrowanie może działać także wtedy, gdy SQL Server Profiler nie jest uruchomiony na komputerze administratora.

Konfiguracja zdarzeń, kolumn i filtrów

Ślad nie rejestruje automatycznie wszystkiego, co dzieje się w instancji. Przy jego konfiguracji wybiera się klasy zdarzeń, na przykład SQL:BatchCompleted, RPC:Completed, Audit Login albo Exception, a następnie określa kolumny opisujące dane zdarzenie. W zależności od wybranej klasy mogą to być między innymi identyfikator procesu serwera, identyfikator sesji, nazwa bazy danych, nazwa aplikacji, nazwa użytkownika, czas rozpoczęcia, czas zakończenia, czas trwania, liczba odczytów logicznych, liczba zapisów oraz tekst polecenia. Nie każda kolumna jest dostępna dla każdej klasy zdarzenia, dlatego konfigurację należy oceniać na podstawie konkretnego zdarzenia, a nie samej nazwy kolumny.

Ważnym elementem śladu są filtry. Można ograniczyć rejestrowanie na przykład do jednej bazy danych, wybranej aplikacji, konkretnego użytkownika, określonego identyfikatora sesji albo instrukcji przekraczających ustalony czas trwania. Filtr zmniejsza liczbę zapisanych rekordów i ułatwia analizę, ale nie naprawia problemu wydajnościowego sam w sobie. Niewłaściwie dobrany ślad może generować znaczący narzut wejścia-wyjścia i zużywać zasoby procesora, zwłaszcza gdy przechwytuje dużą liczbę zdarzeń na obciążonej instancji.

Wynik śladu może być zapisywany do pliku albo kierowany do tabeli. Plik śladu można później analizować narzędziami SQL Server, a dane tabelaryczne odczytywać zapytaniami Transact-SQL. Konfiguracja zapisu powinna uwzględniać uprawnienia konta usługi SQL Server do wskazanej lokalizacji oraz dostępne miejsce na dysku. Przy długotrwałym zbieraniu danych przydatne są ustawienia rozmiaru pliku i liczby plików rotacyjnych, aby ślad nie zapełnił całego woluminu.

Odczyt wyników i ograniczenia diagnostyczne

Wyniki Trace SQL Server są przydatne wtedy, gdy trzeba odtworzyć kolejność zdarzeń lub znaleźć konkretne wywołania. Kolumny czasu rozpoczęcia, zakończenia i czasu trwania pozwalają porównywać wykonania instrukcji, a pola dotyczące odczytów i zapisów pomagają wskazać operacje wykonujące dużo pracy wejścia-wyjścia. Informacje o nazwie aplikacji, użytkowniku i identyfikatorze sesji mogą pomóc powiązać zdarzenie z konkretnym połączeniem. Sam ślad nie stanowi jednak pełnego obrazu wydajności. Nie zastępuje analizy planu wykonania, statystyk oczekiwania, blokad, konfiguracji instancji ani stanu podsystemu dyskowego.

Trzeba też rozróżnia czas trwania pojedynczego zdarzenia od czasu oczekiwania całej aplikacji. Zarejestrowana instrukcja może obejmować oczekiwanie na blokadę, dysk lub inny zasób, lecz pojedynczy rekord nie zawsze wyjaśnia, która sesja była źródłem blokady i jaki łańcuch zależności powstał. Podobnie brak rekordu w śladzie nie musi oznaczać, że użytkownik nie wykonał operacji. Przyczyną może być pominięcie odpowiedniej klasy zdarzenia, aktywny filtr, rozpoczęcie śledzenia po wystąpieniu problemu albo zakończenie zapisu z powodu błędu dostępu do pliku.

SQL Server Profiler jest wygodny do krótkich, celowanych obserwacji, ale uruchamianie szerokiego śladu produkcyjnego bez filtrów może pogorszyć działanie instancji. Ślad powinien mieć jasno określony cel, ograniczony zakres zdarzeń i czas działania. Po zakończeniu pomiaru należy zatrzymać niepotrzebny ślad oraz zachować jego konfigurację razem z informacją o czasie rozpoczęcia, filtrach i miejscu zapisu. Dzięki temu można odróżnić fakty zarejestrowane przez mechanizm od interpretacji wykonanej później podczas diagnostyki.

Trace SQL Server a Extended Events i praktyka serwisowa

SQL Trace i SQL Server Profiler są w dokumentacji Microsoftu oznaczone jako technologie przestarzałe, a zalecanym mechanizmem śledzenia zdarzeń jest Extended Events. Extended Events oferuje model oparty na sesjach zdarzeń i został zaprojektowany z myślą o mniejszym narzucie oraz większej elastyczności. Umożliwia dobieranie zdarzeń, predykatów filtrujących i celów zapisu, między innymi pliku zdarzeń. Do odczytu danych można używać widoków katalogowych oraz funkcji systemowych przeznaczonych do analizy plików Extended Events. W nowej konfiguracji diagnostycznej należy więc najpierw sprawdzić, czy wymagany pomiar można wykonać za pomocą tego mechanizmu.

Trace SQL Server nadal może być spotykany w istniejących skryptach, procedurach utrzymaniowych i starszych instrukcjach operacyjnych. Jego obecność nie oznacza automatycznie awarii, ale wymaga sprawdzenia, czy ślad jest potrzebny, jakie zdarzenia rejestruje i gdzie zapisuje dane. Szczególnej uwagi wymagają ślady uruchamiane przy starcie usługi, ślady zapisujące do tabel bez kontroli rozmiaru oraz konfiguracje obejmujące wszystkie partie poleceń i wywołania procedur. Przy migracji do Extended Events trzeba zachować cel diagnostyczny, lecz nie należy bezpośrednio zakładać, że każda klasa zdarzenia i każda kolumna ma identyczny odpowiednik.

Podczas diagnostyki infrastruktury z SQL Server warto zebrać konfigurację aktywnych śladów, przeanalizować ich filtry, sprawdzić błędy zapisu oraz porównać czas wystąpienia zdarzeń z obserwowanymi opóźnieniami aplikacji. Należy również ustalić, czy dane pochodzą ze właściwej instancji i bazy, ponieważ sam plik śladu nie zawsze zawiera komplet informacji o środowisku, w którym został utworzony. Takie podejście pozwala wykorzystać istniejący Trace SQL Server jako źródło dowodów, a następnie zaplanować przejście do Extended Events bez mieszania wyników z różnych mechanizmów monitorowania.