Checklista: Metodtips för SQL Server virtuella Azure-datorer

GÄLLER FÖR: SQL Server på virtuella Azure-datorer

Den här artikeln innehåller en snabb checklista som en serie metodtips och riktlinjer för att optimera prestanda för dina SQL Server på Azure Virtual Machines (VM).

Mer information finns i de andra artiklarna i den här serien: Checklista, VM-storlek, Storage, säkerhet, HADR-konfiguration,samla in baslinje.

Aktivera SQL Assessment för SQL Server på virtuella Azure-datorer så utvärderas SQL Server mot kända metodtips och resultat som visas på sidan för hantering av virtuella SQL-datorer i Azure Portal.

Översikt

När du SQL Server på Azure Virtual Machines kan du fortsätta att använda samma justeringsalternativ för databasprestanda som gäller för SQL Server i lokala servermiljöer. Prestanda för en relationsdatabas i ett offentligt moln beror dock på många faktorer, till exempel storleken på en virtuell dator och konfigurationen av datadiskarna.

Det finns vanligtvis en avvägning mellan kostnadsoptimering och prestandaoptimering. Den här serien med metodtips för prestanda fokuserar på att få bästa prestanda för SQL Server på Azure Virtual Machines. Om din arbetsbelastning är mindre krävande kanske du inte behöver alla rekommenderade optimeringar. Överväg dina prestandabehov, kostnader och arbetsbelastningsmönster när du utvärderar dessa rekommendationer.

Storlek på virtuell dator

Följande är en snabb checklista med metodtips för VM-storlek för att köra SQL Server på virtuella Azure-datorer:

• Använd VM-storlekar med 4 eller fler virtuella processor, till exempel Standard_M8-4ms, E4ds_v4, eller DS12_v2 eller högre.
• Använd minnesoptimerade storlekar på virtuella datorer för att få bästa möjliga prestanda för SQL Server-arbetsbelastningar.
• DSv2 11-15-, Edsv4-serien, M-och Mv2-serien erbjuder det optimala förhållandet mellan minne och virtuella kärnor som krävs för OLTP-arbetsbelastningar. Båda de virtuella datorerna i M-serien erbjuder det högsta förhållandet mellan minne och vCore som krävs för verksamhetskritiska arbetsbelastningar och är också idealiska för arbetsbelastningar i informationslager.
• Överväg ett högre förhållande mellan minne och vCore för verksamhetskritiska arbetsbelastningar och informationslagerarbetsbelastningar.
• Använd Marketplace-avbildningar för virtuella Azure-datorer när SQL Server och lagringsalternativen är konfigurerade för optimala SQL Server prestanda.
• Samla in målarbetsbelastningens prestandaegenskaper och använd dem för att fastställa lämplig VM-storlek för ditt företag.
• Använd verktyget Data Migration Assistant SKU recommendation för att hitta rätt VM-storlek för din befintliga SQL Server arbetsbelastning.

Mer information finns i metodtipsen för VM-storlek.

Storage

Följande är en snabb checklista över metodtips för lagringskonfiguration för att köra SQL Server på virtuella Azure-datorer:

• Övervaka programmet och fastställa krav på lagringsbandbredd och svarstid för SQL Server, logg- och tempdb-filer innan du väljer disktyp.
• Optimera lagringsprestanda genom att planera för högsta tillgängliga okorkopplade IOPS och använda cachelagring av data som en prestandafunktion för dataläsning samtidigt som du undviker virtuella datorer och diskar med begränsningar/begränsningar.
• Placera data, loggfiler och tempdb-filer på separata enheter.
  • För dataenheten använder du endast Premium P30- och P40-diskar för att säkerställa tillgängligheten för cachestöd
  • För loggenhetsplanen för kapacitet och testprestanda jämfört med kostnad vid utvärdering av Premium P30–P80-diskarna.
    • Om svarstiden för under millisekunder krävs använder du Azure Ultra-diskar för transaktionsloggen.
    • För distributioner av virtuella datorer i M-serien bör du Skrivningsaccelerator över med azure ultradiskar.
  • Placera tempdb på den lokala tillfälliga SSD-enheten (standard) för de D:\ flesta SQL Server arbetsbelastningar när du har valt den optimala VM-storleken.
    • Om kapaciteten för den lokala enheten inte är tillräcklig för tempdb bör du överväga att ändra storlek på den virtuella datorn. Mer information finns i Cachelagringsprinciper för datafiler.
• Stripe multiple Azure data disks using Lagringsutrymmen to increase I/O bandwidth up to the target virtual machine's IOPS and throughput limits .
• Ange värdcachelagring till skrivskyddade för datafildiskar.
• Ange värdcachelagring till ingen för loggfilsdiskar.
  • Aktivera inte cachelagring av läsning/skrivning på diskar som innehåller SQL Server filer.
  • Stoppa alltid SQL Server innan du ändrar diskens cacheinställningar.
• Överväg att använda standardlagring för utvecklings- och testarbetsbelastningar. Vi rekommenderar inte att du använder Standard HDD/SDD för produktionsarbetsbelastningar.
• Kreditbaserad disk bursting (P1-P20) bör endast övervägas för mindre dev/test-arbetsbelastningar och avdelningssystem.
• Etablera lagringskontot i samma region som den virtuella SQL Server datorn.
• Inaktivera geo-redundant lagring i Azure (geo-replikering) och använd LRS (lokal redundant lagring) på lagringskontot.
• Formatera datadisken så att den använder allokeringsenhetsstorleken 64 KB för alla datafiler som placeras på en annan enhet än den tillfälliga enheten (som har standardvärdet D:\ 4 KB). SQL Server virtuella datorer som distribueras via Azure Marketplace med datadiskar formaterade med allokeringsenhetsstorlek och överlagring för lagringspoolen inställda på 64 kB.

Mer information finns i de omfattande Storage bästa metoderna.

SQL Server funktioner

Följande är en snabb checklista med metodtips för att SQL Server konfigurationsinställningar när du kör dina SQL Server-instanser på en virtuell Azure-dator i produktion:

• Aktivera komprimering av databassidan där det är lämpligt.
• Aktivera komprimering av säkerhetskopior.
• Aktivera omedelbar fil initialisering för datafiler.
• Begränsa databasens automatiska storlek.
• Inaktivera automatisk storleksrink av databasen.
• Inaktivera automatisk omslutning av databasen.
• Flytta alla databaser till datadiskar, inklusive systemdatabaser.
• Flytta SQL Server-fellogg och spårningsfilkataloger till datadiskar.
• Konfigurera standardplatser för säkerhetskopiering och databasfiler.
• Ange högsta SQL Server minnesgräns för att lämna tillräckligt med minne för operativsystemet. (Utnyttja Minne\Tillgängliga byte för att övervaka operativsystemets minneshälsa).
• Aktivera lås sidor i minnet.
• Aktivera optimering för adhoc-arbetsbelastningar för OLTP-tunga miljöer.
• Utvärdera och tillämpa de senaste kumulativa uppdateringarna för de installerade versionerna av SQL Server.
• Aktivera Query Store på alla produktionsdatabaser SQL Server enligt bästa praxis.
• Aktivera automatisk justering för verksamhetskritiska programdatabaser.
• Se till att alla tempdb-metodtips följs.
• Placera tempdb på den tillfälliga D:/ Bilresa.
• Använd det rekommenderade antalet filer med hjälpav flera tempdb-datafiler som börjar med en fil per kärna, upp till åtta filer.
• Schemalägg SQL Server agentjobb för att köra DBCC CHECKDB, indexera omorganisera,återskapa indexoch uppdatera statistikjobb.
• Övervaka och hantera hälsotillståndet och storleken på SQL Server av transaktionsloggfilen.
• Dra nytta av alla nya SQL Server tillgängliga för den version som används.
• Tänk på skillnaderna i vilka funktioner som stöds mellan de utgåvor som du överväger att distribuera.

Azure-funktioner

Följande är en snabb checklista med metodtips för Azure-specifik vägledning när du kör SQL Server på virtuella Azure-datorer:

• Registrera dig för SQL IaaS-agenttillägget för att låsa upp ett antal funktionsfördelar.
• Utnyttja den bästa strategin för säkerhetskopiering och återställning för din SQL Server arbetsbelastning.
• Se till att Accelererat nätverk är aktiverat på den virtuella datorn.
• Utnyttja Microsoft Defender for Cloud för att förbättra den övergripande säkerhetsstatusen för distributionen av virtuella datorer.
• Utnyttja Microsoft Defender for Cloud, integrerat med Microsoft Defender for Cloud,för specifika vm-täckningar för SQL Server, inklusive sårbarhetsbedömningar och just-in-time-åtkomst, vilket minskar attacktjänsten och ger legitima användare åtkomst till virtuella datorer vid behov. Mer information finns i Sårbarhetsbedömningar, aktivera sårbarhetsbedömningar för SQL Server virtuella datorer och just-in-time-åtkomst.
• Utnyttja Azure Advisor för att hantera prestanda, kostnad, tillförlitlighet, driftseffektivitetoch säkerhetsrekommendationer.
• Utnyttja Azure Monitor att samla in, analysera och agera på telemetridata från din SQL Server miljö. Detta omfattar identifiering av infrastrukturproblem med VM-insikter och övervakningsdata med Log Analytics för djupare diagnostik.
• Aktivera autoshutdown för utvecklings- och testmiljöer.
• Implementera en HADR-lösning (hög tillgänglighet och haveriberedskap) som uppfyller serviceavtalen för affärskontinunivå. Se DE HADR-alternativ som är tillgängliga för SQL Server på virtuella Azure-datorer.
• Använd Azure Portal (support + felsökning) för att utvärdera resurshälsa och historik. skicka nya supportbegäranden när det behövs.

HADR-konfiguration

Funktioner för hög tillgänglighet och haveriberedskap (HADR), till exempel Always On-tillgänglighetsgruppen och redundansklusterinstansen, förlitar sig på underliggande Windows server-redundansklusterteknik. Gå igenom metodtipsen för att ändra HADR-inställningarna för att få bättre stöd för molnmiljön.

För ditt Windows bör du tänka på följande metodtips:

• Distribuera dina virtuella SQL Server-datorer till flera undernät när det är möjligt för att undvika beroendet av en Azure Load Balancer eller ett distribuerat nätverksnamn (DNN) för att dirigera trafik till hadr-lösningen.
• Ändra klustret till mindre aggressiv parametrar för att undvika oväntade avbrott från tillfälliga nätverksfel eller Azure-plattformsunderhåll. Mer information finns i pulsslags- och tröskelvärdesinställningar. För Windows Server 2012 och senare använder du följande rekommenderade värden:
  • SameSubnetDelay: 1 sekund
  • SameSubnetThreshold: 40 pulsslag
  • CrossSubnetDelay: 1 sekund
  • CrossSubnetThreshold: 40 pulsslag
• Placera dina virtuella datorer i en tillgänglighetsuppsättning eller i olika tillgänglighetszoner. Mer information finns i Tillgänglighetsinställningar för virtuella datorer.
• Använd ett enda nätverkskort per klusternod och ett enda undernät.
• Konfigurera att klusterkvorumröstning ska använda 3 eller fler udda antal röster. Tilldela inte röster till DR-regioner.
• Övervaka resursgränser noggrant för att undvika oväntade omstarter eller redundans på grund av resursbegränsningar.
  • Kontrollera att operativsystemet, drivrutinerna och SQL Server är i de senaste versionerna.
  • Optimera prestanda för SQL Server virtuella Azure-datorer. Läs de andra avsnitten i den här artikeln om du vill veta mer.
  • Minska eller sprida ut arbetsbelastningen för att undvika resursgränser.
  • Flytta till en virtuell dator eller disk som har högre gränser för att undvika begränsningar.

För din SQL Server tillgänglighetsgrupp eller redundansklusterinstans bör du överväga följande metodtips:

• Om du får oväntade fel ofta följer du metodtipsen för prestanda som beskrivs i resten av den här artikeln.
• Om optimeringen SQL Server vm-prestanda inte löser dina oväntade redundanser kan du överväga att lätta på övervakningen för tillgänglighetsgruppen eller redundansklusterinstansen. Detta kanske dock inte tar upp den underliggande källan till problemet och kan maskera symptom genom att minska sannolikheten för fel. Du kan fortfarande behöva undersöka och åtgärda den underliggande rotorsaken. För Windows Server 2012 eller högre använder du följande rekommenderade värden:
  • Timeout för lån: Använd den här ekvationen för att beräkna den maximala tidsgränsen för lån:
    Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
    Börja med 40 sekunder. Om du använder de avslappnade och SameSubnetThreshold SameSubnetDelay värden som rekommenderades tidigare ska du inte överskrida 80 sekunder för timeout-värdet för lånet.
  • Maximalt antal fel under en angiven period: Du kan ange det här värdet till 6.
  • Tidsgräns för hälsokontroll: Du kan ange det här värdet till 60 000 initialt och justera efter behov.
• När du använder det virtuella nätverksnamnet (VNN) och Azure Load Balancer för att ansluta till HADR-lösningen anger du i anslutningssträngen, även om klustret endast omfattar ett MultiSubnetFailover = true undernät.
  • Om klienten inte stöder kan du MultiSubnetFailover = True behöva ange och RegisterAllProvidersIP = 0 cachelagra HostRecordTTL = 300 klientautentiseringsuppgifter under kortare tidsperioder. Detta kan dock orsaka ytterligare frågor till DNS-servern.

• Om du vill ansluta till HADR-lösningen med det distribuerade nätverksnamnet (DNN) bör du tänka på följande:
  • Du måste använda en klientdrivrutin som stöder MultiSubnetFailover = True , och den här parametern måste finnas i anslutningssträngen.
  • Använd en unik DNN-port i anslutningssträngen när du ansluter till DNN-lyssnaren för en tillgänglighetsgrupp.
• Använd en anslutningssträng för databasspegling för en grundläggande tillgänglighetsgrupp för att kringgå behovet av en lastbalanserare eller DNN.
• Kontrollera sektorstorleken för dina virtuella hårddiskar innan du distribuerar din lösning för hög tillgänglighet för att undvika feljusterade I/O. Mer information finns i KB3009974.

Mer information finns i de omfattande metodtipsen för HADR.

Nästa steg

Mer information finns i de andra artiklarna i den här serien:

• VM-storlek
• Storage
• Säkerhet
• HADR-inställningar
• Samla in baslinje

Metodtips för säkerhet finns i Säkerhetsöverväganden för SQL Server på Azure Virtual Machines.

Överväg att aktivera SQL Assessment för SQL Server på virtuella Azure-datorer.

Läs andra SQL Server Virtual Machine på sidan SQL Server Azure Virtual Machines Översikt. Om du har frågor om virtuella SQL Server-datorer kan du läsa Vanliga frågor.