Avatar billede dsj Nybegynder
22. august 2004 - 00:46 Der er 12 kommentarer og
1 løsning

Hjælp til forståelse af Execution Plan

Jeg sidder i øjeblikket og forsøger at forstå den execution plan, som query analyzeren kommer op med på baggrunden af et T-SQL statement, for bedre at være i stand til at vælge indekseringer. Jeg forstår så småt hvad de forskellige ikoner i den grafiske oversigt betyder, og forstår hvordan den bygger resultatet op.

De statements jeg arbejder med er forholdsvis komplekse, og kan indrage op til 6-8 joins, aggregat-funktioner og deslige. Dette kan måske lyde af meget, især i betragtning af, at flere af tabellerne kan indeholde betragtlige mængder data (ca. 2 mio., og voksende med tid).

Mit problem er så at forstå de forskellige indikatorer på omkostninger, som indgår i den grafiske oversigt:

1.
Under hvert ikon/operation er står: "Cost x%", men jeg synes ikke at kunne finde en sammenhæng mellem tilstødende operationer. Nogle står der 600% ved, mens andre i samme query har 0% eller 500%. Hvad er denne procent et udtryk for, og i forhold til hvad?

2.
Det er lykkedes mig, ved at sætte nogle, efter min mening, fornuftige indekseringer, at få 0% under samtlige operationer (ca. 20 i alt), og samtidig står foroven i rapporten: "Query 1: Query cost (relative to the batch): 0,00%". Er dette et godt tegn, eller hvad er alle de mange 0% et udtryk for?

3.
I den lille, gule info-popup for hver enkelt operation, står en række cost-indikatorer. Nogle operationer har værdien "Cost" angivet, andre ikke - dette undrer mig lidt. Nogle har Subtree cost sat til 0, mens sub-operationer har f.eks. 9, hvordan kan dette lade sig gør?

4.
Hvilke indikatorer er de vigtige, når man skal finde og minimere de mest omkostningsfulde operationer, og hvordan kan man sammenligne de forskellige operationers omkostninger?

Ja, disse spørgsmål er nok ikke for enhver, men mon ikke der er nogen der kan svare på dem alligevel? :-)
Avatar billede trer Nybegynder
23. august 2004 - 10:34 #1
Query tuning er ikke nemt - hvad der er godt afhænger meget af situationen, det primære er jo, at du får de data ud du har behov for.

http://www.microsoft.com/sql har der tidligere været en del vejledninger i tuning og forklaring om hvorledes Execution plan forstås og anvendes, de er der sikkert endnu - det er et komplekst område, men absolut værd at løbe gennem. I artikel sektionen har jeg en række artikler liggende om tuning af sql på sql server, de er måske også værd at løbe gennem, omend de er meget grundlægggende.

Grundlæggende skal du holde øje med, at tablescan ikke sker (det er tegn på manglende / forkerte indeks), at afskæring sker korrekt (dvs. at query optimizeren får fjernet så mange rækker som muligt så tidligt som muligt) og at det estimerede antal rækker for hver operation matcher det faktiske antal rækker.  Der er nogle ting vedr. valg af join typer (som jeg husker det, bør et produktionssystem ikke anvende HASH joins) og anvendelse af bookmark operationer (som giver overhead og bør undgås) - og vigtigt; Man bør altid tune ved at indsætte hints i sql'en.

De forskellige procenttal for operationer skal du ikke hænge dig i som det første (de afsindige procenter har jeg heller ikke haft held med at få til at give mening) - mens cost relative to batch er mere interessant. At den giver 0% lugter af for mig af at din klient mangler at få installeret SP3a.

Har du to queries fortæller Cost relative to batch hvor meget de hver i sær vægter af det fulde load - det er perfekt til at sammenligne effektiviteten af to sql'er.
Avatar billede dsj Nybegynder
23. august 2004 - 10:58 #2
Nu får jeg de ønskede data ud, og derfor er det primære pt. at få tunet indekseringerne. I tabelstrukturen er der taget højde for de værste flaske-halse ved bevidst at køre med redundante data i visse tilfælde.

Jeg er godt klar over hvilke operationer man bør undgå, og hvilke man bør stræbe efter. Det jeg godt vil vide er, hvordan jeg tyder de forskellige omkostnings-indikatorer.

Hvad er SP3a? (Service Pack 3a, men til hvad?)
Avatar billede dsj Nybegynder
23. august 2004 - 11:16 #3
Ja, har fundet den til SQL Server - takker for tippet :-)
Avatar billede trer Nybegynder
23. august 2004 - 13:03 #4
OBS:

Fejl i min kommentar: "og vigtigt; Man bør altid tune ved at indsætte hints i sql'en." - bør rettelig være "og vigtigt; Man bør *ALDRIG* tune ved at indsætte hints i sql'en." 

Hints forhindrer nemlig sql server i ændre query plan såfremt datagrundlaget ændrer sig...

De costs (i faste værdier) man finder har svjv kun betydning i fht parallelisme hvor bl.a. antal af filer pr filgruppe også spiller ind (jo flere filer, jo flere parallelle tråde vælger sql server at anvende - hvad der kan lægge et filsystem fladt ned). Procenttallene kigger jeg aldrig på på de enkelte subtræeer eller operationer - jeg nøjes med at se på dem når man sammenligner flere statements i en batch.
Avatar billede dsj Nybegynder
23. august 2004 - 13:17 #5
Nu har jeg i langt de fleste tilfælde kun ét statement pr. batch, og derfor har jeg ikke noget sammenligningsgrundlag. Derfor ville jeg gerne vide, hvordan omkostningerne kunne sammenlignes operationerne imellem.
Avatar billede trer Nybegynder
23. august 2004 - 13:45 #6
Jep, det du kan anvende er, at du tager dit oprindelige udtryk som første statement i en batch, så kopierer du det og paster det ind som andet udtryk. Nu tuner du på udtryk 2 i fht udtryk 1 - du kan f.eks. låse udtryk et til den oprindelige query plan vha indekshints eller midlertidigt bruge hints til at tune udtryk 2 - eller du skriver simpelthen sql'en om fra bunden som udtryk 2.

Cost værdierne kan du så ellers kun bruge til noget ved at forsøge at få dem så langt ned som muligt - men der er ikke noget rigtig fingerpeg om hvad der er "for højt". Tager et udtryk for lang tid eller er for stor en belastning på serveren må man forsøge at skrive det om, evt. fra bunden fremfor at indeks-tune.
Avatar billede venne Nybegynder
23. august 2004 - 15:24 #7
Mht procenter:
Jeg har erfaret at man kan få fornuftige procentværdier hvis man kører med amerikansk locale på klienten. Det er noget med komma og decimalpunkt den kører sur i... (amerikanske programmører...)
Avatar billede dsj Nybegynder
23. august 2004 - 15:43 #8
venne >> Gælder det på den maskine SQL-serveren kører, eller den maskine Query Analyzeren kører på?
Avatar billede venne Nybegynder
24. august 2004 - 08:33 #9
dsj>
Det gælder klientmaskinen, altså der hvor du kører Query Analyzer.
Avatar billede trer Nybegynder
24. august 2004 - 23:51 #10
venne> fint tip, det var jeg ikke faldet over - men som du siger en ganske typisk fejl. En anden tilsvarende lille bug er, at estimated rows i execution plan giver lidt forkerte værdier når du har tabeller med over 200.000.000 rækker - den vil gerne angive det som ekspotiential tal - men snubler så lidt over E'et...
Avatar billede dsj Nybegynder
25. august 2004 - 00:06 #11
Det hjalp mig i øvrigt ikke at skifte til amerikansk locale - jeg oplever stadig execution plans, hvor batchen samlet tager 0,00% ...
Avatar billede trer Nybegynder
25. august 2004 - 13:35 #12
De steder du får 0.00% - hvordan ser "Subtree Cost" ud ned gennem træet?
Avatar billede dsj Nybegynder
15. september 2004 - 10:58 #13
Jeg lukker, da jeg ikke rigtig har fået svar på det ønskede, men tak for jeres kommentarer.
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester