Modyfikacja planu wykonania przy wykorzystaniu Plan Guide

PlanGuides_00

Do napisania niniejszego artykułu skłoniło mnie pytanie jakie usłyszałem na jednym ze spotkań Data Community. Chodziło w nim mianowicie o to, że zadający miał problem z zapytaniem, którego nie mógł zmodyfikować, a plan wykonania jaki wybierał SQL Server jest całkowicie nieakceptowalny i niewydajny. Dodam jeszcze, że osoba ta nie miała do dyspozycji Query Store i najnowszej wersji SQL Server. Jakie jest jedno z rozwiązań tego problemu? O tym postaram się dziś opowiedzieć.

Często zdarza się, że zapytania zostały napisane przez kogoś innego, a my musimy radzić sobie z ich optymalizacją. Jeszcze gorszym scenariuszem jest fakt, że nie możemy zmodyfikować samego zapytania, a wiemy, że ktoś użył tam niewłaściwego hinta który więcej szkodzi niż pomaga. W cache możemy również zaobserwować, że SQL Server wybrał niezbyt optymalny algorytm złączenia – co możemy w takiej sytuacji zrobić? Mamy kilka możliwości (szczególnie w nowszej wersji SQL Server) i jedną z nich jest bohater niniejszego artykułu, a mianowicie Plan Guide, który pozwala nam wpływać na zapytania bez modyfikacji ich właściwej treści – zapraszam do lektury.

Algorytm działania SQL Server w tym aspekcie przedstawia się następująco:

Tak jak możecie zauważyć do standardowej ścieżki postępowania doszło sprawdzenie czy nie ma zdefiniowanego plan guide. W tym miejscu warto zdać sobie sprawę, że Plan Guide nie eliminuje kompilacji i sam w sobie nie ma na nią jakiegoś magicznego wpływu.

Aby zobrazować działanie tego mechanizmu stwórzmy sobie najpierw następującą procedurę:

Przypuśćmy, że w takiej formie kod dostarczył do nas dostawca i my w żaden sposób nie możemy go zmieniać. Jak widzimy nie jest to majstersztyk i cechuje go kilka rzeczy, które przysparzają nam problemów tj. hint MAXDOP 1, który ogranicza nasze zapytanie do tego aby działało na jednym wątku, oraz wymuszenie algorytmu złączenia NESTED LOOPS. Oba hinty nie są zbyt bezpieczne i mogą powodować problemy wydajnościowe. Plan tego zapytania wygląda następująco:

Widzimy, że analizowane przez nas zapytanie jest jednowątkowe i jedynym użytym algorytmem złączenia zgodnie z wpisanym hintem jest Nested Loops. Samo zapytanie wykonuje się bardzo długo można powiedzieć, że wręcz nieakceptowalnie. Spróbujmy to w jakiś sposób naprawić – aby to zrobić użyjemy wspomnianego już Plan Guide. Możemy go stworzyć na kilka sposobów, w tym miejscu zrobimy to za pomocą procedury składowanej o nazwie sp_create_plan_guide:

Jak możecie zauważyć procedura ta przyjmuje kilka parametrów – powiedzmy o nich kilka słów:

  • name – nazwa plan guide
  • stmt – zapytanie do którego będziemy się odnosić (musi to być dokładnie takie zapytanie jak w procedurze/zapytaniu adhoc inaczej plan guide nie zadziała lub nie zostanie stworzony. Nawet najmniejszy biały znak spowoduje, że hash z ciągu znaków zapytania będzie inny co uniemożliwi użycie guide’a.)
  • type – mamy do dyspozycji trzy typy guide’ów:
    • OBJECT – odnosi się do obiektów takich jak procedury, funkcje użytkownika czy też np. wyzwalacze
    • SQL – odnosi się do zapytań adhoc nie będących częścią żadnego obiektu
    • TEMPLATE – specjalny typ odnoszący się do zapytań adhoc pozwalający na nadpisanie ustawienia PARAMETRIZATION
  • module_or_batch – nazwa modułu (np. procedury) jeśli tworzymy plan guide typu OBJECT
  • params – dla plan guide SQL oraz TEMPLATE ciąg parametrów dla których ma być zastosowany dany plan guide
  • hints – hinty jakie mają zostać dołączone do zapytania (dołączone jako OPTION w zapytaniu podanym w parametrze stmt). Jeśli przekażemy do tego parametru NULL to będzie to równoznaczne z usunięciem wszystkich hintów z zapytania.

Całkiem dużo możliwości i może się to wydawać dosyć skomplikowane jednakże w rzeczywistości jest kompletnie inaczej. W powyższym Plan guide użyliśmy typu OBJECT ze względu na fakt, że chcemy go zastosować do kodu TSQL, który jest wewnątrz procedury składowanej. Po jego stworzeniu i wykonaniu procedury raz jeszcze plan zapytania wygląda następująco:

Zniknęły problematyczne złączenia Nested Loops, a samo zapytanie może wykorzystać wiele wątków bo hint MAXDOP 1 został usunięty. Proste prawda? A to jeszcze nie wszystko co mamy do dyspozycji.

Omawiane obiekty mogą również być pomocne w przypadku gdy mamy do czynienia z negatywnymi skutkami tzw. parameter sniffingu przy skośnym rozkładzie częstości. Możemy wtedy wymusić optymalizację dla konkretnej wartości parametru – dla przykładu poniżej znajdziecie definicję kolejnej procedury testowej o nazwie GetInvoicLinesByTaxRate, która przyjmuje jeden parametr:

Procedura nie jest stabilna bo w zależności od wartości parametru otrzymujemy różne plany zapytania.

Dla wartości 15:

Dla wartości 10:

Mamy zatem do czynienia z klasycznym wyborem pomiędzy Nested Loops, a Hash Match – przypuśćmy, że naszym celem będzie “zasugerowanie” aby optymalizacja była wykonana dla wartości parametru 15 gdyż zdecydowana większość wywołań tej procedury zawiera właśnie tą wartość. Do tego celu użyjemy oczywiście OPTIMIZE FOR:

Po ponownym uruchomieniu procedury z wartością 10 zobaczymy, że wartością skompilowaną tego parametru jest 15:

Szybko i bez większego wysiłku problem został rozwiązany bez najmniejszej ingerencji w kod procedury.

Kolejną funkcjonalnością o jakiej chciałbym wspomnieć jest wymuszenie konkretnego planu wykonania dla danego zapytania. Myślę, że aktualnie jeśli kogoś zapytamy o to w jaki sposób wymusić plan zapytania to w przeważającej ilości przypadków usłyszymy “Query Store”, ale również dobrą odpowiedzią jest Plan Guide! Może nie jest to aż tak łatwe jak w przypadku QS ale jednak da się – sprawdźmy jak możemy tego dokonać. Zanim przejdziemy do właściwego zadania usuńmy plan guide który stworzyliśmy w poprzednim przykładzie – użyjemy do tego celu procedury sp_control_plan_guide:

Procedura ta służy za wiele operacji na Plan Guide i może ona przyjmować następujące samo opisujące parametry:

  • DROP
  • DROP ALL
  • DISABLE
  • DISABLE ALL
  • ENABLE
  • ENABLE ALL

Oczywiście jeśli wybierzemy z powyższej listy którąś z operacji “ALL” to nie podajemy nazwy Plan Guide ponieważ odnosi się ona do wszystkich obiektów tego typu w bieżącej bazie danych.

Wracając do meritum czeka nas dosyć problematyczne zadanie – musimy mianowicie znaleźć plan, który chcemy wymusić. Jak to zrobić? Myślę, że najłatwiej ściągnąć go z cache – wykonajmy naszą procedurę z poprzedniego przykładu parametrem 15 bo właśnie plan dla tego parametru nas interesuje:

Następnie używając widoków dynamicznych możemy podejrzeć cache i znajdujący się w nim plan zapytania. Oczywiście warunek WHERE powinien być napisany tak aby jednoznacznie określić zapytanie o które nam chodzi:

Możemy taki plan wykorzystać w plan guide – najlepiej przypisać sobie go do zmiennej gdyż kopiowanie z rezultatu SSMS może nie być najlepszym rozwiązaniem gdyż narzędzie to nie wyświetla całej wartości w przypadku długich stringów, a jedynie jej przyciętą formę:

Nasz Plan guide został stworzony – dlatego też możemy go przetestować dla wartości 10 znanego już parametru@TaxRate:

Plan wykonania oczywiście wyglądał tak jak było to zamierzone – dodatkowo warto zwrócić uwagę na właściwość “Use plan” która ustawiona na True daje nam informację, że plan został wymuszony:

Oczywistym jest fakt, że sprawdzanie działania omawianego mechanizmu w taki sposób nie jest najlepszym pomysłem w przypadku środowisk produkcyjnych. Aby sprawdzić czy Plan guide działa w prawidłowy sposób możemy również użyć Profilera lub Extended Events – postaram się to przedstawić na podstawie tego drugiego narzędzia. Skrypt tworzący sesję wygląda następująco:

Będziemy śledzić dwa zdarzenia plan_guide_successful oraz plan_guide_unsucessful, których znaczenia chyba nie trzeba omawiać. Po uruchomieniu naszej sesji xE i kilkukrotnym uruchomieniu procedury testowej w pliku wynikowym znalazłem następujące wpisy:

Oczywiście niepowodzenie również może zostać przez nas zarejestrowane. Zdarzenie to pojawi się wtedy gdy nasz plan z jakiegoś powodu nie może zostać wymuszony. Dla przykładu usuńmy indeks klastrowany PK_Sales_Invoices z tabeli (wcześniej trzeba usunąć wszystkie klucze obce do niego się odnoszące):

Po raz kolejny po uruchomieniu zapytania testowego nasz plik śledzący odnotował to czego się spodziewaliśmy:

Wytłumaczenie jest tutaj również oczywiste gdyż SQL Server chciał użyć Plan Guide ale ze względu na fakt, iż indeks który w planie wskazanym przez Plan Guide nie istnieje to cała struktura musiała zostać zignorowana i plan musiał zostać wygenerowany na nowo. W przypadku gdy musimy sprawdzić czy nasze Plan Guide działają (np. po migracji)  możemy użyć Extended Events lub funkcji sys.fn_validate_plan_guide w połączeniu z widokiem sys.plan_guides:

Jak możecie zauważyć mamy tutaj komplet informacji wraz z informacją o tym dlaczego plan nie może zostać użyty. Osobiście jeśli miałbym wybierać to ten sposób jest dużo bardziej przyjazny niż XE i z nim polecam się zapoznać.

Wiemy zatem jak działać z Plan Guide oraz z zapytaniami będącymi częścią obiektów takich jak procedury składowane. Jak wspomniałem już wcześniej możemy również używać tego mechanizmu dla zapytań adhoc jednakże jest to o wiele rzadziej używane podejście. Jest to również problematyczne gdyż najmniejszy komentarz czy tez inna zmiana powoduje, że z perspektywy SQL Server jest to całkowicie inne zapytanie. Tworzenie PG przy pomocy procedury sp_create_plan_guide jest bardzo podobne do omówionego wcześniej przykładu dla procedur składowanych z tym, że dla parametru type tejże procedury podajemy SQL dlatego też pozwolę sobie ominąć omawianie tego przypadku. Pokażę Wam natomiast dodatkową opcję pozwalającą na wymuszenie planu, a jest nią hint USE PLAN. Zanim do niego przejdziemy przywrócćmy wcześniej usunięte klucze:

Użycie USE PLAN nie odbiega od użycia standardowych hintów i w naszym przypadku testowym wygląda następująco:

Patrząc na to jak trzeba plan wymusić zdaję sobie sprawę z wielu trudności jakie to przysparza. Nigdy nie używajcie tego w swoim kodzie “na sztywno” – jedyne zastosowanie jakie przychodzi mi do głowy to sytuacja gdy testujemy różne warianty wydajnościowe itp.

Ostatnim elementem, o którym chciałbym wsponieć jest Plan guide typu Template, który pozwala sterować trybem parametryzacji. Jednakże aby się nie powtarzać się odsyłam Was do artykułu, który opisuje ten aspekt i omawia pokrótce plan guide z nim związany – znajdziecie go tutaj.

To by było na tyle jeśli chodzi o Plan Guide. Jak zapewne zauważyliście jest to bardzo ciekawy mechanizm w SQL Server i już nieco zapomnianym mimo obecności w naszym ulubionym siliniku bazodanowym od wersji 2005. Współcześnie dużo łatwiej użyć Query Store do analogicznych operacji jednakże nie każdy posiada SQL Server 2016 lub wyżej. Według mnie usuwanie hintów z zapytań jest bardzo proste w tym mechanizmie i właśnie tutaj wypatrywał bym szansy na efektywne użycie Plan Guides. To co wydaje się logiczne to fakt, żeby oczywiście nie nadużywać opisywanego mechanizmu i używać go z dużą ostrożnością co zresztą dotyczy większości rzeczy związanych z SQL Server. Mimo wszystko mam nadzieję, że wiedza ta komuś się przyda bo w tym wypadku jak i wielu innych “lepiej znać niż nie”.

Adrian Chodkowski
Follow me

Adrian Chodkowski

SQL geek, Data enthusiast, Consultant & Developer
Adrian Chodkowski
Follow me

Leave a Comment

Your email address will not be published. Required fields are marked *