Include Actual Execution Plan

Include Actual Execution Plan to opcja SSMS pokazująca rzeczywisty sposób wykonania zapytania po jego uruchomieniu.

Co oznacza opcja Include Actual Execution Plan w SSMS

Include Actual Execution Plan to polecenie dostępne w SQL Server Management Studio, znanym jako SSMS, które powoduje dołączenie do wyników zapytania rzeczywistego planu wykonania. Plan pokazuje operacje faktycznie wykonane przez aparat zapytań SQL Server podczas realizacji instrukcji. W odróżnieniu od planu szacowanego nie opisuje wyłącznie przewidywań optymalizatora, lecz zawiera także informacje zebrane w trakcie działania zapytania, między innymi rzeczywistą liczbę wierszy przetworzonych przez poszczególne operatory.

Opcja działa dla zapytań uruchamianych w edytorze SSMS po jej włączeniu przed wykonaniem instrukcji. Można ją aktywować z menu Query lub za pomocą skrótu klawiaturowego Ctrl+M. Po uruchomieniu zapytania SSMS wyświetla dodatkową kartę Execution Plan obok kart Results i Messages. Plan ma postać graficznego drzewa operatorów połączonych strzałkami. Kierunek przepływu danych jest przedstawiony od prawej do lewej, dlatego operator znajdujący się po prawej stronie zwykle reprezentuje początkowy etap dostarczania danych, a operator po lewej stronie przekazuje końcowy rezultat.

Informacje widoczne w rzeczywistym planie zapytania

Każdy operator planu opisuje konkretną czynność wykonaną przez SQL Server, na przykład skanowanie indeksu, wyszukiwanie po indeksie, filtrowanie, sortowanie, łączenie tabel albo agregowanie wyników. Po wskazaniu operatora można odczytać jego właściwości. Szczególnie ważne są wartości Actual Number of Rows, Actual Number of Rows Read, Actual Executions oraz Estimated Number of Rows. Pierwsza z nich informuje, ile wierszy operator przekazał dalej, druga może pokazywać, ile wierszy odczytano przed zastosowaniem dodatkowych filtrów, a Actual Executions określa liczbę wykonań operatora.

Rzeczywisty plan może zawierać ostrzeżenia sygnalizowane ikoną żółtego trójkąta. Ich znaczenie zależy od operatora i właściwości planu. Ostrzeżenie może wskazywać między innymi na konwersję niezgodnych typów danych, operację sortowania wymagającą dodatkowej pamięci albo przekierowanie części pracy do tempdb. Samo ostrzeżenie nie jest automatycznie dowodem błędu. Powinno zostać powiązane z czasem wykonania, zużyciem zasobów, liczbą odczytów logicznych oraz charakterem badanego zapytania.

W planie rzeczywistym można także porównać estymowaną i rzeczywistą liczbę wierszy dla poszczególnych operatorów. Duża różnica między tymi wartościami jest określana jako niedokładność estymacji kardynalności. Może wynikać na przykład z nieaktualnych statystyk, nietypowego rozkładu danych, filtrów zależnych od parametrów albo konstrukcji predykatu utrudniającej optymalizatorowi ocenę selektywności. Taka rozbieżność może prowadzić do wyboru niekorzystnego planu, lecz jej interpretacja wymaga sprawdzenia całego przepływu danych.

Różnica między planem rzeczywistym a szacowanym

Szacowany plan wykonania można wyświetlić przed uruchomieniem instrukcji za pomocą Display Estimated Execution Plan, czyli skrótu Ctrl+L. SQL Server tworzy wtedy plan na podstawie tekstu zapytania, metadanych tabel, indeksów, statystyk oraz przewidywanych parametrów. Nie są jednak wykonywane wszystkie operacje zapytania, więc szacowany plan nie zawiera obserwacji z faktycznego przebiegu. Jest przydatny do analizy decyzji optymalizatora bez uruchamiania potencjalnie kosztownej instrukcji.

Actual Execution Plan wymaga wykonania zapytania, dlatego może powodować odczyty danych, blokowanie, zużycie pamięci i obciążenie procesora tak samo jak zwykłe uruchomienie analizowanej instrukcji. W przypadku zapytań modyfikujących dane należy uwzględnić ich skutki transakcyjne; dołączenie planu nie zamienia instrukcji w tryb testowy ani nie wycofuje automatycznie zmian. Rzeczywisty plan jest więc narzędziem obserwacyjnym, a nie mechanizmem izolującym zapytanie od jego normalnego działania.

Wyniki planu należy interpretować razem z innymi pomiarami. Pomocne mogą być statystyki czasu i odczytów, włączane w T-SQL poleceniami SET STATISTICS TIME ON oraz SET STATISTICS IO ON. Execution Plan pokazuje strukturę wykonania, natomiast komunikaty STATISTICS TIME dostarczają informacji o czasie procesora i czasie całkowitym, a STATISTICS IO o odczytach logicznych i fizycznych. Dopiero zestawienie tych danych pozwala ocenić, czy kosztowny operator rzeczywiście odpowiada za problem wydajnościowy.

Wykorzystanie planu podczas analizy problemów z SQL Server

Rzeczywisty plan wykonania pomaga sprawdzić, czy SQL Server użył oczekiwanego indeksu, czy wykonał skan całej tabeli oraz czy liczba przetwarzanych wierszy odpowiada założeniom zapytania. W planach z operatorami Nested Loops, Hash Match lub Merge Join można prześledzić sposób połączenia danych. Należy zwrócić uwagę na wejścia operatorów, kolejność ich wykonania, przepływ wierszy oraz relację między kosztem szacowanym a rzeczywistym. Procentowy koszt operatora jest wartością wyliczaną względem konkretnego planu, a nie uniwersalną miarą czasu wykonania.

Podczas diagnostyki warto zapisać plan do pliku .sqlplan, aby można było przeanalizować go później albo porównać z planem uzyskanym po zmianie zapytania, indeksu lub statystyk. Plan może zawierać tekst instrukcji, nazwy obiektów bazy danych, nazwy kolumn oraz wartości parametrów. Z tego powodu plik planu powinien być przekazywany wyłącznie w zakresie koniecznym do analizy i przechowywany w sposób zgodny z zasadami obowiązującymi w danym środowisku. Jeżeli problem występuje tylko dla wybranych parametrów, trzeba wykonać porównanie planów dla reprezentatywnych przypadków, ponieważ jeden plan nie musi opisywać wszystkich wariantów danych.

Jeżeli SSMS nie pozwala włączyć rzeczywistego planu albo nie wyświetla karty Execution Plan, przyczyną może być użycie niewłaściwego typu połączenia, ograniczenia uprawnień lub specyfika wykonywanego polecenia. Sam plan nie naprawia zapytania i nie aktualizuje indeksów ani statystyk. Stanowi dowód przebiegu wykonania, który należy zestawić z definicją tabel, indeksami, statystykami, parametrami, blokadami oraz obciążeniem instancji SQL Server. W praktycznej diagnostyce komputera używanego do pracy z SSMS sprawdza się również poprawność połączenia, stabilność systemu i dostępność zasobów potrzebnych do uruchomienia narzędzia.