Anbefalede databasekonfigurationer

Før du kan tune forespørgsler eller fejlfinde samtidighed, har du brug for den rette infrastruktur under. Azure SQL Database giver dig to ressourcemodeller og flere serviceniveauer. Den kombination, du vælger, sætter loftet for compute, hukommelse, I/O og lagring for din arbejdsbyrde. Vælger du for lidt, lider præstationen. Vælger du for meget, spilder du budgettet.

Sammenlign ressourcemodeller

Azure SQL Database understøtter to ressourcemodeller: vCore og DTU. De måler og fakturerer ressourcer forskelligt, så at forstå forskellen hjælper dig med at træffe det rigtige valg fra starten.

vCore-modellen giver dig direkte kontrol over virtuelle kerner, hukommelse og lager. Du vælger hardware-generering, service-niveau og compute-niveau uafhængigt. Hvis du migrerer fra en lokal SQL Server, kortlægges denne model rent til fysisk CPU og hukommelse, hvilket gør kapacitetsplanlægning mere ligetil. Den understøtter også prisfastsættelse af reserverede instanser og Azure Hybrid Benefit for omkostningsbesparelser.

DTU-modellen samler CPU, hukommelse og I/O i én enhed kaldet en Database Transaction Unit (DTU). DTU-baserede niveauer (Basic, Standard og Premium) tilbyder forudkonfigurerede ressourcepakker. Denne model fungerer, når du ikke behøver fintgået kontrol over individuelle ressourcedimensioner.

For de fleste nye implementeringer anbefaler Microsoft vCore-modellen. Det giver højere ressourcebegrænsninger, større skaleringsgranularitet og større prisfleksibilitet.

Forstå serviceniveauer i vCore-modellen

vCore-modellen har tre serviceniveauer: General Purpose, Business Critical og Hyperscale. Hvert lag bruger en forskellig arkitektur, hvilket påvirker lagertype, I/O-ydelse og tilgængelighed.

General Purpose adskiller beregning og lagring. Databasemotoren kører på en compute-node, mens datafilerne ligger på Azure Blob Storage. Lagringslatensen er typisk mellem 5 og 10 millisekunder. Denne arkitektur giver budgetvenlige priser og fungerer godt til de fleste forretningsarbejdsbelastninger. Hvis compute-noden fejler, flytter Azure Service Fabric processen til en reservenode og gentilknytter de fjern-lagringsfiler.

Overvej e-handelsapplikationen fra introduktionen. I normale åbningstider håndterer General Purpose ordremængden uden problemer. Men under et flash-salg i ferien er I/O-latenstid på 5 millisekunder til 10 millisekunder måske ikke hurtigt nok til at få udbetalingen.

Business Critical integrerer beregning og lagring på hver node. Databasemotoren og datafilerne bruger begge lokalt tilsluttede SSD'er i en Always On tilgængelighedsgruppe med tre sekundære replikaer. Dette design giver dig den laveste I/O-latens (1 millisekund til 2 millisekunder i gennemsnit), den højeste IOPS (input/output-operationer per sekund) og en gratis read-only-replika, du kan bruge til rapportering af forespørgsler. Ulempen er prisen, cirka 2,7 gange mere end General Purpose for samme vCore-antal. For e-handelsteamet giver Business Critical mening, hvis deres betalingstransaktioner kræver konstant latenstid på under 2 millisekunder.

Hyperscale bruger en afkoblet lagringsarkitektur med uafhængige sideservere og en cache-lagring med flere lag. Den understøtter databaser op til 128 TB, tillader nul til fire højtilgængelighedsreplikaer og skalerer beregningen op eller ned uden at kopiere data. Du bliver kun faktureret for tildelt lagerplads, ikke maksimal lagerplads. Hyperscale fjerner de praktiske begrænsninger for lagring og skalering af de andre niveauer og er velegnet til det bredeste udvalg af arbejdsbelastninger.

Følgende tabel opsummerer de vigtigste forskelle:

Vælg et beregningsniveau

Inden for vCore-modellen vælger du også mellem to compute-niveauer: provisioned og serverless.

Provisioneret beregning tildeler et fast antal vCores, som forbliver tilgængelige uanset arbejdsbelastningens aktivitet. Du betaler en fast timeløn. Dette niveau tilpasser arbejdsbelastninger med et stabilt eller forudsigeligt ressourceforbrug, som e-handelsapplikationen, der behandler ordrer i løbet af dagen.

Serverløs beregning skalerer automatisk vCores baseret på efterspørgsel og regninger pr. sekund for den anvendte beregning. Når databasen er inaktiv, kan den autopause og helt eliminere beregningsomkostninger, selvom autopause i øjeblikket kun understøttes i General Purpose. Serverless compute er tilgængelig både til General Purpose- og Hyperscale-niveauer. Det fungerer godt til udviklingsmiljøer, interne værktøjer eller applikationer med ujævn trafik.

Match konfigurationen til din arbejdsbyrde

Nu hvor du forstår mulighederne, hvordan beslutter du så? Vurder din arbejdsbyrde ud fra disse faktorer:

• Latenstid: Hvis din applikation konsekvent kræver I/O-latenstid under 2 millisekunder, vælg Business Critical. For moderat latenstid er General Purpose tilstrækkeligt.
• Lagerstørrelse: Hvis din database overstiger 4 TB, eller du forventer hurtig vækst, er Hyperscale den eneste mulighed, der kan rumme op til 128 TB.
• Læseintensive arbejdsbyrder: Business Critical inkluderer en gratis skrivebeskyttet replika. Hyperscale understøtter navngivne replikaer til fleksibel læse-skalering.
• Omkostningsfølsomhed: Generel anvendelse med provisioneret beregning tilbyder forudsigelige priser. Serverløs beregning i General Purpose eller Hyperscale reducerer omkostningerne for intermitterende arbejdsbelastninger.
• Tilgængelighedskrav: Business Critical leverer den højeste robusthed med tre synkrone replikaer og den hurtigste failover. Hyperscale lader dig konfigurere antallet af replikaer for at balancere robusthed og omkostninger.

Konfigurer database-niveau indstillinger

Du valgte dit niveau og din compute-model. Se nu inde i selve databasen. Flere indstillinger påvirker, hvordan Azure SQL Database håndterer parallelisme, forespørgselsoptimering og gendannelse. Du justerer disse indstillinger uden at ændre dit serviceniveau.

Styr parallelisme med MAXDOP

Maksimal grad af parallelisme (MAXDOP) styrer, hvor mange processortråde motoren tildeler til en enkelt forespørgsel. Azure SQL Database er standard 8, hvilket fungerer for det bredeste udvalg af arbejdsbelastninger. Før september 2020 gik nye databaser som standard til 0, ubegrænset parallelisme, og det skabte problemer. En enkelt analytisk forespørgsel kunne forbruge alle tilgængelige tråde og sulte CPU'ens udbetalingsflow.

Du sætter MAXDOP på database-niveau med ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP. Du kan også sætte en anden værdi for sekundære replikager, når dine read-write og read-only workloads har forskellige samtidighedsbehov. For en specifik forespørgsel, brug hintet OPTION (MAXDOP) . Den ene regel: undgå MAXDOP 0 i produktion. Ubegrænset parallelisme fører til ressourceudtømning, forespørgselstidsafbrydelser og applikationsafbrydelser.

Lad automatisk tuning fange regressioner

Forespørgselsoptimeringen vælger ikke altid den bedste plan. Statistikker bliver forældede, datafordelinger skifter, og en plan, der var hurtig i går, bliver langsom i dag. Automatisk tuning overvåger forespørgselspræstationen og anvender korrektioner uden at vente på, at du opdager det.

Azure SQL Database understøtter tre muligheder:

• FORCE_LAST_GOOD_PLAN opdager planregressioner og tvinger den tidligere hurtige plan. Aktiveret som standard.
• CREATE_INDEX identificerer manglende indekser, opretter dem og verificerer forbedringen. Deaktiveret som standard.
• DROP_INDEX fjerner ubrugte og duplikerede indekser. Deaktiveret som standard. Unikke indekser, herunder indekser der understøtter primærnøgle og unikke begrænsninger, bliver aldrig droppet.

Hver ændring gennemgår et valideringsvindue, 30 minutter til 72 timer afhængigt af forespørgselsfrekvensen. Hvis ydelsen bliver dårligere, bliver ændringen automatisk tilbageført.

ALTER DATABASE CURRENT
SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN = ON,
                      CREATE_INDEX = ON,
                      DROP_INDEX = OFF);

Tænk på e-handelsapplikationen under et juleudsalg. Forespørgselsmønstre ændrer sig, efterhånden som forskellige produktsider bliver mere populære. FORCE_LAST_GOOD_PLAN fanger automatisk disse regressioner, så en dårlig planændring kl. 2 om natten forsinker ikke kassen, før nogen opdager det mandag morgen. Du vil sandsynligvis gerne lade CREATE_INDEX og DROP_INDEX fri, indtil det, de foreslår, er gennemgået.

Lås op for optimeringsfunktioner med kompatibilitetsniveau

Hver database har et kompatibilitetsniveau , der bestemmer, hvilke forespørgselsoptimeringsadfærd der er tilgængelige. Nye databaser i Azure SQL Database starter som standard på niveau 170, eller det højeste tilgængelige niveau. Hvert niveau låser op for et sæt intelligente forespørgselsbehandlingsfunktioner (IQP):

• Niveau 150: batch-tilstand på rowstore, tabelvariabel udskudt kompilering, skalar brugerdefineret funktion (UDF) inlining.
• Niveau 160: parametersensitiv planoptimering (PSP), kardinalitetsestimeringsfeedback.
• Niveau 170: valgfri optimering af parameterplanen.

Eksisterende databaser kan køre på et lavere kompatibilitetsniveau, fordi Microsoft aldrig automatisk opgraderer denne indstilling. En database, der blev oprettet, da en lavere standard var gældende, beholder sit oprindelige niveau. For eksempel, hvis du oprettede en Azure SQL-database i 2024, er databasen stadig på niveau 160, hvis niveauet ikke opdateres manuelt. På samme måde, hvis du importerede en database via en BACPAC-fil, er den importerede databases kompatibilitetsniveau baseret på kildedatabasens kompatibilitetsniveau. For at rykke op:

ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 170;

Skift ikke denne indstilling blindt under produktionen. Brug Query Store til at indfange en performance-baseline på det aktuelle niveau, opgrader i et testmiljø og sammenlign. Hvis en forespørgsel går tilbage, kan du tvinge den gamle plan, mens du undersøger.

Reducer oppustethed i plancachen med OPTIMIZE_FOR_AD_HOC_WORKLOADS

E-handelsapplikationen genererer produktsøgninger med dusinvis af filterkombinationer. Hver unik forespørgselstekst får sin egen kompilerede plan i cachen, selvom forespørgslen aldrig kører igen. Med tiden fyldes planlageret med tusindvis af engangsplaner, hvilket forskubber de ofte udførte planer, der virkelig betyder noget.

OPTIMIZE_FOR_AD_HOC_WORKLOADS løser dette problem. Når den er aktiveret, gemmer motoren en lille kompileret plan-stub ved første udførelse i stedet for hele planen. Først når den samme forespørgsel kører en anden gang, kompilerer og cacher motoren hele planen.

ALTER DATABASE SCOPED CONFIGURATION
SET OPTIMIZE_FOR_AD_HOC_WORKLOADS = ON;

Denne indstilling holder cachen slank og sikrer, at planerne for dine vigtigste forespørgsler forbliver i hukommelsen.

Forstå accelereret databasegendannelse

Accelereret databasegendannelse er altid aktiveret i Azure SQL Database. Du kan ikke slukke den, og det behøver du heller ikke. Accelereret databasegendannelse (ADR) redesigner gendannelsesprocessen, så gendannelsestiden forbliver konstant uanset hvor mange aktive transaktioner der kørte, da en fejl opstod. Den giver også øjeblikkelig tilbagerulning af transaktioner og aggressiv logtrunkering.

ADR gemmer rækkeversioner i et persistent versionslager (PVS) inde i databasen i stedet for i tempdb. Afhængigt af størrelsen på den række, der ændres, gemmes versioner enten i rækken på datasider eller uden for rækken i en separat intern tabel. Skriveintensive arbejdsbelastninger kan opleve øgede sideopdelinger og højere loggenerering, fordi hver rækkeversion logges. For at minimere denne overhead, hold transaktioner korte og reducer unødvendige afbrudte transaktioner.

PVS'en deler din databases allokerede lagerplads, så en voksende PVS reducerer pladsen til dine data. For at overvåge off-row PVS overhead, foresøg sys.dm_tran_persistent_version_store_stats og tjek kolonnen persistent_version_store_size_kb , som kun rapporterer størrelsen på off-row versioner og ikke inkluderer in-row versioner gemt på datasider. For at etablere en baseline under typiske arbejdsbelastninger, sammenlign den værdi med din samlede databasestørrelse. Hvis PVS vokser markant ud over dette udgangspunkt, skal man kigge efter langvarige transaktioner eller høje abortrater, der forsinker versionsoprydning.

Vigtige takeaways

Azure SQL Database giver dig to ressourcemodeller, tre serviceniveauer og to compute-niveauer. vCore-modellen med General Purpose dækker de fleste arbejdsbelastninger. Business Critical tilføjer latenstid på under 2 millisekunder. Hyperscale fjerner begrænsninger for lagring og skalering. Inde i databasen er MAXDOP 8 den sikre standard, automatisk justering fanger planregressioner, og opgradering af dit kompatibilitetsniveau låser op for de nyeste intelligente forespørgselsbehandling (IQP) funktioner. Aktiver OPTIMIZE_FOR_AD_HOC_WORKLOADS for at holde plancachen ren, og overvåg PVS-lagerforbruget fra ADR-brug sys.dm_tran_persistent_version_store_stats, især i skriveintensive scenarier. Dernæst udforsker du, hvordan isolationsniveauer og samtidighedskontrol påvirker forespørgslerne, der kører inde i denne infrastruktur.