Sp_who

sp_who to procedura systemowa pokazująca listę aktywnych procesów i sesji na serwerze.

Sp_who jako narzędzie do podglądu pracy systemu

Sp_who to wbudowana procedura systemowa używana w środowisku Microsoft SQL Server do szybkiego sprawdzania aktywnych połączeń, sesji oraz procesów obsługiwanych przez silnik bazy danych. Jej podstawowym zadaniem jest przedstawienie bieżącego obrazu tego, co dzieje się w instancji: które sesje są aktywne, jaki identyfikator procesu został im przypisany, z jakiej bazy korzystają i czy oczekują na wykonanie określonej operacji. Dzięki temu można rozpocząć analizę sytuacji, w której użytkownicy zgłaszają spowolnienie aplikacji, brak możliwości wykonania zapytania albo długie oczekiwanie na zapis danych.

Procedura jest wywoływana poleceniem sp_who, najczęściej bez dodatkowych parametrów. W takiej postaci zwraca zestawienie widocznych sesji. W zależności od uprawnień oraz wersji systemu prezentowane są między innymi identyfikator SPID, status, nazwa logowania, nazwa hosta, identyfikator procesu blokującego, nazwa bazy danych oraz opis ostatniego polecenia. Nie jest to pełny raport diagnostyczny, lecz szybki punkt wyjścia do dalszego sprawdzania.

W praktyce Sp_who bywa stosowane podczas bieżącego nadzoru, testowania aplikacji oraz reagowania na incydenty. Wynik należy jednak odczytywać z uwzględnieniem chwili wykonania polecenia. Lista pokazuje stan dynamiczny: sesja może zakończyć pracę tuż po wyświetleniu zestawienia, a nowe połączenie może pojawić się chwilę później. Jednorazowy odczyt nie zawsze wystarcza do rozstrzygnięcia przyczyny problemu.

Sp_who w kontekście sesji, procesów i blokowania

Wynik Sp_who składa się z wierszy odpowiadających sesjom widocznym dla osoby wykonującej polecenie. Kolumna spid wskazuje identyfikator sesji, który może zostać wykorzystany przy dalszej analizie. Pole status podpowiada, czy sesja wykonuje zadanie, oczekuje na zasób, pozostaje bezczynna albo przechodzi przez inny stan rozpoznawany przez silnik. Informacja o loginie i hoście pomaga ustalić, z jakiego konta oraz z jakiego źródła pochodzi połączenie.

Szczególne znaczenie ma kolumna wskazująca proces blokujący. Jeżeli jedna sesja zatrzymuje inną, identyfikator blokującego SPID tworzy prostą relację między oczekującym a tym, który aktualnie przetrzymuje zasób. Nie oznacza to automatycznie błędu. Krótka blokada może być normalnym elementem transakcji, natomiast długo utrzymująca się zależność może wskazywać na niezatwierdzoną transakcję, zbyt szeroki zakres operacji, nieoptymalne zapytanie albo niewłaściwie dobrany sposób współbieżnego dostępu.

Sp_who różni się od bardziej szczegółowych narzędzi tym, że przekazuje skrócony obraz. W porównaniu z sp_who2 może oferować mniej informacji potrzebnych do oceny zużycia zasobów i bieżącej aktywności. Z kolei widoki dynamicznego zarządzania, takie jak sys.dm_exec_sessions, sys.dm_exec_requests oraz sys.dm_exec_sql_text, pozwalają budować dokładniejsze zapytania diagnostyczne. Można w nich łączyć dane o sesji, aktualnie wykonywanym żądaniu, czasie oczekiwania, typie oczekiwanego zasobu i tekście polecenia.

Podobieństwo nazw nie oznacza identycznego zastosowania. Sp_who sprawdza się jako szybka kontrola, natomiast rozbudowane zapytania diagnostyczne są lepsze wtedy, gdy trzeba ustalić kolejność zdarzeń, porównać czas trwania żądań albo odróżnić blokowanie od zwykłego oczekiwania na operację wejścia i wyjścia. Wybór narzędzia powinien zależeć od tego, czy potrzebny jest szybki podgląd, czy materiał do dokładnej analizy.

Sp_who a typowe problemy z działaniem bazy

Jednym z najczęstszych powodów użycia Sp_who jest podejrzenie blokady. Objawem może być zawieszanie formularza, długie zapisywanie dokumentu, opóźnione generowanie zestawienia lub komunikat informujący o oczekiwaniu na zakończenie innej operacji. W takim przypadku warto zwrócić uwagę na sesje, które pozostają aktywne przez dłuższy czas, oraz na wiersze wskazujące konkretny proces blokujący. Sam fakt wystąpienia blokady nie przesądza jeszcze o winie danej sesji, ponieważ blokujący może wykonywać prawidłową, lecz obszerną transakcję.

Innym przypadkiem jest nagromadzenie połączeń bezczynnych. Sesja oznaczona jako uśpiona nie musi oznaczać problemu. Aplikacje często utrzymują pulę połączeń, aby ograniczyć koszt ich wielokrotnego otwierania. Niepokój może pojawić się dopiero wtedy, gdy takich sesji jest wyjątkowo dużo, pozostawiają one otwarte transakcje albo przyczyniają się do wyczerpania limitu połączeń. Weryfikacja powinna obejmować również konfigurację aplikacji, sposób zwalniania połączeń oraz logikę obsługi błędów.

Sp_who może również pomóc przy rozpoznawaniu nieoczekiwanych logowań. Nazwa użytkownika, host i używana baza tworzą podstawowy kontekst do porównania z dokumentacją aplikacji. Nie należy jednak traktować pojedynczego wpisu jako dowodu nieuprawnionego dostępu. Do takiej oceny potrzebne są dodatkowe dane, między innymi historia logowań, reguły uwierzytelniania, dzienniki aplikacyjne i informacje o planowanych zadaniach.

Ważne jest także rozróżnienie między problemem bazy a problemem komputera, sieci lub aplikacji. Jeżeli Sp_who nie pokazuje długotrwałych żądań ani blokad, przyczyna może znajdować się poza samym silnikiem. Opóźnienie może wynikać z przeciążenia urządzenia, błędnego sterownika, problemu z pamięcią masową, niestabilnego połączenia albo nieprawidłowo działającego programu klienckiego. Dlatego wynik procedury powinien być jednym z elementów diagnozy, a nie jej jedyną podstawą.

Sp_who i praktyczne zasady bezpiecznej analizy

Przed wykonaniem polecenia warto zapisać godzinę obserwacji oraz okoliczności wystąpienia problemu. Przydatne jest porównanie kilku odczytów wykonanych w odstępie czasu, ponieważ pozwala sprawdzić, czy dany SPID utrzymuje się długo, czy tylko chwilowo pojawił się na liście. Dobrą praktyką jest zestawienie wyniku z informacjami od użytkowników: nazwą funkcji, która działa wolno, momentem rozpoczęcia trudności i zakresem operacji wykonywanych w aplikacji.

Nie powinno się kończyć sesji wyłącznie na podstawie tego, że wygląda na długo aktywną. Przerwanie procesu może spowodować wycofywanie transakcji, dodatkowe obciążenie oraz utratę pracy wykonywanej przez użytkownika. Decyzja o zakończeniu sesji wymaga ustalenia właściciela połączenia, sprawdzenia, czy transakcja może zostać bezpiecznie przerwana, oraz oceny wpływu na pozostałe operacje. W razie wątpliwości bezpieczniejsze jest zebranie danych i konsultacja z osobą odpowiedzialną za bazę.

Podczas analizy warto zwrócić uwagę na kilka elementów: identyfikator sesji, status, login, host, nazwę bazy, SPID blokujący oraz opis ostatniego polecenia. Należy pamiętać, że ostatnie polecenie nie zawsze opisuje pełną przyczynę obciążenia. Mogło ono zakończyć się chwilę wcześniej, a aktualny problem może wynikać z oczekiwania na zatwierdzenie transakcji lub zwolnienie zasobu.

W przypadku powtarzalnych incydentów dobrze jest prowadzić prostą historię obserwacji. Data, godzina, objaw, wynik Sp_who, identyfikator blokującego procesu i podjęte działanie ułatwiają znalezienie wzorca. Jeżeli problem pojawia się wyłącznie przy określonym raporcie, imporcie lub godzinie zwiększonego ruchu, takie informacje mogą skierować dalszą diagnostykę ku konkretnemu zapytaniu albo fragmentowi aplikacji.

• Najpierw należy ustalić, czy problem jest aktualny, czy został już zakończony.
• Następnie warto sprawdzić relację między sesją oczekującą a sesją blokującą.
• Potem należy porównać wynik z logami aplikacji i innymi danymi diagnostycznymi.
• Na końcu trzeba ocenić, czy wymagane jest działanie doraźne, czy trwała zmiana konfiguracji albo kodu.

Sp_who jako sygnał do zgłoszenia usterki

Do serwisu warto zgłosić się wtedy, gdy korzystanie z programu jest regularnie utrudnione, komputer samoczynnie przerywa pracę, pojawiają się błędy połączenia z bazą albo problem występuje mimo prawidłowego działania samej aplikacji. Szczególnie pomocne jest przekazanie daty i godziny zdarzenia, treści komunikatu, nazwy używanego programu oraz informacji, czy trudność dotyczy jednego stanowiska, czy większej liczby urządzeń. Sam wynik Sp_who może wskazywać kierunek, ale nie zawsze rozstrzyga, czy źródłem jest sprzęt, system, sieć, aplikacja czy baza danych.

W sprawach dotyczących komputera użytkowanego w domu lub w biurze można skontaktować się z Warszawskim Pogotowiem Komputerowym 24/7 pod numerem +48 22 100 48 29. Przy zgłoszeniu warto opisać objawy własnymi słowami i zaznaczyć, czy trudność pojawia się przy uruchamianiu programu, zapisie danych, drukowaniu, pracy przez sieć czy po aktualizacji. Takie informacje ułatwiają dobranie właściwego zakresu sprawdzenia oraz ograniczają ryzyko pomylenia problemu sprzętowego z błędem konfiguracji.

Jeżeli Sp_who pokazuje sesje działające prawidłowo, a użytkownik nadal obserwuje poważne spowolnienia, warto poszerzyć ocenę o stan dysku, pamięci, systemu operacyjnego, sterowników i połączenia sieciowego. Jeżeli natomiast widoczna jest powtarzalna blokada jednej sesji przez inną, potrzebna może być współpraca z administratorem bazy lub twórcą aplikacji. W obu przypadkach uporządkowany opis zdarzeń, wykonane obserwacje i ostrożne podejście do przerywania procesów zwiększają szansę na szybkie ustalenie przyczyny oraz właściwe usunięcie usterki.