Widok sys.dm_exec_sql_text

sys.dm_exec_sql_text zwraca pełną treść zapytania na podstawie jego uchwytu.

Uchwyt zapytania jako klucz do jego treści

Silnik SQL Servera nie przechowuje treści poleceń w tabelach systemowych — trzyma je w pamięci podręcznej razem z planami wykonania, a dostęp do nich daje uchwyt, czyli binarna wartość identyfikująca wsad. sys.dm_exec_sql_text zamienia ten uchwyt na czytelny tekst. Można ją wywołać zarówno z sql_handle, jak i z plan_handle, co bywa istotne, bo nie każdy obiekt diagnostyczny udostępnia oba. Wynik zawiera pole dbid wskazujące bazę pochodzenia oraz objectid identyfikujące obiekt, jeśli tekst pochodzi z procedury składowanej, funkcji lub wyzwalacza; dla zwykłego wsadu przesłanego przez aplikację obie kolumny są puste, co samo w sobie jest informacją o źródle polecenia.

Trzy scenariusze użycia w codziennej pracy

Pierwszy to analiza na żywo, gdy trzeba ustalić, co właśnie wykonuje zablokowana sesja — uchwyt pobiera się wtedy z widoku bieżących żądań. Drugi to szukanie zapytań najbardziej obciążających serwer w dłuższym okresie: sys.dm_exec_query_stats gromadzi statystyki zużycia procesora i odczytów dla każdego planu w cache, a dopiero doklejenie tekstu zamienia listę uchwytów w zrozumiały raport. Trzeci to inwentaryzacja obciążenia przed migracją serwera — zbiera się wtedy zrzuty zapytań w kilku porach dnia, żeby wiedzieć, co realnie pracuje na produkcji. Nowszą alternatywą dla dwóch ostatnich zastosowań jest Query Store, który zapisuje teksty i plany trwale w bazie użytkownika i przeżywa restart usługi, czego pamięć podręczna nie robi.

Sytuacje, w których analiza kończy się niczym

Najbardziej frustrujący przypadek to procedura utworzona z opcją szyfrowania — funkcja zwraca wtedy wartość NULL w kolumnie z tekstem i znacznik informujący o zaszyfrowaniu, a jedynym wyjściem jest kontakt z dostawcą oprogramowania. Drugi to wyczyszczona pamięć podręczna: po restarcie usługi SQL Server, po zmianie części ustawień konfiguracyjnych albo po ręcznym wywołaniu polecenia czyszczącego cache uchwyty przestają być rozwiązywalne i zapytanie zwraca pusty wynik. Trzeci dotyczy praw dostępu — analiza wymaga uprawnienia VIEW SERVER STATE, a przy jego braku widoczne są wyłącznie własne polecenia. Warto też uważać na wynik przy zapytaniach składanych dynamicznie w aplikacji, gdzie każde wywołanie z inną wartością tworzy osobny wpis i zaśmieca cache setkami niemal identycznych tekstów.

Analiza obciążenia serwera przed rozbudową

Zanim firma kupi mocniejszy serwer, warto sprawdzić, czy problemem jest sprzęt, czy kilka źle napisanych raportów. Odczytujemy realne teksty najcięższych zapytań w instancjach obsługujących Subiekta, WAPRO i Comarch, zestawiamy je z zużyciem procesora i odczytami dysku, a potem wskazujemy, co da się poprawić indeksem, a co wymaga zmiany po stronie sprzętu. Pracujemy także w nocy i w weekendy, kiedy można bezpiecznie zbierać dane z produkcji.