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
1 | SELECT wait_type,waiting_tasks_count,signal_wait_time_ms |
2 | FROM sys.dm_os_wait_stats |
3 | 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.
