Sp_whoisactive

sp_whoisactive to popularna, zewnętrzna procedura diagnostyczna Adama Machanica do analizy aktywnych zapytań.

Sp_WhoIsActive jako procedura diagnostyczna SQL Server

sp_WhoIsActive to zewnętrzna procedura składowana przeznaczona dla Microsoft SQL Server. Została opracowana przez Adama Machanica i służy do obserwowania aktywności instancji w czasie wykonywania zapytań. Nie jest elementem instalacji silnika SQL Server ani poleceniem języka T-SQL dostępnym automatycznie po utworzeniu bazy. Administrator instaluje jej definicję w wybranej bazie, zwykle w bazie administracyjnej, a następnie uruchamia ją z odpowiednimi uprawnieniami.

Procedura pobiera informacje o sesjach i żądaniach wykonywanych aktualnie przez silnik. W wynikach można znaleźć między innymi identyfikator sesji, nazwę użytkownika, nazwę bazy danych, tekst wykonywanego polecenia, czas rozpoczęcia, czas trwania, stan żądania oraz informacje o blokowaniu. Dzięki temu sp_WhoIsActive pozwala szybko ustalić, czy opóźnienie wynika z długiego zapytania, oczekiwania na blokadę, przeciążenia zasobów albo nieprawidłowego zachowania konkretnej sesji.

Jakie dane pokazuje uruchomienie sp_WhoIsActive

Podstawowe wywołanie EXEC sp_WhoIsActive; zwraca bieżący obraz pracy instancji SQL Server. Procedura prezentuje aktywne żądania, a także sesje, które mogą mieć znaczenie dla analizy. Szczególnie użyteczne są kolumny związane z czasem działania, stanem oczekiwania, typem oczekiwania, zasobem, na który czeka sesja, oraz sesją blokującą. Wiersz dotyczący blokowanego zapytania należy interpretować razem z wierszem blokera, ponieważ samo stwierdzenie, że sesja oczekuje, nie wskazuje jeszcze przyczyny problemu.

Do analizy tekstu polecenia można użyć parametrów takich jak @get_full_inner_text = 1 oraz @get_outer_command = 1. Pierwszy z nich pomaga wyświetlić pełniejszy tekst aktualnie wykonywanego polecenia wewnętrznego, natomiast drugi ułatwia rozpoznanie polecenia zewnętrznego, na przykład procedury wywołującej dalsze instrukcje. Parametr @get_plans = 1 umożliwia dołączenie planu wykonania, a @get_locks = 1 pozwala rozszerzyć wynik o informacje o blokadach. Dane te mogą być obszerne, dlatego w praktyce warto włączać je wtedy, gdy są potrzebne do konkretnej diagnozy.

Wynik można porządkować według różnych kryteriów za pomocą parametru @sort_order, na przykład według czasu trwania lub użycia zasobów. Parametr @find_block_leaders = 1 pomaga wskazać sesje znajdujące się na początku łańcucha blokowania, czyli takie, których zakończenie może odblokować większą liczbę innych żądań. Nie oznacza to automatycznie, że sesję wolno zakończyć. Decyzję o anulowaniu zapytania lub rozłączeniu sesji trzeba poprzedzić sprawdzeniem transakcji, wykonywanej operacji i skutków przerwania.

Analiza blokad, oczekiwań i planów wykonania

sp_WhoIsActive jest przydatne przede wszystkim wtedy, gdy administrator potrzebuje korelować kilka rodzajów informacji z jednego momentu. Długi czas trwania zapytania bez oczekiwania może wskazywać na intensywne obliczenia, odczyt dużej liczby stron albo plan wykonania wymagający optymalizacji. Z kolei oczekiwanie typu blokującego wymaga ustalenia, która sesja utrzymuje blokadę oraz czy ma otwartą transakcję. Sesja widoczna jako aktywna może w rzeczywistości czekać na klienta, dysk, pamięć, blokadę lub inny zasób silnika.

Opcja @get_additional_info = 1 może dostarczyć dodatkowych danych kontekstowych, zależnie od wersji SQL Server i dostępnych informacji diagnostycznych. Przy użyciu @get_task_info = 2 procedura może zebrać bardziej szczegółowe dane dotyczące zadań wykonywanych przez żądania, jednak takie rozszerzone odczyty mogą zwiększać koszt samej obserwacji. Diagnostyka powinna być prowadzona proporcjonalnie do problemu: najpierw warto wykonać podstawowy odczyt, a dopiero potem włączać plany, blokady i pełne teksty.

Plan wykonania uzyskany przez sp_WhoIsActive nie jest samodzielnym dowodem błędnej konfiguracji. Należy go zestawić z parametrami zapytania, indeksami, statystykami, rozmiarem tabel, częstotliwością wywołań oraz obciążeniem instancji. Procedura pokazuje stan chwilowy, więc pojedyncze uruchomienie może nie uchwycić problemu występującego okresowo. Przy zdarzeniach krótkotrwałych przydatne jest cykliczne zapisywanie wyników do tabeli za pomocą parametru @destination_table, a następnie porównywanie czasu trwania, oczekiwań i sesji blokujących w kolejnych próbkach.

Bezpieczne wykorzystanie w praktyce administracyjnej

Przed użyciem sp_WhoIsActive należy sprawdzić, w której bazie została zainstalowana procedura, z jakiego źródła pochodzi jej definicja oraz czy jej kod odpowiada wersji używanego SQL Server. Procedura powinna być traktowana jak dodatkowy komponent administracyjny, a nie jak zaufana funkcja systemowa. Jej instalację, aktualizację i usunięcie wykonuje się świadomie, z uwzględnieniem zależności skryptu oraz uprawnień konta uruchamiającego. Dostęp do informacji o innych sesjach i planach może wymagać podwyższonych uprawnień, w tym uprawnienia VIEW SERVER STATE; dokładny zakres zależy od wersji silnika i rodzaju odczytywanych danych.

Wyniki sp_WhoIsActive należy zapisywać w sposób kontrolowany, ponieważ mogą zawierać teksty zapytań, nazwy obiektów, nazwy baz i informacje o środowisku. Przy długotrwałym monitoringu trzeba ograniczyć częstotliwość próbkowania, rozmiar przechowywanych planów oraz czas retencji tabeli docelowej. Sama procedura nie naprawia indeksów, nie zmienia planów wykonania i nie usuwa blokad. Jest narzędziem obserwacyjnym, które pomaga wskazać sesję lub żądanie wymagające dalszej analizy w SQL Server.

W środowisku, w którym problem dotyczy aplikacji uruchamianej na laptopie lub komputerze PC, dane z SQL Server warto łączyć z informacjami o czasie odpowiedzi aplikacji, połączeniu sieciowym i obciążeniu systemu operacyjnego. Dzięki temu można odróżnić opóźnienie wynikające z pracy bazy od problemu klienta. Rzetelna diagnoza powinna obejmować powtarzalne pomiary, identyfikację konkretnego zapytania oraz weryfikację skutków każdej zmiany konfiguracji lub kodu.