Widok sys.dm_exec_requests

sys.dm_exec_requests zwraca listę aktualnie wykonywanych żądań na instancji.

Widok jako punkt wyjścia do łączenia z innymi DMV

Praktyczna wartość sys.dm_exec_requests bierze się z tego, że jest węzłem, do którego dopina się pozostałe obiekty diagnostyczne. Uchwyt sql_handle prowadzi do treści polecenia, plan_handle do planu wykonania dostępnego przez sys.dm_exec_query_plan, a session_id pozwala połączyć wiersz z sys.dm_exec_sessions, żeby zobaczyć nazwę zalogowanego użytkownika, nazwę komputera klienckiego i nazwę aplikacji. Ta ostatnia kolumna bywa najcenniejsza w firmie: pokazuje, czy zapytanie przyszło z programu magazynowego, z generatora raportów, czy z czyjegoś arkusza Excela podłączonego do bazy przez zapytanie zewnętrzne. Bez tego połączenia mamy tylko numer sesji, który nikomu nic nie mówi.

Sesja użytkownika kontra proces systemowy

Widok zwraca również żądania wewnętrzne silnika, więc pierwszym odruchem przy analizie jest odfiltrowanie ich. Sesje użytkowników mają numery zaczynające się powyżej wartości zarezerwowanych dla procesów tła, a dodatkowo warto wykluczyć własną sesję identyfikowaną funkcją @@SPID, żeby zapytanie diagnostyczne nie raportowało samo siebie jako najdłużej działające. Osobno trzeba pamiętać, że część zadań, jak zapis dziennika czy proces czyszczenia wersji wierszy, pojawia się i znika w ułamkach sekundy — ich obecność w jednym uruchomieniu i brak w kolejnym nie świadczy o niestabilności. Do obserwacji ciągłej lepiej nadaje się rozszerzone zdarzenie lub Query Store, bo utrwalają dane, podczas gdy ten widok jest wyłącznie migawką.

Błędy interpretacyjne przy czytaniu wyników

Najczęstszy polega na uznaniu długiego czasu wykonania za problem wydajnościowy, podczas gdy status suspended z typem oczekiwania wskazującym na blokadę oznacza, że zapytanie nie zużywa procesora, tylko czeka na inną sesję. Drugi to zabijanie sesji poleceniem KILL bez sprawdzenia, czy nie jest ona w trakcie transakcji zapisującej — wycofywanie potrafi trwać dłużej niż sama operacja i nie da się go przerwać. Trzeci to szukanie w tym widoku sesji, która blokuje pozostałe, ale sama nic już nie wykonuje: taka sesja bezczynna z otwartą transakcją nie ma wiersza wśród żądań i widać ją dopiero po stronie sesji. Wreszcie kolumna reads dotyczy odczytów fizycznych, a nie łącznego obciążenia — do porównania kosztu zapytań lepiej użyć logical_reads.

Stały nadzór nad serwerem bazodanowym

Dla firm korzystających z programów handlowych opartych o SQL Server prowadzimy przeglądy serwera: sprawdzamy powtarzające się blokady, czas wykonania kluczowych operacji, fragmentację indeksów i realną skuteczność kopii zapasowych. Efektem jest lista konkretnych poprawek zamiast ogólnej diagnozy, że baza zwalnia. Sprzęt, jeśli wymaga interwencji fizycznej, odbieramy i odwozimy własnym transportem, bez pośrednictwa kurierów.