Viime blogissani kuvasin, miten wait statsit syntyvät SQLOS:ssä. Tällä kertaa aihe on hieman maanläheisempi: Vilkaisemme SQL Serverin query planeja wait statsien näkökulmasta.
Johdanto
Tähän mennessä olemme tutkiskelleet lähinnä kumulatiivista wait stats-tietoa. Tämä ei kuitenkaan yksistään riitä, mikäli haluamme saada kunnolla ”sarvista härkää”, jotta pystyisimme diagnosoimaan ja optimoimaan yksittäisiä T-SQL-kyselyitä, eritoten vilkkaissa OLTP-systeemeissä. Tämän takia Wait statsien tutkiskelu query planien näkökulmasta auttaa meitä ymmärtämään, mihin vaiheisiin yksittäiset kyselyt polttavat aikaa ja resursseja – yksittäinen kysely kun voi saada, lukuisista ympäristömuuttujista riippuen; kovinkin erilaisia query planeja ajettavakseen SQL Server enginessä.
Mennäänpä historiassa hieman taaksepäin: SQL Server 2016 SP1 oli ensimmäinen SQL Serverin versio, joka alkoi kaapata wait statseja T-SQL-kyselyiden suoritussuunnitelmiin (=query execution plan) ja saatoit visualisoida tämän SSMS:ssä. Ominaisuuden myötä saa kiinni täsmälleen kyselyyn käytetyn wait timen wait counteittain ja wait typeittäin, tosin ainoastaan yksittäisiin kyselyihin pohjautuvan todellisen suoritussuunnitelman (=actual exucition plan) mukaan. Tämä eroaa oletetusta suoritussuunnitelmasta (=estimated execution plan) seuraavasti:
- Estimated execution plan on se oletettu suoritussuunnitelma, jonka SQL Server engine kääntää sen hetkisiin tietoihinsa, kuten kyselyyn, tietomalliin, avaimiin, indekseihin ja taulustatistiikkaan perustuen suorittamatta itse kyselyä. Tästä suunnitelmasta ei siksi voi saada wait statseja.
- Actual execution plan taas on se suoritussuunnitelma, jota SQL Server engine joutuu lopulta käyttämään saadakseen kyselyn suoritettua. Nämä voivat joskus poiketa toisistaan radikaalistikin.
Versio 2019:stä lähtien SQL Serverin Query Store on historioinut estimated execution planin. Tämä halpottaa osaltaan myös wait stats-analyysiä, koska voit linkittää niitä kyseiseen query execution planiin. Tulokset ovat kuitenkin indikatiivisia, koska estimated execution plan tosiaan poikkeaa monasti actual execution planista, etenkin jos statistiikat ovat tietokantatauluissa kuralla.
SQL Server Management Studiossa (=SSMS) voit kätevästi näyttää kyselyn oletetun suoritussuunnitelman valitsemalla ”Include Estimated Execution Plan” -option (heti V-merkin oikealla puolella). Tämä saa SQL Serverin enginen kääntämään oletetun kyselysuunnitelman ja näyttää sen sinulle:
Klikkaamalla suoritussuunnitelman SELECT listiä hiiren oikealla, saat query plan propertyt esille:
Kuten huomataan, wait statseja ei vielä ole tässä vaiheessa syntynyt, koska kyselyä ei ole ajettu. Seuraavaksi, aktivoi ”Include Actual Execution Plan” -optio muutama ikoni oikeammalta ennen kyselyn suorittamista ja aja kysely query analyzerissa, jolloin saat actual execution planin (=Execution plan -tabi):
➜
➜
Kuten kuvasta näkyy, query planista avautuu varsin kattava ja valaiseva ominaisuuslistaus, kuten:
- Query planin koko kilotavuina
- Käännösaika (ms)
- Maxdop -asetus (=looginen coremäärä, joka parallelisoidaan kyselylle mikäli ei-sekventiaalinen)
- Arvioidut rivimäärät
- Arvioitu suoritusaika valitulle operaattorille
- QueryHash
- QueryPlanHash
- Wait statsit
Esimerkiksi tässä kyselyssä odoteltiin verkkoa, muistiallokaatiota ja levyoperaatioita, oikeastaan tarkemmin ottaen skannattiin levypinnasta klusteroitua pääavainta (=taulun läpiluku) ja allokoitiin datasivut buffer cacheen. Kustakin wait typestä nähdään, kuinka monta kertaa kyseinen wait type kohdattiin suoritettaessa kyselyä, sekä kuinka monta millisekuntia wait timeä kertyi kaikkiaan.
Yhteenveto
Kuten huomataan, SQL Serverissä on tätä nykyä kohtuullinen tuki wait statsien seurantaan yksittäisellä kyselytasolla. Kuitenkin ainakin allekirjoittanut jää kaipaamaan ominaisuutta, jossa query store tallentaisi actual execution planin reaaliaikaisten wait statsien kanssa. Liekö ollut käytännössä liian raskas ominaisuus kun ei ole vielä toteutettu, tiedä häntä. Seuraavassa blogissani kurkataan query storeen wait statsien näkökulmasta. Tähän ominaisuuteen et voi juuri olla törmäämättä diagnosoidessasi uudempia SQL Server-ympäristöjä. Siihen saakka; koodailemisiin!
