Dynamisk skalning av databasresurser med minimal stilleståndstid – Azure SQL Database och Azure SQL Managed Instance

Gäller för:Azure SQL DatabaseAzure SQL Managed Instance

Med Azure SQL Database och Azure SQL Managed Instance kan du dynamiskt lägga till fler resurser i databasen med minimal stilleståndstid. Det finns dock en växling över en period där anslutningen går förlorad till databasen under en kort tid, vilket kan minimeras med hjälp av omförsökslogik.

Översikt

När efterfrågan på din app växer från en handfull enheter och kunder till miljoner skalas Azure SQL Database och SQL Managed Instance i farten med minimal stilleståndstid. Skalbarhet är en av de viktigaste egenskaperna för PaaS (Plattform som en tjänst) som gör att du dynamiskt kan lägga till fler resurser i tjänsten när det behövs. Med Azure SQL Database kan du enkelt ändra resurser (processorkraft, minne, I/O-dataflöde och lagring) som allokerats till dina databaser.

Du kan åtgärda prestandaproblem på grund av ökad användning av ditt program som inte kan åtgärdas med hjälp av indexerings- eller frågeomskrivningsmetoder. Genom att lägga till fler resurser kan du snabbt reagera när databasen når de aktuella resursgränserna och behöver mer kraft för att hantera den inkommande arbetsbelastningen. Med Azure SQL Database kan du också skala ned resurserna när de inte behövs för att sänka kostnaden.

Du behöver inte bekymra dig om att köpa maskinvara och ändra underliggande infrastruktur. Det är enkelt att skala en databas via Azure-portalen med hjälp av ett skjutreglage.

Azure SQL Database erbjuder den DTU-baserade inköpsmodellen och den vCore-baserade inköpsmodellen, medan Azure SQL Managed Instance bara erbjuder den vCore-baserade köpmodellen.

• Den DTU-baserade inköpsmodellen erbjuder en blandning av beräknings-, minnes- och I/O-resurser på tre tjänstnivåer för att stödja enkla till tunga databasarbetsbelastningar: Basic, Standard och Premium. Det finns prestandanivåer inom varje nivå med en blandning av dessa resurser, och du kan lägga till ytterligare lagringsresurser till dessa.
• Med köpmodellen baserad på virtuell kärna kan du välja antalet virtuella kärnor, mängden eller minnet samt mängden och lagringshastigheten. Den här inköpsmodellen erbjuder tre tjänstnivåer: Generell användning, Affärskritisk och Hyperskala.

Tjänstnivån, beräkningsnivån och resursgränserna för en databas, elastisk pool eller hanterad instans kan ändras när som helst. Du kan till exempel skapa din första app på en enda databas med hjälp av den serverlösa beräkningsnivån och sedan ändra dess tjänstnivå manuellt eller programmatiskt när som helst till den etablerade beräkningsnivån för att uppfylla behoven i din lösning.

Kommentar

Viktiga undantag där du inte kan ändra tjänstnivån för en databas är:

• Databaser som använder funktioner som endast är tillgängliga på tjänstnivåerna Affärskritisk/Premium kan inte ändras för att använda tjänstnivån Generell användning/Standard. För närvarande är den enda funktionen minnesintern OLTP.
• Databaser som ursprungligen skapades på tjänstnivån Hyperskala kan inte migreras till andra tjänstnivåer. Om du migrerar en befintlig databas i Azure SQL Database till tjänstnivån Hyperskala kan du ångra migreringen till tjänstnivån Generell användning inom 45 dagar efter den ursprungliga migreringen till Hyperskala. Om du vill migrera databasen till en annan tjänstnivå, till exempel Affärskritisk, måste du först omvända migreringen till tjänstnivån Generell användning och sedan utföra en ytterligare migrering. Läs mer i Så här omvänt migrerar du från Hyperskala.

Du kan justera de resurser som allokerats till databasen genom att ändra tjänstmålet eller skalning för att uppfylla arbetsbelastningskraven. På så sätt kan du också bara betala för de resurser du behöver, när du behöver dem. Se anmärkningen om den potentiella inverkan som en skalningsåtgärd kan ha på ett program.

Azure SQL Database erbjuder möjligheten att dynamiskt skala dina databaser:

• Med en enda databas kan du använda DTU- eller vCore-modeller för att definiera maximal mängd resurser som ska tilldelas till varje databas.
• Med elastiska pooler kan du definiera maximal resursgräns per grupp med databaser i poolen.

Med Azure SQL Managed Instance kan du även skala:

• SQL Managed Instance använder vCores-läge och gör att du kan definiera maximalt antal processorkärnor och maximalt lagringsutrymme som allokeras till din instans. Alla databaser i den hanterade instansen delar de resurser som allokerats till instansen.

Dricks

Med dynamisk skalning kan kunder ändra resursallokering manuellt eller programmatiskt. Den dynamiska skalningsfunktionen är tillgänglig för alla Azure SQL Database- och Azure SQL Managed Instance-resurser.

Förutom att stödja dynamisk skalning stöder den serverlösa nivån i Azure SQL Database automatisk skalning. Databaser på den serverlösa nivån skalar resurser automatiskt inom ett kunddegivet intervall baserat på efterfrågan på arbetsbelastningar. Ingen kundåtgärd krävs för att skala databasen.

Påverkan av upp- eller nedskalningsåtgärder

När du initierar en uppskalnings- eller nedskalningsåtgärd i någon av de ovan nämnda smakerna startar du om databasmotorprocessen och flyttar den till en annan virtuell dator om det behövs. Att flytta databasmotorprocessen till en ny virtuell dator är en onlineprocess där du kan fortsätta använda din befintliga Azure SQL Database-tjänst. När måldatabasmotorn är redo att bearbeta frågor avslutas öppna anslutningar till den aktuella databasmotorn och ogenomförda transaktioner återställs. Nya anslutningar görs till måldatabasmotorn.

Kommentar

Vi rekommenderar inte att du skalar din hanterade instans om en tidskrävande transaktion, till exempel dataimport, databearbetningsjobb, återskapande av index osv., körs eller om du har någon aktiv anslutning på instansen. För att förhindra att skalningen tar längre tid att slutföra än vanligt bör du skala instansen när alla tidskrävande åtgärder har slutförts.

Kommentar

Du kan förvänta dig en kort anslutningspaus när uppskalnings-/nedskalningsprocessen är klar. Om du har implementerat omprövningslogik för tillfälliga standardfel kommer du inte att märka redundansväxlingen.

Alternativa skalningsmetoder

Skalning av resurser är det enklaste och mest effektiva sättet att förbättra databasens prestanda utan att ändra antingen databasen eller programkoden. I vissa fall kanske inte ens de högsta tjänstnivåerna, beräkningsstorlekarna och prestandaoptimeringarna hanterar din arbetsbelastning på ett framgångsrikt och kostnadseffektivt sätt. I så fall har du dessa ytterligare alternativ för att skala databasen:

• Utskalning av läsning är en tillgänglig funktion där du får en skrivskyddad replik av dina data där du kan köra krävande skrivskyddade frågor som rapporter. En skrivskyddad replik hanterar din skrivskyddade arbetsbelastning utan att påverka resursanvändningen i din primära databas.
• Databassharding är en uppsättning tekniker som gör att du kan dela upp dina data i flera databaser och skala dem oberoende av varandra.

Nästa steg

• Information om hur du förbättrar databasprestanda genom att ändra databaskod finns i Hitta och tillämpa prestandarekommendationer.
• Information om hur du låter inbyggd databasinformation optimera din databas finns i Automatisk justering.
• Information om lässkalning i Azure SQL Database finns i använda skrivskyddade repliker för att belastningsutjämning av skrivskyddade frågearbetsbelastningar.
• Information om en databassharding finns i Skala ut med Azure SQL Database.
• Ett exempel på hur du använder skript för att övervaka och skala en enskild databas finns i Använda PowerShell för att övervaka och skala en enskild SQL Database.