Plan Explorer 3.0-webbseminarium – exempel och frågor och svar

I fredags höll jag ett webbseminarium om Plan Explorer 3.0, de nya funktionerna och varför vi bestämde oss för att ta bort PRO-utgåvan och ge bort alla funktioner gratis . Om du missade det kan du se webbinariet här:

Webinarium för Plan Explorer 3.0

Det kom in många bra frågor och jag ska försöka ta upp dem här. Vi ställde också några av våra egna frågor vid olika tillfällen under presentationen, och användare bad om detaljer om dem, så jag börjar med enkätfrågorna. Vi hade en topp på 502 deltagare, och jag kommer att ange i diagrammen nedan hur många personer som svarade på varje fråga. Eftersom den första frågan ställdes innan webinariet tekniskt sett startade, svarade ett mindre antal personer på den.

Frågor från publiken

F:Finns kodexemplen tillgängliga?

Svar: Ja, de tre sessionsfilerna jag använde för mina demos finns tillgängliga här:

Plan Explorer 3.0 Webinar Demos

Du kan öppna dessa i den senaste versionen av Plan Explorer, men om du vill köra någon av frågorna igen lokalt behöver du AdventureWorks2014 (med det förstorande skriptet från Jonathan Kehayias) och/eller den nya exempeldatabasen Wide World Importers.

Svar: Jag blir alltid förvånad när jag stöter på människor som tror att allt vi erbjuder är Plan Explorer (jag ser dessa personligen, och det fanns flera liknande kommentarer på Gregs blogginlägg också). Vårt riktiga bröd och smör finns i vår övervakningsplattform, och vi hoppas att din positiva erfarenhet av Plan Explorer kommer att leda till att du också testar våra andra lösningar.

Svar: Ja, även om du kommer att gå miste om en del av funktionerna (som Live Query Profile), så finns det mycket mer information tillgänglig för dig jämfört med SSMS, och vi gör allt vi kan för att göra specifika problem mycket mer upptäckbara.

Svar: Ja, så länge Service Pack 1 tillämpas, eftersom funktionen är beroende av en DMV som lades till i SQL Server 2014 SP1.

Svar: Absolut. Begränsningen jag tog upp under webinariet om SQL Server 2012 och lägre är att de inte kan fånga in Live Query Profile-data.

Svar: Ja, Live Query Profile (och resursdiagrammen) fungerar i SQL Server 2014 (med minst SP1), SQL Server 2016 och Azure SQL Database. Den påverkas inte av kompatibilitetsnivån.

Svar: Insamling av väntestatistik bygger på en Extended Event-session, så du måste köra mot SQL Server 2008 eller högre, och köra i sammanhanget för en användare eller inloggning med tillräckliga behörigheter för att skapa och släppa en Extended Event-session (CONTROL SERVER i SQL Server 2008 och 2008 R2 och ALTER ANY EVENT SESSION i SQL Server 2012 och senare).

Svar: Det fanns många variationer på dessa två frågor, och utifrån ljudet av dem lekte folk aktivt med den nya versionen under webbinariet och såg varken indexanalysdata eller Live Query-profildata. Om du har en befintlig plan hämtad från SSMS eller en tidigare version av Plan Explorer, kommer det inte att finnas någon information att visa.

För att samla in Indexanalys data måste du generera en uppskattad eller faktisk plan från Plan Explorer. För att se ett kolumn- och indexrutnät måste du välja en vald operation:i rullgardinsmenyn högst upp på fliken Indexanalys.

För att samla in Live Query Profile data måste du skapa en faktisk plan från Plan Explorer och kör mot 2014 SP1 eller bättre. Du måste också se till att du har valt alternativet "Med Live Query Profile" (se bilden till höger), och vänta på att exekveringen av frågan är klar innan diagrammen renderas. I en framtida version kommer diagrammen att renderas i realtid, men i den här versionen gör vi det efter att all data har samlats in.

Svar: Ja, det här kommer att fungera, men det kommer inte att ge mycket information eftersom en klonad databas är tom – du kommer att se de rätta uppskattningarna i planen, men de faktiska värdena kommer alla att vara 0, och därför kommer körtidsmåtten inte att representera någon realistisk eller meningsfulla flaskhalsar. Såvida du inte fyller klonen med alternativa data, som Erin Stellato främjar i ett tidigare inlägg. Observera också att om du vill att frågeplaner ska återspegla verkliga produktionsdatastorlekar, vill du se till att alla former av autostatistik är avstängda, annars kommer de att uppdateras när du kör frågor, och då blir alla uppskattningar 0.

Svar: Ja. Vi stöder alla nya SQL Server 2016 planoperatörer och andra showplanändringar (se mitt inlägg, "Plan Explorer Support for SQL Server 2016"), och tillägget fungerar även med den senaste versionen av SSMS (se mitt inlägg, "Tillkännager Plan Explorer-tilläggsstöd för SSMS 2016").

Svar: Ja det stämmer. När du samlar in Live Query Profile-data kan vi ändra kostnadsprocenten för alla operatörer, eftersom vi vet med en betydande grad av noggrannhet hur mycket arbete varje operation utförde (förfrågan behöver dock köras längre än ett tröskelvärde). Detta kan vara särskilt användbart om du felsöker ett I/O-problem, eftersom uppskattningarna aldrig verkar ta hänsyn till I/O-flaskhalsar. Följande grafik cirkulerar genom de ursprungliga uppskattningarna (vi kan alltid visa dig vad SSMS skulle ha sagt till dig), de faktiska värdena efter omkostnad och de faktiska värdena efter omkostnad och ändrade kostnader till "genom I/O" och linjebredder till "efter datastorlek":

Svar: Jag tog upp den här frågan i webinariet, men för att vara tydlig tror jag att det finns två steg i utvecklingen av en fråga:(1) säkerställa korrekta resultat och (2) prestandaoptimering. Jag är övertygad om att du för närvarande bör använda SSMS för (1) och Plan Explorer för (2). Jag har länge förespråkat att när folk är säkra på att de har korrekta resultat bör de ställa in genom att generera faktiska exekveringsplaner från Plan Explorer, eftersom vi samlar in mycket mer runtime-information åt dig. Den här körtidsinformationen är särskilt användbar om du delar dina planer på vår Q &A-webbplats, eftersom den gör alla mätvärden och potentiella flaskhalsar mycket mer uppenbara.

Svar: Den procentandelen är inte en kostnad utan snarare procentandelen rader som faktiskt bearbetades jämfört med uppskattningen. I det här fallet uppskattade SQL Server att funktionen skulle returnera 10 000 rader, men vid körning returnerade den nära 300 000! Du kan se ett verktygstips om du bara håller muspekaren över det %-talet, och du kan se skillnaderna i uppskattning av radantal i verktygstipset för operatören, eller i andra rutnät som Top Operations (funktionen returnerar ett annat antal rader nu än den gjorde under demon):

Svar: Ja, alla våra paneler är justerbara; många har en push-pin som växlar mellan statisk och auto-hide, de flesta paneler kan dras runt (precis som i Visual Studio, SSMS, etc.), och speciellt replay-panelen har en liten pil högst upp i mitten som låter dig för att snabbt visa/dölja:

Svar: Jag är inte säker på om jag tolkar frågan rätt, men alla våra paneler är kontextkänsliga, och uttalandet för planen som för närvarande granskas visas både i uttalande-rutnätet och på textdatapanelen:

Om satstexten inte är helt synlig på grund av längden kan du alltid högerklicka på den cellen och välja Kopiera sats till kommandotext Kopiera och sedan växla till den fliken. Eller, om du inte vill skriva över det aktuella innehållet på fliken Kommandotext, välj Kopiera> Cell och klistra in i en ny session, SSMS eller annan redigerare.

Svar: Om en fråga körs för närvarande finns det en stoppknapp i statusfältet, längst ner till vänster:

Svar: Vi har definitivt planer på att göra indexskriptet mer robust i framtiden, inklusive alternativ som DROP_EXISTING och ONLINE.

Svar: All funktionalitet i Plan Explorer är också tillgänglig i SentryOne-klienten. Du behöver tekniskt sett inte installera Plan Explorer om du har klienten, förutom att uppdateringar skickas på ett annat schema, så i många fall kan det vara vettigt att ha båda installerade.

Tänk på att planer som vi samlar in åt dig under övervakningsaktiviteter är uppskattade planer, på grund av den höga kostnaden för att samla in faktiska planer för alla frågor som körs mot en server. Det betyder att om du borrar ner till en insamlad plan i klienten kommer den inte att ha ytterligare information som indexanalys och Live Query Profile-data. Du kan alltid köra frågan igen, interaktivt, för att få ytterligare körtidsdata.

Svar: Det mesta av informationen vi samlar in är inte dyrare än om du körde samma frågor och samlade in samma körtidsdata från Management Studio (t.ex. med SHOWPLAN, STATISTICS TIME och STATISTICS IO på). Mycket av detta kompenseras dock av vårt standardbeteende att kassera resultat, så vi belastar inte servern med ansträngningen att överföra resultat till vår applikation.

För extremt komplexa planer som körs mot databaser med mycket komplexa scheman och MÅNGA index, kan insamlingen av index och statistik vara mindre effektiv, men det är extremt osannolikt att detta kommer att orsaka någon märkbar inverkan på befintliga arbetsbelastningar. Detta kommer inte att påverkas av antalet rader i en tabell, som nämndes i en variant av denna fråga.

För riktigt långvariga eller resurskrävande frågor skulle min största oro vara vår Live Query Profile-samling. Vi har två inställningar som kan hjälpa till med detta:om vi ska inkludera Live Query Profile med all faktisk plangenerering som standard, och vilket intervall för att samla in data från DMV. Även om jag fortfarande anser att overheaden för den här samlingen aldrig borde komma i närheten av överheaden för själva frågan, kan du justera dessa inställningar för att göra samlingen mindre aggressiv.

Som allt sagt, med ansvarsfriskrivningen att allt ska göras med måtta, har jag inte observerat några problem relaterade till kostnaden för att samla in data och skulle inte tveka att använda alla funktioner mot en produktionsinstans.

Svar: För närvarande har vi ingen funktion som rekommenderar filtrerade index, men det finns definitivt på vår radar.

Svar: Ja, detta har verkligen funnits på vår färdplan sedan långt innan denna funktionalitet introducerades i SSMS. :-) Vi kommer att ta oss tid och bygga ut en uppsättning funktioner som du förhoppningsvis har kommit att förvänta dig av oss.

Svar: Jag antar att du skulle kunna, om du anropar paketet eller jobbet via T-SQL mot en server (Plan Explorer har inte möjlighet att starta saker som SSIS-paket direkt). Men applikationen visar bara de prestandaaspekter som görs synliga genom SQL Server – om det finns ineffektivitet i SSIS-paketet som inte är relaterade till exekvering mot SQL Server (säg, en oändlig loop i en skriptuppgift) är vi kommer inte att kunna plocka upp dem, eftersom vi inte har någon synlighet och inte utför någon kodanalys.

Svar: Jag missade den här frågan under webinariet, men jag pratar om den här funktionen i mitt Demo Kit, Jonathan Kehayias har bloggat om det här, Steve Wright har en video om det på YouTube, och den officiella dokumentationen kan granskas i PE User Guide.

Svar: Plan Explorer är utformad för att hjälpa till att analysera individuella frågor och deras genomförandeplaner. Vi har en fullt utrustad övervakningsplattform för större insatser, och det finns flera verktyg för analys av arbetsbelastning från tredje part där ute också.

Svar: Det finns många resurser för att bli bättre på att ställa in frågor:

• Alla T-SQL-böcker av Itzik Ben-Gan, Grant Fritchey eller Benjamin Nevarez;
• Alla blogginlägg av Paul White eller Rob Farley;
• Frågor och svar här på answers.sqlperformance.com eller över på dba.stackexchange.com;
• Frågejustering av videor på YouTube;
• Demo Kit (med en ny version kommer snart!); och,
• Öva . Allvarligt. Du kan läsa alla böcker och artiklar du vill, men utan praktisk, praktisk felsökning och förbättra problematiska frågor med verkliga prestandaproblem, kommer det att bli svårt att bli expert. IMHO.

Sammanfattning

Tack för att du deltog i webbinariet och tack så mycket för alla bra frågor. Jag är ledsen att jag inte kunde ta upp dem alla, men jag hoppas att detta var till hjälp ändå. Om du hade en fråga som jag inte tog upp ovan får du gärna fråga mig direkt på [email protected].