Widok sys.dm_exec_query_plan

sys.dm_exec_query_plan zwraca plan wykonania zapytania na podstawie jego uchwytu.

Miejsce widoku w rodzinie obiektów dynamicznych

W dokumentacji SQL Servera obiekt bywa opisywany raz jako widok dynamiczny, raz jako funkcja zarządzania dynamicznego. Formalnie należy do drugiej grupy: nie da się go odpytać samodzielnie instrukcją SELECT * FROM, bo wymaga argumentu. Cała rodzina obiektów o przedrostku dm_exec_ opisuje wykonywanie kodu — obok planu dostępny jest sys.dm_exec_sql_text zwracający tekst instrukcji, sys.dm_exec_text_query_plan pozwalający pobrać plan jako zwykły tekst z możliwością wycięcia fragmentu po numerze instrukcji, oraz sys.dm_exec_cached_plans opisujący same wpisy w pamięci podręcznej wraz z licznikiem użyć.

Typowy sposób łączenia z pozostałymi widokami

Praktyczne zapytanie diagnostyczne łączy trzy elementy: sys.dm_exec_query_stats jako źródło uchwytów i metryk, sys.dm_exec_sql_text dla treści zapytania i omawiany obiekt dla planu. Sortowanie po kolumnie total_worker_time podzielonej przez execution_count pokazuje zapytania najdroższe w przeliczeniu na jedno wykonanie, sortowanie po samej total_logical_reads wskazuje te, które najmocniej obciążają dyski. Warto pamiętać o kolumnach statement_start_offset i statement_end_offset — bez nich z procedury składowanej wyciąga się cały jej tekst zamiast konkretnej instrukcji, która zajmuje procesor. Offsety liczone są w bajtach, a nie w znakach, co przy typie nvarchar oznacza dzielenie przez dwa.

Rzeczy, które łatwo źle zinterpretować

Wartości w cache dotyczą wyłącznie czasu od ostatniego restartu usługi lub ostatniego wyczyszczenia pamięci podręcznej — po ponownym uruchomieniu serwera obraz jest pusty i przez pierwsze godziny mylący. Drugi błąd to szukanie w cache zapytań wykonywanych z opcją RECOMPILE albo z podpowiedzią OPTION (RECOMPILE), bo ich plany nie są przechowywane i nie pojawią się w zestawieniu mimo realnego obciążenia. Trzeci to plany równoległe: dokument XML zawiera wtedy operatory wymiany, a odczyt kosztów bez uwzględnienia stopnia równoległości prowadzi do zawyżonych wniosków. Wreszcie na serwerze z bardzo dużą liczbą różniących się parametrami zapytań ad hoc cache zapycha się jednorazowymi planami i sensowna analiza wymaga wcześniejszego włączenia opcji optimize for ad hoc workloads.

Pomoc przy spowolnieniach systemów magazynowych

Zgłoszenia brzmiące „program działa wolno” prawie nigdy nie mają jednej przyczyny — bywa nią przeciążony dysk stacji roboczej, ale równie często zapytanie skanujące tabelę bez indeksu. Warszawskie Pogotowie Komputerowe rozdziela te dwa światy: sprawdzamy nośnik i pamięć na stanowisku, a równolegle zdejmujemy obraz obciążenia z serwera bazodanowego. Obsługujemy zarówno pojedyncze stanowiska klientów indywidualnych, jak i firmowe serwery z oprogramowaniem handlowym. Sprzęt wymagający wymiany podzespołów odbieramy i odwozimy własnymi kierowcami, bez pośrednictwa firm kurierskich.