SYS.DM_OS_WAITING_TASKS

sys.dm_os_waiting_tasks zwraca listę zadań aktualnie oczekujących na zasób.

SYS.DM_OS_WAITING_TASKS – czym jest widok oczekujących zadań

sys.dm_os_waiting_tasks jest dynamicznym widokiem zarządzania w Microsoft SQL Server, który pozwala sprawdzić stan zadań oczekujących na wykonanie określonej operacji. Nie przedstawia pełnej historii obciążenia ani trwałego rejestru wszystkich opóźnień. Pokazuje sytuację obserwowaną w chwili wykonania zapytania, dlatego wynik może zmieniać się z każdym odświeżeniem. Zadanie może oczekiwać na blokadę, dostęp do pamięci, ukończenie operacji wejścia i wyjścia albo sygnał pozwalający na dalsze wykorzystanie zasobu procesora.

Warto rozróżnić zadanie, sesję i żądanie. Sesja identyfikuje połączenie z bazą, żądanie opisuje aktualnie wykonywaną operację, a zadanie jest jednostką pracy realizowaną przez aparat wykonawczy. Jedno żądanie może korzystać z kilku zadań, szczególnie gdy plan wykonania dopuszcza pracę równoległą. Z tego powodu liczba wierszy zwróconych przez widok nie musi odpowiadać liczbie użytkowników, połączeń ani zapytań. Każdy wiersz powinien być interpretowany w kontekście identyfikatora sesji, rodzaju oczekiwania, zasobu oraz relacji blokowania.

Najprostsze odczytanie widoku może wyglądać następująco:

• SELECT session_id, wait_duration_ms, wait_type, blocking_session_id FROM sys.dm_os_waiting_tasks;

Takie zapytanie jest punktem wyjścia, a nie kompletną diagnozą. Przydatność wyniku rośnie po połączeniu go z informacjami o zapytaniach, tekstach poleceń, planach wykonania, sesjach oraz obiektach, których dotyczą blokady.

SYS.DM_OS_WAITING_TASKS – kontekst techniczny i porównania

Wynik sys.dm_os_waiting_tasks opisuje oczekiwanie na poziomie zadań i zasobów. To odróżnia go od sys.dm_exec_requests, które koncentruje się na aktywnych żądaniach, ich stanie, czasie wykonania oraz bieżącej komendzie. Z kolei sys.dm_os_wait_stats gromadzi zagregowane statystyki typów oczekiwań od momentu uruchomienia instancji albo wyzerowania liczników. Pierwszy widok odpowiada więc na pytanie „kto i na co czeka teraz”, drugi pokazuje „jakie oczekiwania występowały w dłuższym okresie”, a trzeci pomaga powiązać bieżący stan z konkretną sesją lub żądaniem.

Nie każde oczekiwanie oznacza awarię. Część z nich jest normalnym elementem koordynowania pracy. Oczekiwanie na blokadę może wynikać z krótkiej transakcji, która za chwilę się zakończy. Oczekiwanie związane z wejściem i wyjściem może być typowe dla zapytania odczytującego większy zakres danych. Przy pracy równoległej mogą pojawić się oczekiwania synchronizacyjne, które same w sobie nie wskazują na problem. Znaczenie uzyskuje dopiero po zestawieniu typu oczekiwania z czasem jego trwania, częstotliwością, obciążeniem oraz wpływem na użytkowników.

W przypadku diagnozy blokad szczególnie istotne są pola blocking_session_id, resource_description i wait_type. Pierwsze może wskazywać sesję, która przetrzymuje zasób. Drugie opisuje zasób w formie technicznej, czasem wymagającej dalszego powiązania z obiektem lub stroną danych. Trzecie określa mechanizm oczekiwania. Do ustalenia przyczyny nie wystarcza więc samo znalezienie najdłuższego czasu oczekiwania. Należy sprawdzić także, czy blokująca sesja wykonuje pracę, pozostaje bezczynna w otwartej transakcji albo została pozostawiona przez aplikację.

Ważne jest również odróżnienie czasu oczekiwania od czasu zajmowania procesora. Zadanie może czekać przez długi czas, lecz nie zużywać zasobów obliczeniowych. Może też szybko przechodzić między różnymi stanami, przez co pojedynczy odczyt nie pokaże pełnego obrazu. Przydatne bywa wykonanie kilku pomiarów w odstępach czasu i porównanie powtarzających się sesji oraz typów oczekiwań.

SYS.DM_OS_WAITING_TASKS – typowe problemy i interpretacja

Jednym z częstych problemów jest blokowanie przez długo otwartą transakcję. W takiej sytuacji wiele sesji może oczekiwać na podobny zasób, a jedna sesja staje się początkiem łańcucha blokad. Przy analizie należy ustalić, która sesja jest źródłem opóźnienia, jaki tekst polecenia ją otworzył i czy transakcja powinna zostać zakończona. Przerywanie sesji bez rozpoznania skutków może doprowadzić do wycofywania zmian, dlatego decyzję należy opierać na stanie aplikacji i znaczeniu operacji.

Inną grupę stanowią oczekiwania związane z pamięcią. Mogą wskazywać, że zapytanie potrzebuje miejsca na sortowanie, grupowanie lub inne operacje pośrednie, ale nie otrzymuje go wystarczająco szybko. Nie oznacza to automatycznie braku pamięci fizycznej. Przyczyną może być nieoptymalny plan, zaniżone oszacowanie liczby wierszy, nieaktualne statystyki albo konkurencja między zapytaniami. Zasadne jest sprawdzenie planu wykonania, kardynalności, indeksów i parametrów zapytania.

Oczekiwania wejścia i wyjścia często są wiązane z wolnym nośnikiem, lecz również tutaj potrzebne jest szersze rozpoznanie. Wąskim gardłem może być duża liczba losowych odczytów, skanowanie nieodpowiednio dobranej tabeli, intensywna aktywność dziennika transakcji albo równoczesne wykonywanie wielu operacji. Warto porównać czas oczekiwania z rozmiarem odczytywanych danych, planem wykonania i obciążeniem podsystemu przechowywania.

Problemy mogą powstawać także w aplikacji. Brak szybkiego zatwierdzania lub wycofywania transakcji, pobieranie danych w małych porcjach, niepotrzebne przetrzymywanie połączeń oraz wykonywanie zapytań bez ograniczenia zakresu zwiększają prawdopodobieństwo oczekiwań. W takim przypadku korekta samej konfiguracji SQL Server może nie rozwiązać problemu. Potrzebna może być zmiana logiki dostępu do danych, kolejności operacji albo sposobu obsługi błędów.

SYS.DM_OS_WAITING_TASKS – praktyczne wskazówki diagnostyczne

Analizę najlepiej rozpocząć od uchwycenia powtarzalnego zjawiska. Jednorazowy odczyt może trafić na naturalny, krótkotrwały etap pracy. Przydatne jest zapisanie godziny pomiaru, identyfikatorów sesji, typu oczekiwania, czasu oczekiwania i identyfikatora sesji blokującej. Następnie można porównać kilka próbek, aby sprawdzić, czy te same sesje pozostają w oczekiwaniu i czy tworzy się stały łańcuch zależności.

W praktyce warto łączyć widok z danymi o aktywnych żądaniach. Przykładowe zapytanie może wyglądać tak:

• SELECT wt.session_id, wt.wait_type, wt.wait_duration_ms, wt.blocking_session_id, r.status, r.command, r.cpu_time, r.total_elapsed_time, r.sql_handle FROM sys.dm_os_waiting_tasks AS wt LEFT JOIN sys.dm_exec_requests AS r ON r.session_id = wt.session_id;

Wynik powinien być oceniany ostrożnie, ponieważ wartości dotyczą konkretnego momentu. Jeżeli potrzebne jest odczytanie tekstu polecenia, można wykorzystać uchwyt zapytania i funkcje systemowe przeznaczone do pobierania tekstu SQL. Przydatne bywa również przeanalizowanie planu wykonania oraz historii zmian, takich jak wdrożenie nowego indeksu, aktualizacja aplikacji, zmiana parametrów lub wzrost liczby danych.

Nie należy automatycznie usuwać blokad, restartować usługi ani wyłączać zapytań tylko dlatego, że widok pokazuje oczekiwanie. Najpierw trzeba ustalić właściciela zasobu, przewidywany skutek przerwania pracy i możliwość bezpiecznego zakończenia transakcji. W środowiskach testowych można odtworzyć scenariusz na mniejszym zbiorze danych, aby sprawdzić wpływ indeksu, poziomu izolacji lub zmiany zapytania.

SYS.DM_OS_WAITING_TASKS – kiedy zgłosić się do serwisu

Wsparcie serwisowe może być zasadne, gdy oczekiwania powtarzają się mimo poprawnej konfiguracji, użytkownicy obserwują długie przerwy w działaniu aplikacji, pojawiają się cykle blokad albo nie jest możliwe bezpieczne ustalenie źródła opóźnień. Do zgłoszenia warto dołączyć przybliżony czas wystąpienia problemu, zrzut lub zapis wyników widoku, informacje o objawach oraz opis zmian wykonanych przed pojawieniem się trudności. Ułatwia to rozdzielenie problemu aplikacyjnego, bazodanowego i sprzętowego.

Warszawskie Pogotowie Komputerowe 24/7 może pomóc w uporządkowaniu objawów, zebraniu podstawowych informacji diagnostycznych i ocenie, czy potrzebna jest dalsza analiza konfiguracji oraz danych. Przed przekazaniem materiałów należy usunąć hasła, tokeny, dane osobowe i treści, których nie powinno się udostępniać. Właściwa diagnoza powinna obejmować nie tylko pojedynczy wpis z sys.dm_os_waiting_tasks, lecz także powtarzalność zjawiska, zależności między sesjami i wpływ oczekiwań na działanie całego systemu.

Najbardziej użyteczny wniosek z tego widoku nie brzmi „każde oczekiwanie jest błędem”, lecz „każde nietypowe oczekiwanie wymaga powiązania z zasobem, sesją i czasem”. Dopiero takie zestawienie pozwala odróżnić zwykłą synchronizację od rzeczywistego wąskiego gardła i dobrać działanie, które ograniczy opóźnienia bez przypadkowego przerywania prawidłowej pracy.