Przedstawiam krótki opis stanów sesji (SPID), które można podejrzeć używając sp_who2 lub znanego skryptu Adama Machanica sp_whoisactive.
DORMANT
SQL Server resetuje sesję.
ROLLBACK
Sesja jest w trakcie wycofywania transakcji.
SPINLOCK
Zadanie sesji czeka na zwolnienie blokady spinlock.
Zasadniczo oznacza, że zapytanie jest w pewnym sensie uruchomione, w którym jest zajęte oczekiwaniem w procesorze na swoją kolej.
RUNNING:
(Mam wątki i CPU)
Ten stan oznacza, że sesja uruchomiła jeden lub więcej batchów. Po włączeniu Multiple Active Result Sets ( (MARS) sesja może uruchomić wiele batchów. W rzeczywistości oznacza to, że klient połączony z SQL Server za pomocą tej sesji już przesłał zapytanie do SQL Server do przetworzenia, a SQL Server aktualnie je przetwarza. Zapytanie może znajdować się w dowolnym miejscu między wygenerowaniem drzewa parsera a wykonaniem złączenia do sortowania danych. i obecnie zużywa cykle procesora.
SUSPENDED:
(Czekam na IO)
Oznacza to, że żądanie obecnie nie jest aktywne, ponieważ oczekuje na zasób. Zasobem może być I/O do odczytu strony. Oczekiwanie może to być spowodowane komunikacją w sieci lub czekaniem na blokadę lub zatrzask. Stanie się aktywny po zakończeniu zadania, na które czeka. Na przykład, jeśli zapytanie wysłało żądanie I/O odczytu danych z kompletnej tabeli tbl, to zadanie zostanie zawieszone do czasu zakończenia I/O. Po zakończeniu I/O (dane dla tabeli tbl są dostępne w pamięci), zapytanie zostanie przeniesione do kolejki RUNNABLE.
RUNNABLE:
Identyfikator SPID znajduje się w uruchamialnej (RUNNABLE) kolejce harmonogramu i czeka na uruchomienie kwantu w harmonogramie. Oznacza to, że żądania mają przypisany wątek roboczy, ale nie otrzymują czasu procesora.
Kolejkę RUNNABLE można porównać do analogii ze sklepem spożywczym, w której istnieje wiele kolejek do kasy. Zarządcą rejestru jest CPU. Tylko jeden klient sprawdza m.in. „RUNNING” w dowolnym rejestrze. Czas spędzony w kolejce do kasy reprezentuje ciśnienie procesora. Więc ten identyfikator SPID czeka na tego klienta, który jest uruchomiony (z zarządcą rejestru), aby wyjść, aby można było rozpocząć uruchamianie.
Można użyć zapytania
SELECT wait_type,waiting_tasks_count,signal_wait_time_ms
FROM sys.dm_os_wait_stats
ORDER BY signal_wait_time_ms DESC
, aby dowiedzieć się, jaka jest różnica między czasem, w którym wątek został zasygnalizowany i kiedy zaczął działać. Tą różnicą jest czas spędzony w kolejce RUNNABLE. Niektóre oczekiwania na górze listy można bezpiecznie zignorować.
PENDING:
(Nie mam wątków ani CPU)
Żądanie czeka, aż worker ją odbierze. Oznacza to, że żądanie jest gotowe do uruchomienia, ale nie ma dostępnych wątków roboczych do wykonania żądań w procesorze. Nie oznacza to, że musisz zwiększyć „Max. Worker threads”, musisz sprawdzić, co robią aktualnie wykonywane wątki i dlaczego nie ustępują. Osobiście widziałem więcej SPIDów ze statusem PENDING w kwestiach, które zakończyły się w „Non-yielding Scheduler” i „Scheduler deadlock”.
BACKGROUND:
Żądanie jest wątkiem w tle, takim jak Monitor zasobów lub Deadlock Monitor.
SLEEPING:
Nie ma pracy do wykonania.
