Widok sys.dm_os_tasks

sys.dm_os_tasks zwraca listę zadań wykonywanych przez wątki silnika bazodanowego.

Co widok pokazuje o wewnętrznej pracy silnika

sys.dm_os_tasks należy do rodziny widoków opisujących warstwę systemu operacyjnego SQL Servera, czyli SQLOS. Jeden wiersz odpowiada jednemu zadaniu — najmniejszej jednostce pracy, którą harmonogram przydziela wątkowi. Widok zawiera identyfikator sesji, identyfikator żądania, adres harmonogramu, adres wątku roboczego oraz stan zadania. Istotne jest to, że jedna sesja użytkownika może mieć wiele zadań naraz: zapytanie wykonywane równolegle rozdziela pracę między kilka wątków i każdy z nich pojawia się tu jako osobny wiersz z tym samym session_id, ale różnymi wartościami exec_context_id.

Stany zadań i co z nich wynika

Kolumna task_state przyjmuje wartości opisujące położenie zadania w cyklu życia: PENDING oznacza zadanie czekające na przydzielenie wątku roboczego, RUNNABLE zadanie gotowe do pracy stojące w kolejce po procesor, RUNNING zadanie aktualnie wykonywane, SUSPENDED zadanie wstrzymane w oczekiwaniu na zasób, SPINLOOP zadanie kręcące się w pętli aktywnego oczekiwania. Duża liczba zadań w stanie PENDING to sygnał wyczerpania puli wątków roboczych, czyli sytuacji, w której serwer nie ma czym obsłużyć kolejnych żądań. Przewaga stanu RUNNABLE przy jednoczesnym niskim wykorzystaniu dysków wskazuje na zator na procesorze, a nie na wejściu-wyjściu. To rozróżnienie zmienia kierunek dalszej diagnostyki.

Ograniczenia i błędne wnioski

Widok pokazuje wyłącznie zadania istniejące w chwili odpytania, więc pojedynczy SELECT daje migawkę, a nie historię — wniosek o obciążeniu wymaga serii odczytów, na przykład co kilka sekund do tabeli tymczasowej. Zadania systemowe silnika, takie jak zapis dziennika czy czyszczenie duchów rekordów, również się tu pojawiają i mają identyfikatory sesji poniżej progu sesji użytkowników, co przy pobieżnej analizie zawyża obraz. Kolumna pending_io_count bywa mylona z licznikiem operacji zakończonych, choć dotyczy operacji trwających. Wreszcie samo odpytanie tego widoku na mocno obciążonym serwerze potrafi chwilę potrwać, bo wymaga przejścia po strukturach harmonogramów — nie należy uruchamiać go w pętli bez przerwy, gdy szuka się przyczyny przeciążenia.

Analiza obciążenia serwera baz danych w firmie

Do tego widoku sięgamy, gdy zgłoszenie brzmi „program zawiesza się o określonej godzinie” albo „przy większej liczbie użytkowników wszystko staje”. Warszawskie Pogotowie Komputerowe zbiera wtedy próbki stanu silnika w oknie, w którym problem występuje, i zestawia je z obciążeniem dysków oraz pamięci maszyny. Serwisujemy wdrożenia Subiekta, WAPRO i Comarch działające na SQL Server, gdzie źródłem zatoru bywa nocne zadanie kopii zapasowej nachodzące na godziny pracy albo raport uruchamiany przez jednego użytkownika i blokujący pozostałych. Pomoc świadczymy przez całą dobę, także w dni wolne.