Skala enkla databasresurser i Azure SQL Database
Den här artikeln beskriver hur du skalar de beräknings- och lagringsresurser som är tillgängliga för en Azure SQL Database på den etablerade beräkningsnivån. Alternativt tillhandahåller den serverlösa beräkningsnivån automatisk beräkning och fakturor per sekund för beräkning som används.
När du har valt antalet virtuella kärnor eller DTU:er kan du skala upp eller ned en enskild databas dynamiskt baserat på den faktiska upplevelsen med hjälp av:
Viktigt!
Under vissa omständigheter kan du behöva krympa en databas för att frigöra outnyttjat utrymme. Mer information finns i Hantera filutrymme i Azure SQL Database.
Kommentar
Microsoft Entra-ID är det nya namnet för Azure Active Directory (Azure AD). Vi uppdaterar dokumentationen just nu.
Påverkan
Om du ändrar tjänstnivån eller beräkningsstorleken för innebär det främst att tjänsten utför följande steg:
Skapa en ny beräkningsinstans för databasen.
En ny beräkningsinstans skapas med den begärda tjänstnivån och beräkningsstorleken. För vissa kombinationer av ändringar av tjänstnivå och beräkningsstorlek måste en replik av databasen skapas i den nya beräkningsinstansen, vilket innebär att data kopieras och kan påverka den övergripande svarstiden. Oavsett är databasen fortfarande online under det här steget och anslutningarna fortsätter att dirigeras till databasen i den ursprungliga beräkningsinstansen.
Växla routning av anslutningar till en ny beräkningsinstans.
Befintliga anslutningar till databasen i den ursprungliga beräkningsinstansen tas bort. Alla nya anslutningar upprättas till databasen i den nya beräkningsinstansen. För vissa kombinationer av ändringar av tjänstnivå och beräkningsstorlek kopplas databasfilerna från och kopplas tillbaka under växeln. Oavsett kan växeln leda till ett kort tjänstavbrott när databasen är otillgänglig i allmänhet i mindre än 30 sekunder och ofta i bara några sekunder. Om det finns långvariga transaktioner som körs när anslutningar tas bort kan det ta längre tid för det här steget att återställa avbrutna transaktioner. Accelererad databasåterställning kan minska effekten från att avbryta långvariga transaktioner.
Viktigt!
Inga data går förlorade under ett steg i arbetsflödet. Kontrollera att du har implementerat viss logik för återförsök i de program och komponenter som använder Azure SQL Database medan tjänstnivån ändras.
Svarstid
Den uppskattade svarstiden för att ändra tjänstnivån, skala beräkningsstorleken för en enskild databas eller elastisk pool, flytta en databas in/ut från en elastisk pool eller flytta en databas mellan elastiska pooler parametriseras på följande sätt:
| Svarstid för databasskalning | Till Enkel enkel databas, Standard enkel databas (S0-S1) |
Till Standard enkel databas (S2-S12), Generell användning enkel databas, Grundläggande elastisk pooldatabas, Standard elastisk pooldatabas, Generell användning pooldatabas |
Till en enskild Premium-databas eller pooldatabas Affärskritisk enkel databas eller pooldatabas |
Till hyperskala för enkel databas eller pooldatabas |
|---|---|---|---|---|
| Från Enkel enkel enkel databas, Standard enkel databas (S0-S1) |
• Konstant tidsfördröjning oberoende av använt utrymme. • Normalt mindre än 5 minuter. |
• Svarstider som är proportionella mot databasutrymme som används på grund av datakopiering. • Normalt används mindre än 1 minut per GB utrymme. |
• Svarstider som är proportionella mot databasutrymme som används på grund av datakopiering. • Normalt används mindre än 1 minut per GB utrymme. |
• Svarstider som är proportionella mot databasutrymme som används på grund av datakopiering. • Normalt används mindre än 1 minut per GB utrymme. |
| Från enkel pooldatabas, enkel standarddatabas (S2-S12), standarddatabas med pool, enkel databas för generell användning eller pooldatabas |
• Svarstider som är proportionella mot databasutrymme som används på grund av datakopiering. • Normalt används mindre än 1 minut per GB utrymme. |
• För enkla databaser är konstant tidsfördröjning oberoende av det utrymme som används. • Vanligtvis mindre än 5 minuter för enskilda databaser. • För elastiska pooler, proportionellt mot antalet databaser. |
• Svarstider som är proportionella mot databasutrymme som används på grund av datakopiering. • Normalt används mindre än 1 minut per GB utrymme. |
• Svarstider som är proportionella mot databasutrymme som används på grund av datakopiering. • Normalt används mindre än 1 minut per GB utrymme. |
| Från en enskild Premium-databas eller pooldatabas Affärskritisk enkel databas eller pooldatabas |
• Svarstider som är proportionella mot databasutrymme som används på grund av datakopiering. • Normalt används mindre än 1 minut per GB utrymme. |
• Svarstider som är proportionella mot databasutrymme som används på grund av datakopiering. • Normalt används mindre än 1 minut per GB utrymme. |
• Svarstider som är proportionella mot databasutrymme som används på grund av datakopiering. • Normalt används mindre än 1 minut per GB utrymme. |
• Svarstider som är proportionella mot databasutrymme som används på grund av datakopiering. • Normalt används mindre än 1 minut per GB utrymme. |
| Från en enkel Hyperskala-databas eller pooldatabas | Ej tillämpligt | Se Omvänd migrering från Hyperskala för scenarier och begränsningar som stöds. | Ej tillämpligt | • Konstant tidsfördröjning oberoende av använt utrymme. • Normalt mindre än 2 minuter. |
Kommentar
- För standarddatabaser (S2-S12) och generell användning är svarstiden för att flytta en databas in/ut från en elastisk pool eller mellan elastiska pooler proportionell mot databasens storlek om databasen använder PFS-lagring (Premium File Share).
- Om du flyttar en databas till/från en elastisk pool påverkar endast det utrymme som används av databasen svarstiden, inte det utrymme som används av den elastiska poolen.
- Kör följande fråga i databasens kontext för att avgöra om en databas använder PFS-lagring. Om värdet i kolumnen AccountType är
PremiumFileStorageellerPremiumFileStorage-ZRSanvänder databasen PFS-lagring.
SELECT s.file_id,
s.type_desc,
s.name,
FILEPROPERTYEX(s.name, 'AccountType') AS AccountType
FROM sys.database_files AS s
WHERE s.type_desc IN ('ROWS', 'LOG');
Kommentar
- Den zonredundanta egenskapen förblir densamma som standard när du skalar en enskild databas från Affärskritisk till nivån Generell användning.
- Svarstiden för skalningsåtgärden när zonredundans ändras för en enskild databas för generell användning är proportionell mot databasens storlek.
Dricks
Information om hur du övervakar pågående åtgärder finns i: Hantera åtgärder med HJÄLP av SQL REST API, Hantera åtgärder med CLI, Övervaka åtgärder med T-SQL och dessa två PowerShell-kommandon: Get-AzSqlDatabaseActivity och Stop-AzSqlDatabaseActivity.
Övervaka eller avbryta skalningsändringar
En ändrings- eller beräkningsskalningsåtgärd på tjänstnivå kan övervakas och avbrytas.
På sidan Översikt över SQL-databas letar du efter banderollen som anger att en skalningsåtgärd pågår och väljer länken Visa mer för den pågående distributionen.
På den resulterande sidan Pågående åtgärder väljer du Avbryt den här åtgärden.
Behörigheter
För att skala databaser via Transact-SQL ALTER DATABASE används. Om du vill skala en databas måste en inloggning antingen vara serveradministratörens inloggning (som skapades när den logiska Azure SQL Database-servern etablerades), Microsoft Entra-administratören för servern, en medlem av databasrollen dbmanager i master, en medlem av db_owner databasrollen i den aktuella databasen eller dbo i databasen. Mer information finns i ALTER DATABASE.
Om du vill skala databaser via Azure-portalen, PowerShell, Azure CLI eller REST API krävs Azure RBAC-behörigheter, särskilt rollen Deltagare, SQL DB-deltagare eller AZURE RBAC-roll för SQL Server-deltagare. Mer information finns i inbyggda Azure RBAC-roller.
Ytterligare överväganden
- Om du uppgraderar till en högre tjänstnivå eller beräkningsstorlek ökar inte databasens maxstorlek om du inte uttryckligen anger en större storlek (maxstorlek).
- Om du vill nedgradera en databas måste det använda utrymmet vara mindre än den maximala tillåtna storleken på måltjänstnivån och beräkningsstorleken.
- Vid nedgradering från Premium till Standard-nivån gäller en extra lagringskostnad om båda (1) den maximala storleken på databasen stöds i målberäkningsstorleken och (2) maxstorleken överskrider den inkluderade lagringsmängden för målberäkningsstorleken. Om till exempel en P1-databas med en maxstorlek på 500 GB har minskats till S3, gäller en extra lagringskostnad eftersom S3 stöder en maximal storlek på 1 TB och dess inkluderade lagringsmängd bara är 250 GB. Det extra lagringsutrymmet är alltså 500 GB – 250 GB = 250 GB. Priser för extra lagring finns i Priser för Azure SQL Database. Om den faktiska mängden utrymme som används är mindre än den inkluderade lagringsmängden kan du undvika den här extra kostnaden genom att minska databasens maximala storlek till den inkluderade mängden.
- När du uppgraderar en databas med geo-replikering aktiverad uppgraderar du dess sekundära databaser till önskad tjänstnivå och beräkningsstorlek innan du uppgraderar den primära databasen (allmän vägledning för bästa prestanda). När du uppgraderar till en annan utgåva är det ett krav att den sekundära databasen uppgraderas först.
- När du nedgraderar en databas med geo-replikering aktiverad nedgraderar du dess primära databaser till önskad tjänstnivå och beräkningsstorlek innan du nedgraderar den sekundära databasen (allmän vägledning för bästa prestanda). När du nedgraderar till en annan utgåva är det ett krav att den primära databasen nedgraderas först.
- Erbjudandena för återställningstjänsterna är olika för de olika tjänstnivåerna. Om du nedgraderar till Basic-nivån finns det en lägre kvarhållningsperiod för säkerhetskopior. Se Säkerhetskopior av Azure SQL Database.
- De nya egenskaperna för databasen tillämpas inte förrän ändringarna har slutförts.
- När datakopiering krävs för att skala en databas (se Svarstid) när du ändrar tjänstnivån kan hög resursanvändning samtidigt med skalningsåtgärden orsaka längre skalningstider. Med Accelererad databasåterställning (ADR) är återställning av långvariga transaktioner inte en betydande fördröjningskälla, men hög samtidig resursanvändning kan lämna mindre resurser för beräkning, lagring och nätverksbandbredd för skalning, särskilt för mindre beräkningsstorlekar.
Fakturering
Du debiteras för varje timme som en databas finns med den högsta tjänstnivån + beräkningsstorleken som tillämpades under den timmen, oavsett användning eller om databasen var aktiv i mindre än en timme. Om du till exempel skapar en enkel databas och tar bort den fem minuter senare visar fakturan en avgift för en databastimmes.
Ändra lagringsstorlek
Köpmodell baserad på virtuell kärna
Lagring kan etableras upp till maxstorleksgränsen för datalagring med hjälp av steg om 1 GB. Den minsta konfigurerbara datalagringen är 1 GB. För maximala storleksgränser för datalagring i varje tjänstmål, se dokumentationssidor för resursgräns för Resursgränser för enskilda databaser med köpmodellen för virtuella kärnor och Resursgränser för enskilda databaser med hjälp av DTU-inköpsmodellen.
Datalagringen för en enkel databas kan etableras genom att du ökar eller minskar den maximala storleken med hjälp av Azure Portal, Transact-SQL, PowerShell, Azure CLI eller REST API. Om värdet för maximal storlek anges i byte måste det vara en multipel på 1 GB (1073741824 byte).
Mängden data som kan lagras i datafilerna i en databas begränsas av den konfigurerade maximala datalagringsstorleken. Utöver den lagringen lägger Azure SQL Database automatiskt till 30 % mer lagringsutrymme som ska användas för transaktionsloggen. Priset för lagring för en enskild databas eller en elastisk pool är summan av datalagrings- och transaktionslogglagringsbelopp multiplicerat med lagringsenhetspriset på tjänstnivån. Om datalagring till exempel är inställt på 10 GB är den extra lagringen för transaktionsloggen 10 GB * 30 % = 3 GB och den totala mängden fakturerbar lagring är 10 GB + 3 GB = 13 GB.
Kommentar
Den maximala storleken på transaktionsloggfilen hanteras automatiskt och kan i vissa fall vara större än 30 % av den maximala datalagringsstorleken. Detta ökar inte lagringspriset för databasen.
Azure SQL Database allokerar automatiskt 32 GB per virtuell kärna för
tempdbdatabasen.tempdbfinns på den lokala SSD-lagringen på alla tjänstnivåer. Kostnaden förtempdbingår i priset för en enskild databas eller en elastisk pool.Mer information om lagringspriset finns i Priser för Azure SQL Database.
Viktigt!
Under vissa omständigheter kan du behöva krympa en databas för att frigöra outnyttjat utrymme. Mer information finns i Hantera filutrymme i Azure SQL Database.
Köpmodell baserad på DTU
- DTU-priset för en enskild databas innehåller en viss mängd lagringsutrymme utan extra kostnad. Extra lagringsutrymme utöver den inkluderade mängden kan etableras till en extra kostnad upp till den maximala storleksgränsen i steg om 250 GB upp till 1 TB och därefter i steg om 256 GB över 1 TB. Information om inkluderade lagringsmängder och maxstorleksgränser finns i Enkel databas: Lagringsstorlekar och beräkningsstorlekar.
- Extra datalagring för en enkel databas kan etableras genom att du ökar eller minskar den maximala storleken med hjälp av Azure Portal, Transact-SQL, PowerShell, Azure CLI eller REST API.
- Priset för extra lagring för en enskild databas är den extra lagringsmängden multiplicerat med det extra priset för lagringsenheter på tjänstnivån. Mer information om priset för extra lagring finns i Priser för Azure SQL Database.
Viktigt!
Under vissa omständigheter kan du behöva krympa en databas för att frigöra outnyttjat utrymme. Mer information finns i Hantera filutrymme i Azure SQL Database.
Geo-replikerad databas
Om du vill ändra databasstorleken för en replikerad sekundär databas ändrar du storleken på den primära databasen. Den här ändringen replikeras sedan och implementeras även på den sekundära databasen.
P11- och P15-begränsningar när maxstorleken är större än 1 TB
Mer än 1 TB lagringsutrymme på Premium-nivån är för närvarande tillgängligt i alla regioner utom: Kina, östra, Kina, norra, Tyskland, centrala och Tyskland, nordöstra. I dessa regioner är det maximala lagringsutrymmet på Premium-nivån begränsat till 1 TB. Följande överväganden och begränsningar gäller för P11- och P15-databaser med en maximal storlek som är större än 1 TB:
- Om maxstorleken för en P11- eller P15-databas någonsin har angetts till ett värde som är större än 1 TB kan den bara återställas eller kopieras till en P11- eller P15-databas. Därefter kan databasen skalas om till en annan beräkningsstorlek, förutsatt att mängden utrymme som allokerats vid tidpunkten för omskalningsåtgärden inte överskrider maxstorleksgränserna för den nya beräkningsstorleken.
- För aktiva geo-replikeringsscenarier:
- Konfigurera en geo-replikeringsrelation: Om den primära databasen är P11 eller P15 måste de sekundära (ies) också vara P11 eller P15. Lägre beräkningsstorlekar avvisas som sekundär eftersom de inte kan stödja mer än 1 TB.
- Uppgradering av den primära databasen i en geo-replikeringsrelation: Om du ändrar den maximala storleken till mer än 1 TB på en primär databas utlöses samma ändring på den sekundära databasen. Båda uppgraderingarna måste lyckas för att ändringen på den primära ska börja gälla. Regionbegränsningar för alternativet mer än 1 TB gäller. Om den sekundära är i en region som inte har stöd för mer än 1 TB uppgraderas inte den primära.
- Det går inte att använda tjänsten Import/Export för att läsa in P11/P15-databaser med mer än 1 TB. Använd SqlPackage för att importera och exportera data.
Relaterat innehåll
Övergripande resursgränser finns i Azure SQL Database vCore-baserade resursgränser – enskilda databaser och Azure SQL Database DTU-baserade resursgränser – enkla databaser.
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för