Tänk om du gjorde allt besväret med att implementera eller uppgradera till en ny SQL Server för en bättre upplevelse för dina kunder – och de klagade på att saker och ting faktiskt var värre?
Skulle du inte bli orolig om du hoppade igenom alla dessa affärsmässiga och tekniska ramar för att få bättre SQL Server-prestanda, och sedan inte gjorde det?
Du kanske borde ha genomfört några SQL Server-prestandatester innan du gick i produktion. Då hade du vetat om din prestation skulle förbättras, förbli densamma eller, värst av allt, minska.
Men du skulle åtminstone inte ha blivit obehagligt överraskad.
SQL Server-prestandabryggan passerar vi alla
Oavsett om det handlar om att byta från någon annan databas till SQL Server eller uppgradera från en äldre version av SQL Server till en nyare, var du tvungen att gå över prestandabryggan så småningom.
"Kommer det verkligen att gå bättre än tidigare?" frågade din chef.
"Åh, visst," sa du. "Med datavirtualisering i SQL Server 2019 kan vi köra frågor utan att flytta eller replikera data. Och det finns automatisk justering med Intelligence Query Processing för att skala upp frågor. Data kommer att FLYA ut från servrar." Du var så säker att du skrev "FLYG".
Så hur kunde du ha testat din prestation bättre?
4 sätt att testa prestanda . . .
Brent Ozar, SQL Server maven extraordinaire, berättar hur du kontrollerar prestanda på en ny SQL Server:
- det enkla sättet, att jämföra före- och eftertider på en fullständig säkerhetskopiering och CHECKDB
- det enkla men fel sättet, med en syntetisk arbetsbelastning och TPC-C i HammerDB
- det svårare sättet, att testa individuella frågor med sp_BlitzCache, hans plancacheanalysskript
- den riktigt svåra vägen, kör samma frågor som du kör i produktionen
Men som Brent klargör är att övervaka din SQL-serverprestanda och upptäcka att den har sjunkit med X procent bara början; du måste fortfarande ta reda på var träffen kommer ifrån.
Det innebär att leta efter trender i resultatdata över hela veckor och månader, inte bara under de senaste timmarna.
Ju fler datapunkter och historik du har, desto bättre bild kan du få av vad som händer inuti, under och runt din SQL Server-miljö.
Och ju mer beräkning du kan kasta på all den data, desto snabbare kan du analysera den.
SQL Server prestandaövervakning:Låter som ett jobb för molnet
Japp. Det är ett jobb för molnet, det enda stället du kan skala ut tillräckligt långt för att samla in och analysera all denna data för en bred, djup bild av hur SQL Server förbrukar resurser. Och hur det har förbrukat dessa resurser över tid. Till exempel:
- Vid vissa tider på dagen eller månaden måste ofta körda frågor läsas från disken istället för från buffertcachen, som är kopian i minnet av nyligen använda databassidor. Behöver du allokera mer minne till din buffertcache? Kan du spara mer minne för det?
- Samma för sidans förväntade livslängd. Om det är lågt beror det troligen på att SQL Server avhyser sidor från buffertcachen för ofta och måste köra uppslagningar från lagring istället för från minne. Det hämmar prestandan.
- Blir den maximala I/O-väntetiden för lång? Hur är det trendigt? Det är en antydan om att I/O-enheten kan vara mättad.
- Hur lång är processorkön nu? Hur länge brukar det vara? För många trådar som ständigt väntar kan indikera processorstockning.
- Körs processorn mot de gränser som din server kan hantera? Vad händer om du inte kan skala upp servern längre? Om du är säker på att dina frågor är välinställda och att dina andra systemresurser är tillräckliga kan du behöva lägga till ett uttag för fysisk hårdvara eller vCPU:er till dina virtuella datorer.
- Fragmenterade index är långsamma index, men du vet inte att de är boven förrän du kontrollerar fragmenteringsnivåer. Att se effekterna av omorganisering och ombyggnad över tid kan hjälpa dig att införa en tillförlitlig indexunderhållsprocess.
Att hitta problem som de i alla dina lokala och molndatabaser blir enklare och snabbare när du kan övervaka din SQL-serverprestanda från molnet. Det bästa av allt är att du kan övervaka var som helst i den kända galaxen när all beräkning, lagring och analys finns i molnet och du bara är några klick bort i vilken webbläsare som helst.
Börja testa din SQL Server-prestanda i molnet
På Quest behöver ingen säga till oss två gånger att våra kunder vill ha molnbaserade verktyg, vare sig det gäller molnmigrering, prestandaövervakning eller Office 365. Vi gör fler av våra produkter tillgängliga som molnerbjudanden eftersom teknologier och marknader drar dem dit.
Så, hur kör du prestandatester på dina nya eller uppgraderade SQL-servrar?
- Jag kör CHECKDB.
- Jag kör HammerDB.
- Jag kör Brent Ozars verktyg.
- Jag testar med produktionsbelastningar.
- Jag slår tärningen och väntar tills användarna klagar.
- Jag har folk som gör det åt mig.
- Jag använder Spotlight Cloud från Quest. Det borde du också.