Skala resurser för en enskild databas i Azure SQL Database

gäller för:Azure SQL Database

Den här artikeln beskriver hur du skalar de beräknings- och lagringsresurser som är tillgängliga för Azure SQL Database på den etablerade beräkningsnivån. Alternativt tillhandahåller serverlös beräkningsnivå beräkningsbaserad autoskalning 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

Effekt

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 tjänstnivå och beräkningsstorleksändringar kopplas databasfilerna från och kopplas tillbaka under bytet. När växlingen sker kan det leda till ett kort tjänstavbrott när databasen är otillgänglig, oftast i mindre än 30 sekunder och ofta bara i några sekunder. Om det finns långvariga transaktioner som körs när anslutningar tas bort kan varaktigheten för det här steget ta längre tid för att återställa avbrutna transaktioner. Accelererad databasåterställning kan minska effekten från att avbryta långvariga transaktioner.

Fördröjning

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

Om du vill 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 av databasen. Mer information finns i ALTER DATABASE.

Om du vill skala databaser via Azure-portalen, PowerShell, Azure CLI eller REST API: Azure RBAC-behörigheter krävs, 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åde (1) databasens maximala storlek 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. För prissättning av extra lagring, se Prissättning 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änsten skiljer sig åt för de olika tjänstnivåerna. Om du nedgraderar till nivån Basic finns det en lägre kvarhållningsperiod för säkerhetskopior. Se Automatiserade säkerhetskopior i 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ä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

vCore-baserad köpmodell

• Lagring kan tilldelas upp till den maximala datalagringsstorleken i 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.

• Datalagring för en enskild databas kan etableras genom att öka eller minska dess maximala storlek med hjälp av Azure-portalen, Transact-SQL, PowerShell, Azure CLIeller REST API. Om maxstorleksvärdet anges i byte måste det vara en multipel av 1 GB (1 073 741 824 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 transaktionslogglagringen 10 GB * 30% = 3 GBoch den totala mängden fakturerbar lagring är 10 GB + 3 GB = 13 GB.

  Obs!

  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 Prissättning för Azure SQL Database.

DTU-baserad inköpsmodell

• DTU-priset för en enskild databas innehåller en viss mängd lagringsutrymme utan extra kostnad. Extra lagringsutrymme utöver det inkluderade beloppet kan etableras för en extra kostnad upp till maxstorleksgränsen i steg om 250 GB upp till 1 TB och sedan i steg om 256 GB utöver 1 TB. Information om inkluderade lagringsmängder och maxstorleksgränser finns i Enkel databas: Lagringsstorlekar och beräkningsstorlekar.
• Extra lagringsutrymme för en enskild databas kan etableras genom att öka maxstorleken med hjälp av Azure-portalen, Transact-SQL, PowerShell, Azure CLIeller 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 Prissättning 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 lagrings maxvärdet 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. Senare 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 databaserna 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

• Resursgränser för enskilda databaser med köpmodellen för virtuella kärnor
• Resursbegränsningar för enskilda databaser med hjälp av DTU-inköpsmodellen – Azure SQL Database