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:

• Transact-SQL
• Azure-portalen
• PowerShell
• Azure CLI
• REST-API

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:

1. 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.

2. 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.

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:

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');

Övervaka eller avbryta skalningsändringar

En ändrings- eller beräkningsskalningsåtgärd på tjänstnivå kan övervakas och avbrytas.

Login-AzAccount
$SubscriptionID = "<YourSubscriptionIdHere>"
Select-AzSubscription -SubscriptionName $SubscriptionID

Get-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01"

Stop-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" -OperationId af97005d-9243-4f8a-844e-402d1cc855f5

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
$operationName = (az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv)
if (-not [string]::IsNullOrEmpty($operationName)) {
    (az sql db op cancel --resource-group $resourceGroupName --server $serverName --database $databaseName --name $operationName)
        "Operation " + $operationName + " has been canceled"
}
else {
    "No service tier change or compute rescaling operation found"
}

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 tempdb databasen. tempdb finns på den lokala SSD-lagringen på alla tjänstnivåer. Kostnaden för tempdb ingår i priset för en enskild databas eller en elastisk pool.

• Mer information om lagringspriset finns i Priser för 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.

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.