Azure SQL Database är Microsofts databas-som-en-tjänst-erbjudande som erbjuder en enorm mängd flexibilitet och säkerhet och, som en del av Microsofts Platform-as-a-Service, får dra nytta av ytterligare funktioner. Eftersom Azure SQL Database är databasbaserat finns det några stora skillnader när det gäller prestandajustering.
Justera instansen
Många objekt på instansnivå som du har varit van vid att konfigurera på fullständiga installationer är förbjudna. Några av dessa objekt inkluderar:
- Ställa in min och max serverminne
- Aktivera optimering för ad hoc-arbetsbelastningar
- Ändrar kostnadströskeln för parallellitet
- Ändra maxgraden av parallellitet på instansnivå
- Optimera tempdb med flera datafiler
- Spårningsflaggor
Var inte för upprörd över vissa av dessa. ALTER DATABASE SCOPED CONFIGURATION-satsen tillåter en hel del konfigurationsinställningar på individuell databasnivå. Detta introducerades med Azure SQL Database och i SQL Server från och med SQL Server 2016. Några av dessa inställningar inkluderar:
- Rensa procedurcache
- Ställa in MAXDOP på ett annat värde än noll
- Ställ in frågeoptimerarens kardinalitetsuppskattningsmodell
- Aktivera eller inaktivera snabbkorrigeringar för frågeoptimering
- Aktivera eller inaktivera parametersniffning
- Aktivera eller inaktivera identitetscachen
- Aktivera eller inaktivera en kompilerad planstub som ska lagras i cachen när en batch kompileras för första gången.
- Aktivera eller inaktivera insamling av exekveringsstatistik för inbyggt kompilerade T-SQL-moduler.
- Aktivera eller inaktivera online som standardalternativ för DDL-satser som stöder syntaxen ONLINE=ON/OFF.
- Aktivera eller inaktivera resumable som standardalternativ för DDL-satser som stöder syntaxen RESUMABLE=ON/OFF.
- Aktivera eller inaktivera auto-drop-funktionen för globala temporära tabeller
Som du kan se från listan över omfångade konfigurationer har du mycket kontroll och precision för att finjustera specifika beteenden för enskilda databaser. För vissa kunder kan begränsningarna för kontroll på instansnivå ha negativ inverkan, medan andra kommer att se det som en fördel.
För företag som har en databas per kund, som behöver fullständig isolering, som är inbyggd i Azure SQL Database. För de som behöver funktionerna på instansnivå i SQL Server men som vill dra fördel av Microsofts PaaS-erbjudande finns Azure SQL Managed Instance, som är instansomfattad. Målet där är att ha 100 % ytarea kompatibilitet med SQL Server; så du kan ställa in min och max serverminne, aktivera optimering för adhoc-arbetsbelastningar och ändra både MAXDOP och kostnadströskel för parallellitet. Tempdb på en hanterad instans har redan flera filer, men du kan lägga till fler och öka standardstorleken. På många sätt känns det verkligen som en fullständig installation av SQL Server.
Frågejustering
En annan skillnad mellan Azure SQL Database och SQL Server är att Query Store är aktiverat som standard i Azure SQL Database. Du kan stänga av Query Store, men sedan begränsar du de Intelligent Performance-verktyg i Azure Portal som använder den. Query Store är en funktion som ger insikt i frågeprestanda och planval. Query Store fångar också en historik över frågor, planer och körtidsstatistik så att du kan granska vad som händer. Vill du veta vilken fråga som har högst omkompileringstid, körningstid, antal körningar, CPU-användning, minnesanvändning, flest fysiska läsningar/skrivningar och mer? Query Store har den informationen. För SQL Server måste du aktivera den här funktionen per databas. Om du är ny på Query Store har min kollega Erin Stellato en tretimmarskurs om Pluralsight som hjälper dig att komma igång.
Kategorien Intelligenta prestandaverktyg har fyra funktioner. För det första ger prestandaöversikten en sammanfattning av din totala databasprestanda genom att lista de fem bästa frågorna efter CPU-förbrukning, eventuella rekommendationer från automatisk justering, justering av aktivitet och aktuella inställningar för automatisk justering. Den här målsidan ger dig en snabb inblick i ditt resultat.
För det andra kommer alternativet för prestandarekommendationer att lista alla aktuella rekommendationer för att skapa index eller om några index ska tas bort. Om några senaste åtgärder har slutförts ser du också historiken.
För det tredje är Query Performance Insight där du kan hitta en djupare insikt i din resursförbrukning genom att se de 5 bästa frågorna efter CPU, Data I/O eller Log I/O. De fem bästa frågorna är färgkodade så att du snabbt kan se procentandelen av den totala förbrukningen visuellt. Du kan klicka på fråge-id för att få mer information inklusive SQL-texten. Det finns också en flik för långa frågor. Jag gillar verkligen att Microsoft har inkluderat en sådan här funktion i Azure Portal utan kostnad. Det ger värde genom att ge kunderna en portal där de kan se de mest stötande frågorna. Vad jag tycker är utmanande här är att ha ett sätt att se en övergripande baslinje för jämförelse av dag till dag, vecka till vecka och föregående månad. Men för en snabb analys och översikt är Query Performance Insight till hjälp.
Den sista funktionen i denna kategori är automatisk inställning. Det är här du kan konfigurera kraftplanen, skapa index och släppa indexinställningar. Du kan tvinga den på, av eller välja att ärva från servern. Force plan tillåter Azure att välja vad den anser vara det bästa av exekveringsplanerna för regresserade frågor. Den här funktionen finns också i SQL Server 2017 Enterprise Edition som automatisk plankorrigering. Vissa DBA:er blir nervösa när de hör talas om de automatiska inställningsfunktionerna, eftersom de fruktar att det kan ersätta behovet av DBA:er i framtiden. Jag gillar alltid att ställa frågan "Hur mycket tid varje dag lägger du ner på att proaktivt ställa in frågor?". Det överväldigande svaret är att människor faktiskt kan lägga väldigt lite tid på att proaktivt trimma, och de flesta svarar att den enda gången de verkligen "justerar" är efter en kodutgivning eller när användare börjar klaga.
Förutom de inbyggda verktygen och värdet av att använda Query Store, är DMVs också lätt tillgängliga. Glenn Berry har en hel samling skript bara för Azure SQL Database som du kan använda. En speciell DMV jag vill kalla ut är sys.dm_os_wait_stats. Detta kommer att dra från servernivån, så om du verkligen vill titta på väntestatistik för databasnivån, måste du använda sys.dm_db_wait_stats istället.
Hårdvara – Skalning
Ett annat område att tänka på när man tittar på prestanda med Azure SQL Database är den underliggande hårdvaran. Azure SQL Database prissätts av Database Transaction Units (DTUs) och vCores. DTU:er är ett blandat mått på CPU, minne och I/O, och finns i tre nivåer; Basic, Standard och Premium. Basic är endast 5 DTU:er, Standard sträcker sig från 10-3 000 DTU:er och Premium-intervall från 125-4 000 DTU:er. För de vCore-baserade nivåerna har vi General Purpose och Business Critical som sträcker sig från 1-80 vCores.
I DTU-modellen bör Basic övervägas för utveckling och testning. Den har bara en 7-dagars säkerhetskopiering så jag skulle inte anse den som lönsam för någon produktionsdata. Standard är bra för låg, medium och hög CPU-behov med måttlig till låg I/O-behov. Grundnivån och standardnivån erbjuder 2,5 IOPS per DTU med 5 ms (läs), 10 ms (skriv). Premium-nivån är för medelhög till hög CPU-efterfrågan och hög I/O och erbjuder 48 IOPS per DTU med 2ms (läs/skriv). Premium-nivån har lagring som är storleksordningar snabbare än standarden. I vCore-modellen har du Gen4-processorer som erbjuder 7 GB RAM per fysisk kärna och Gen 5-processorer som erbjuder 5,1 GB RAM per logisk kärna. Ur ett I/O-perspektiv erbjuder General Purpose 500 IOPS per vCore med 7 000 max. Business Critical erbjuder 5 000 IOPS per kärna med 200 000 max.
Sammanfattning
Azure SQL Database är bra för de system som behöver databasisolering medan Azure SQL Managed Instance är bra för de miljöer där du behöver kompatibilitet på instansnivå (stöd för korsdatabasfrågor). När du behöver finjustera Azure SQL Database måste du göra saker på databasnivå eftersom alternativ på instansnivå är förbjudna, så databasomfattade konfigurationsinställningar är dina finjusteringsalternativ. Med felsökning av frågor som fungerar dåligt har du några inbyggda verktyg som hjälper dig, inklusive Query Store, och de flesta av dina vanliga inställningsskript kommer att fungera. Du kanske upptäcker att du fortfarande behöver mer, såsom baslinjer, mer historisk data och förmågan att skapa rådgivande villkor för att hjälpa dig hantera dina arbetsbelastningar. Det är här kraftfulla övervakningslösningar som SentryOne DB Sentry kan hjälpa till.
När allt annat misslyckas, eller din arbetsbelastning helt enkelt har ökat förbi dina nuvarande hårdvaruresurser, skala till en högre nivå.