Sp_who2

sp_who2 to nieoficjalna, rozszerzona wersja sp_who z dodatkowymi kolumnami diagnostycznymi.

Sp_who2 jako rozszerzony podgląd sesji SQL Server

Sp_who2 jest nieoficjalnie rozszerzoną odmianą procedury systemowej sp_who, używaną do szybkiego sprawdzania aktywności instancji Microsoft SQL Server. Nie stanowi osobnego mechanizmu zarządzania bazą ani pełnego narzędzia do analizy wydajności. Jej wartość polega na zebraniu w jednym zestawieniu podstawowych informacji o połączeniach, procesach serwera, stanie wykonywanych poleceń oraz obiektach, z którymi powiązane są aktywne sesje.

Procedura jest często wywoływana w sytuacji, gdy aplikacja przestaje odpowiadać, zapytanie długo się wykonuje albo użytkownicy zgłaszają opóźnienia przy zapisie i odczycie danych. Wynik może pomóc ustalić, czy problem wynika z oczekiwania na inną sesję, dużego obciążenia, otwartej transakcji, blokady lub nietypowej aktywności pojedynczego połączenia. Sp_who2 nie odpowiada jednak samodzielnie na wszystkie pytania. Otrzymane dane wymagają interpretacji w odniesieniu do konfiguracji serwera, rodzaju aplikacji, harmonogramu zadań oraz aktualnie wykonywanych operacji.

Najczęściej procedura jest uruchamiana w narzędziu do obsługi SQL Server za pomocą polecenia EXEC sp_who2;. Możliwe jest również wskazanie konkretnego identyfikatora procesu, aby ograniczyć wynik do jednej sesji. W praktyce przydatne bywa porównanie kilku kolejnych odczytów, ponieważ pojedynczy wynik przedstawia tylko chwilowy stan. Krótkie zapytanie może zakończyć się jeszcze przed analizą, a sesja oczekująca może zmienić status po zwolnieniu zasobu.

Sp_who2 i znaczenie kolumn w diagnozie

Wynik Sp_who2 zawiera między innymi identyfikator procesu, status, nazwę logowania, nazwę hosta, nazwę używanej bazy danych oraz opis wykonywanego polecenia. Istotna jest także kolumna wskazująca sesję blokującą. Jeżeli przy danym procesie pojawia się identyfikator innej sesji, może to oznaczać oczekiwanie na zwolnienie zasobu zajętego przez wcześniejsze połączenie. Nie oznacza to jeszcze, że wskazana sesja jest przyczyną problemu w każdym sensie. Należy ustalić, jakie polecenie wykonuje, czy ma otwartą transakcję oraz jak długo utrzymuje blokadę.

Warto zwrócić uwagę na pola związane z czasem procesora, liczbą operacji wejścia i wyjścia oraz czasem oczekiwania. Wysoka wartość czasu procesora może wskazywać na intensywne obliczenia, nieoptymalne zapytanie lub przetwarzanie dużego zbioru danych. Duża liczba operacji wejścia i wyjścia może kierować uwagę na odczyty z dysku, brak odpowiednich indeksów albo zapytanie zwracające więcej danych, niż jest potrzebne. Samo wystąpienie wysokiej wartości nie przesądza o błędzie, ponieważ znaczenie zależy od czasu działania sesji oraz charakteru wykonywanej pracy.

Status sesji również wymaga ostrożnej interpretacji. Stan oznaczony jako aktywny sugeruje, że proces aktualnie wykonuje operację, natomiast stan uśpienia może oznaczać bezczynne połączenie oczekujące na kolejne polecenie. Sesja uśpiona nie musi być problemem. Może należeć do puli połączeń aplikacji i pozostawać gotowa do ponownego użycia. Niepokój może pojawić się wtedy, gdy bezczynne połączenie utrzymuje niezatwierdzoną transakcję lub blokuje inne procesy.

Przy analizie przydatne jest zestawienie Sp_who2 z innymi widokami dynamicznymi, na przykład sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_tran_active_transactions oraz sys.dm_os_waiting_tasks. Takie porównanie pozwala sprawdzić tekst zapytania, typ oczekiwania, czas trwania operacji i informacje o transakcjach. Sp_who2 może więc pełnić funkcję pierwszego filtra, po którym wykonywana jest dokładniejsza diagnostyka.

Sp_who2 a typowe problemy z blokadami i zapytaniami

Jednym z najczęstszych zastosowań procedury jest szukanie blokad. Blokada powstaje wtedy, gdy jedna sesja utrzymuje zasób potrzebny innej sesji. Zasobem może być między innymi wiersz, strona danych, tabela albo inny element wykorzystywany podczas operacji. W wyniku Sp_who2 można zobaczyć relację pomiędzy sesją oczekującą a sesją, która może przetrzymywać zasób. Następnie należy sprawdzić tekst polecenia oraz stan transakcji, ponieważ zakończenie niewłaściwego procesu może spowodować utratę niezapisanych zmian lub przerwanie ważnej operacji.

Problemy z długimi zapytaniami mogą wynikać z wielu przyczyn. Należą do nich brak odpowiedniego indeksu, filtrowanie po kolumnie o niekorzystnej selektywności, nieaktualne statystyki, nieoczekiwane skanowanie dużej tabeli, konwersje typów danych lub przekazywanie nadmiernej liczby rekordów do aplikacji. Sp_who2 może wskazać, że sesja działa długo i zużywa zasoby, lecz nie zastępuje planu wykonania. Do ustalenia przyczyny potrzebne jest przeanalizowanie planu, parametrów, warunków wyszukiwania i liczby przetwarzanych danych.

W niektórych przypadkach na liście pojawiają się procesy systemowe, zadania w tle albo połączenia związane z narzędziami administracyjnymi. Nie powinno się ich usuwać wyłącznie na podstawie nazwy. Przed podjęciem decyzji o przerwaniu sesji należy zweryfikować właściciela połączenia, cel operacji, czas trwania, blokowane zasoby oraz możliwość bezpiecznego wycofania transakcji. Zdarza się, że pozornie zawieszona operacja wykonuje poprawną, choć długotrwałą pracę.

Do odróżnienia krótkotrwałego skoku obciążenia od stałego problemu pomocne jest wykonywanie kilku odczytów w odstępach czasu i zapisywanie wyników. Jeżeli ten sam proces regularnie pojawia się jako blokujący, warto przeanalizować sposób otwierania i zatwierdzania transakcji w aplikacji. Gdy blokady występują tylko podczas określonego zadania, znaczenie może mieć harmonogram operacji, kolejność aktualizacji danych lub sposób współdzielenia zasobów.

Sp_who2 w praktycznej analizie stanu serwera

Przed uruchomieniem procedury dobrze jest określić objaw, który ma zostać wyjaśniony. Inaczej interpretuje się brak odpowiedzi aplikacji, inaczej wolne wykonywanie pojedynczego raportu, a jeszcze inaczej błędy pojawiające się przy zapisie. Pomocne jest zanotowanie czasu wystąpienia problemu, nazwy aplikacji, użytkownika, używanej bazy oraz czynności wykonywanej w danym momencie. Dzięki temu wynik Sp_who2 można połączyć z logami aplikacji i innymi informacjami diagnostycznymi.

Nie powinno się oceniać wydajności wyłącznie na podstawie kolejności wierszy. Lista nie jest rankingiem najwolniejszych procesów. Warto filtrować informacje według statusu, nazwy bazy, hosta, identyfikatora procesu lub sesji blokującej. Przydatne jest również rozróżnienie czasu procesora od czasu, przez który sesja istnieje. Długie połączenie może przez większość czasu pozostawać bezczynne, a krótko działające zapytanie może w tym samym momencie intensywnie korzystać z zasobów.

Przydatną praktyką jest wykonanie kopii tekstowej wyniku przed zmianą konfiguracji lub zakończeniem sesji. Zachowanie danych pozwala później odtworzyć przebieg zdarzenia i porównać go z kolejnym przypadkiem. W środowisku testowym można sprawdzić, czy zmiana zapytania, indeksu lub sposobu obsługi transakcji usuwa problem. W środowisku używanym przez aplikacje produkcyjne każda ingerencja powinna być poprzedzona oceną ryzyka oraz ustaleniem procedury powrotu.

Sp_who2 może także pomóc wykryć nieoczekiwane połączenia, lecz sama nazwa hosta lub logowania nie jest wystarczającym dowodem nieprawidłowości. Dane należy porównać z konfiguracją aplikacji, listą zaplanowanych zadań i informacjami od administratora. Jeżeli wynik zawiera nieznane sesje, powinno się najpierw potwierdzić ich pochodzenie, zamiast natychmiast przerywać procesy.

Kiedy Sp_who2 wymaga wsparcia serwisowego

Do serwisu warto zgłosić się wtedy, gdy problemy z działaniem aplikacji lub bazy powtarzają się, a podstawowy odczyt Sp_who2 nie pozwala ustalić przyczyny. Szczególnie ważne są sytuacje, w których występują regularne blokady, niezatwierdzone transakcje, nagłe spowolnienia, przerwane połączenia albo trudności z uruchomieniem narzędzi administracyjnych. W takich przypadkach przydatne może być zebranie wyników procedury, komunikatów błędów, informacji o czasie wystąpienia problemu oraz opisu czynności wykonywanych przez użytkowników.

Warszawskie Pogotowie Komputerowe 24/7 może zostać wskazane jako miejsce konsultacji problemów związanych z pracą komputera, systemu lub aplikacji wymagającej uporządkowanej diagnostyki. Przy przekazywaniu zgłoszenia warto opisać, czy problem dotyczy pojedynczego stanowiska, kilku użytkowników, konkretnej bazy lub określonej operacji. Takie informacje ułatwiają odróżnienie kłopotu z połączeniem od problemu z samym zapytaniem albo zasobami komputera.

Przed przekazaniem danych diagnostycznych należy usunąć hasła, tokeny, dane osobowe oraz fragmenty zapytań zawierające poufne informacje. Zrzut wyniku Sp_who2 powinien być traktowany jako materiał techniczny, a nie pełna diagnoza. Najlepszy efekt daje połączenie go z opisem objawów, czasem wystąpienia, logami oraz informacją o ostatnich zmianach w aplikacji lub konfiguracji.