Frågeprofilering är hur du tar reda på vad som händer i den svarta lådan med SQL Server-prestanda.
Användare har det lätt. DBA:er gör det inte.
Tänk på de enkla alternativen användare har när en databasapplikation körs dåligt:
- Gå och hämta kaffe och vänta.
- Förolämpa datorn.
- Klaga till andra användare.
- Skicka in ett felmeddelande.
Är inte det Rileys liv jämfört med alternativen du har som DBA?
- Leta efter blockerade sessioner.
- Kontrollera träffförhållanden för buffertcache.
- Mät maximal I/O-vänta.
- Undersök sidans förväntade livslängd.
- Se om index saknas eller behöver byggas om.
- Leta efter lås/blockerat lås.
- Kontrollera CPU-användning.
- Granska programloggen för meddelanden som är slut på minnet.
- Se till att tempdb-databasen är korrekt konfigurerad.
Det kan vara något av dessa programvaruproblem, och de leder dig vanligtvis till lösningen att optimera en fråga eller ändra din konfiguration. Eller så kan det vara ett hårdvaruproblem och lösningen är att köpa mer minne eller processorkraft.
Eftersom databasapplikationer mest handlar om att köra många SQL-frågor, har prestandaproblem många ställen att gömma sig i SQL Server. Om du är en användare kan du säga, "Åh, ja, problemet måste vara inuti den svarta lådan någonstans. Inte mitt jobb.”
Men som DBA har du inte den lyxen. Du måste öppna den svarta lådan, klättra in, hitta röran och fixa den.
Frågeprofilering 101 med övervakning av SQL-serverprestanda
Generellt sett är ditt mål med övervakning av serverprestanda att hålla ett öga på hur dina SQL-frågor presterar över tid och över ökningen av transaktionsvolymen på din SQL Server. Du kan uppnå det målet på flera sätt.
Ta en titt på förklaringsplanen
Förklaringsplanen visar vad SQL Server kommer att göra för att köra frågan, inklusive tabellerna den kommer att ansluta sig till, vilken typ av koppling den kommer att utföra, antalet rader den kommer att röra och indexen den kommer att använda.
Vad kan förklara planen säga dig? För det första kan du se hur du kan förbättra själva frågan genom att till exempel ta bort en NESTED LOOP JOIN som en av databasutvecklarna lade till mot en enorm tabell. Eller så kan du räkna ut från förklaringsplanen att du behöver skapa eller bygga om ett index för en viss tabell.
Förklaringsplanen är en bra utgångspunkt för frågeprofilering, även innan du faktiskt utför de misstänkta frågorna.
Kör frågan
För att köra frågorna och se vilka resurser de påverkar vid körning skapar du först spår för att markera händelser när de inträffar. Med spår kan du fånga data och se efter att fel uppstår. Ett profileringsverktyg lagrar data som spåren har fångat och visar det på ett sätt som gör det lättare för dig att hitta och felsöka problematiska frågor.
Kombinationen av spåren och profileringsverktyget kan svara på många frågor:
- Vilka frågor förbrukar mest minne?
- Hur lång tid tar varje fråga att köra?
- Vilka lås ställer SQL Server in för varje fråga?
- Vilka frågor kan SQL Server köra från buffertcachen? Hur ofta behöver den gå till disken?
- Hur många rader undersöker varje fråga?
- Hur många förfrågningar per minut uppfyller databasen?
Du får den mest exakta läsningen genom att köra frågan på dina produktionsdatabaser, men det kan också sakta ner bearbetningen av dina verkliga kunder och användare. Om du kan, testa först på utvecklings- eller testinstanser där du inte konkurrerar om minne eller I/O med din produktionsinstans.
På tal om kunder och användare, ditt mål med frågeprofilering är att göra dem nöjda. Profilering kan enkelt avslöja dussintals problem i din databas, men anledningen till att du har öppnat den svarta lådan är för att lösa de mest smärtsamma problemen. Efter att ha samlat in data från en dag eller två med normal användning, kan du hitta de SQL-serverprestandaproblem som ger dina användare mest problem. Kanske saktar ett saknat index ner posthämtningen, eller för många index saktar ner postinförandet och databasuppdateringar. Kanske samlar en ofta använd fråga in information som ingen längre bryr sig om.
Använd profileringsverktyg på ett klokt sätt
Profileringsverktyg räddar dig från den tråkiga processen att manuellt ställa in varje händelse, filter och procedur kräver allt du vill spåra. Med så mycket som händer i den svarta lådan av SQL Server-prestanda kan du enkelt fånga för mycket data för att se skogen för träden.
Bra verktyg gör att du noggrant kan välja vad du spårar så att du till exempel inte fångar hundratals Lock:Acquired-händelser och i onödan fyller din display med dem. Men om du behöver undersöka en ofta förekommande händelse, använd filter som applikationsnamn eller tabellnamn.
Istället för att skriva spårningsdata till en tabell i en databas, överväg att spara den i en egen separat fil. Det förhindrar att överheaden av spåret blir en börda på SQL Server och potentiellt snedvrida resultaten. Om ditt profileringsverktyg föredrar data hämtade från en tabell kan du importera data från filen till tabellen senare.
Förbättra din SQL Server-prestandaövervakning med frågeprofilering
Dina användare håller sig borta från den svarta lådan med SQL Server-prestanda, men du behöver inte. Frågeprofilering är hur du öppnar lådan, tar reda på vad som händer inuti och börjar felsöka.
Men vänta inte tills du har problem med att använda den. Frågeprofilering är mer som att kontrollera oljan än att byta ut motorn. Det hjälper till med de vanliga DBA-uppgifterna att uppdatera föråldrade frågor och ändra design så att dina databaser håller jämna steg med förändringar i verksamheten.