SYS.DM_EXEC_SQL_TEXT

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

Funkcja, a nie widok — i co z tego wynika

Mimo że w rozmowie nazywa się ją widokiem, sys.dm_exec_sql_text jest funkcją tablicową przyjmującą argument. Podaje się jej sql_handle albo plan_handle, a w odpowiedzi otrzymuje jeden wiersz z kolumnami dbid, objectid, number, encrypted oraz text zawierającą treść wsadu. Skoro wymaga argumentu, nie da się jej odpytać zwykłym SELECT bez źródła uchwytów — łączy się ją operatorem CROSS APPLY z widokiem dostarczającym uchwyty, najczęściej sys.dm_exec_requests przy analizie bieżącej albo sys.dm_exec_query_stats przy szukaniu najbardziej kosztownych zapytań w historii pamięci podręcznej planów.

Wyciąganie pojedynczej instrukcji z długiej procedury

Kolumna text zwraca cały wsad lub całe ciało procedury składowanej, co przy kilkusetliniowym kodzie nie mówi nic o tym, która instrukcja właśnie się wykonuje. Rozwiązaniem są kolumny statement_start_offset i statement_end_offset z sys.dm_exec_requests, wyrażone w bajtach — ponieważ tekst przechowywany jest w Unicode, przy wycinaniu funkcją SUBSTRING trzeba je podzielić przez dwa i dodać jeden do pozycji początkowej. Wartość -1 w offsecie końcowym oznacza koniec wsadu i wymaga osobnej obsługi. Ten szczegół odróżnia zapytanie diagnostyczne, które faktycznie wskazuje winowajcę, od takiego, które zrzuca ścianę kodu i zostawia analityka bez odpowiedzi.

Kiedy zwracany tekst jest bezużyteczny

Dla obiektów zaszyfrowanych klauzulą WITH ENCRYPTION kolumna encrypted przyjmuje wartość jeden, a text zwraca NULL — nie jest to błąd, lecz świadome zachowanie silnika. Drugi przypadek to uchwyt, którego plan zdążył wypaść z pamięci podręcznej: funkcja zwróci pusty zestaw, bo tekst jest przechowywany razem z planem, a nie trwale zapisany. Dlatego analiza wykonana godzinę po incydencie potrafi już niczego nie znaleźć, zwłaszcza po restarcie usługi albo po wyczyszczeniu cache. Trzecia trudność dotyczy zapytań parametryzowanych przez sterownik aplikacji — zobaczymy wtedy postać z parametrami sp_executesql, a nie kod widoczny w programie. Do tego dochodzi wymóg uprawnienia VIEW SERVER STATE, bez którego całe zapytanie diagnostyczne po prostu nie ruszy.

Znajdowanie zapytania, które zatrzymuje pracę biura

W programach opartych o SQL Server rzadko wiadomo, co dokładnie robi aplikacja w tle. Kiedy Subiekt, WAPRO lub Comarch stają na kilka minut, odczytujemy realną treść wykonywanego polecenia, dopasowujemy ją do operacji w programie i wskazujemy przyczynę: raport bez odpowiedniego indeksu, kolizja z zadaniem kopii zapasowej albo pętla po dokumentach. Naprawę prowadzimy zdalnie lub na miejscu, w terminie dopasowanym do pracy firmy.