Resources van een individuele database schalen in Azure SQL Database

In dit artikel wordt beschreven hoe u de reken- en opslagresources kunt schalen die beschikbaar zijn voor een Azure SQL Database in de ingerichte rekenlaag. De serverloze rekenlaag biedt ook automatische schaalaanpassing en facturen per seconde voor rekengebruik.

Nadat u in eerste instantie het aantal vCores of DTU's hebt opgehaald, kunt u een individuele database dynamisch omhoog of omlaag schalen op basis van de werkelijke ervaring met behulp van:

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

Impact

Als u de servicelaag of rekenkracht wijzigt, wordt voornamelijk de service uitgevoerd door de volgende stappen uit te voeren:

1. Maak een nieuw rekenproces voor de database.

   Er wordt een nieuw rekenproces gemaakt met de aangevraagde servicelaag en rekenkracht. Voor sommige combinaties van wijzigingen in de servicelaag en de rekengrootte moet een replica van de database worden gemaakt in het nieuwe rekenproces, waarbij gegevens worden gekopieerd en de algehele latentie sterk kan worden beïnvloed. Ongeacht of de database online blijft tijdens deze stap en verbindingen blijven worden omgeleid naar de database in het oorspronkelijke rekenproces.

2. Schakelen tussen routering van verbindingen naar een nieuw rekenproces.

   Bestaande verbindingen met de database in het oorspronkelijke rekenproces worden verwijderd. Nieuwe verbindingen worden tot stand gebracht met de database in het nieuwe rekenproces. Voor sommige combinaties van wijzigingen in de servicelaag en rekengrootte worden databasebestanden losgekoppeld en opnieuw gekoppeld tijdens de switch. De switch kan ook resulteren in een korte serviceonderbreking wanneer de database over het algemeen minder dan 30 seconden niet beschikbaar is en vaak slechts een paar seconden. Als er langlopende transacties worden uitgevoerd wanneer verbindingen worden verbroken, kan de duur van deze stap langer duren om afgebroken transacties te herstellen. Versneld databaseherstel kan de gevolgen verminderen van het afbreken van langlopende transacties.

Latentie

De geschatte latentie voor het wijzigen van de servicelaag, het schalen van de rekenkracht van één database of elastische pool, het verplaatsen van een database in/uit een elastische pool of het verplaatsen van een database tussen elastische pools wordt als volgt geparameteriseerd:

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

Wijzigingen in schalen controleren of annuleren

Een wijzigings- of berekeningsbewerking van een servicelaag kan worden bewaakt en geannuleerd.

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"
}

Bevoegdheden

Als u databases wilt schalen via Transact-SQL, ALTER DATABASE wordt gebruikt. Als u een database wilt schalen, moet de aanmelding van de serverbeheerder zijn (gemaakt toen de logische server van Azure SQL Database is ingericht), de Microsoft Entra-beheerder van de server, een lid van de databaserol dbmanager in master, lid van de db_owner-databaserol in de huidige database of dbo van de database. Zie ALTER DATABASE voor meer informatie.

Als u databases wilt schalen via de Azure-portal, PowerShell, Azure CLI of REST API, zijn Azure RBAC-machtigingen nodig, met name de rol Inzender, SQL DB-inzender of De rol Inzender van SQL Server Azure RBAC. Ga naar ingebouwde Rollen van Azure RBAC voor meer informatie.

Aanvullende overwegingen

• Als u een upgrade naar een hogere servicelaag of rekenkracht wilt uitvoeren, neemt de maximale grootte van de database niet toe, tenzij u expliciet een grotere grootte opgeeft (maxsize).
• Als u een database wilt downgraden, moet de gebruikte databaseruimte kleiner zijn dan de maximaal toegestane grootte van de doelservicelaag en rekenkracht.
• Wanneer u een downgrade uitvoert van Premium naar de Standard-laag , gelden er extra opslagkosten als beide (1) de maximale grootte van de database worden ondersteund in de doelrekengrootte en (2) de maximale grootte groter is dan de inbegrepen opslaghoeveelheid van de doelrekengrootte. Als bijvoorbeeld een P1-database met een maximale grootte van 500 GB wordt verkleind naar S3, zijn er extra opslagkosten van toepassing omdat S3 een maximale grootte van 1 TB ondersteunt en de inbegrepen opslagruimte slechts 250 GB is. De extra opslagruimte is dus 500 GB – 250 GB = 250 GB. Zie Azure SQL Database-prijzen voor prijzen voor extra opslag. Als de werkelijke hoeveelheid gebruikte ruimte kleiner is dan de inbegrepen opslagruimte, kunnen deze extra kosten worden vermeden door de maximale grootte van de database te verkleinen tot het inbegrepen bedrag.
• Bij het upgraden van een database waarvoor geo-replicatie is ingeschakeld, moet u de secundaire databases upgraden naar de gewenste servicelaag en rekenkracht voordat u de primaire database bijwerken (algemene richtlijnen voor de beste prestaties). Wanneer u een upgrade naar een andere editie uitvoert, is het een vereiste dat de secundaire database eerst wordt bijgewerkt.
• Bij het downgraden van een database waarvoor geo-replicatie is ingeschakeld, downgradet u de primaire databases naar de gewenste servicelaag en rekenkracht voordat u de secundaire database downgradet (algemene richtlijnen voor de beste prestaties). Bij het downgraden naar een andere editie is het een vereiste dat de primaire database eerst wordt gedowngradeerd.
• De mogelijkheden om de service te herstellen verschillen voor de verschillende servicelagen. Als u een downgrade uitvoert naar de Basic-laag , is er een lagere bewaarperiode voor back-ups. Zie Back-ups van Azure SQL Database.
• De nieuwe eigenschappen voor de database worden pas toegepast als de wijzigingen zijn voltooid.
• Wanneer het kopiëren van gegevens vereist is om een database te schalen (zie Latentie) bij het wijzigen van de servicelaag, kan een hoog resourcegebruik gelijktijdig met de schaalbewerking langere schaaltijden veroorzaken. Met versneld databaseherstel (ADR) is het terugdraaien van langlopende transacties geen belangrijke oorzaak van vertraging, maar een hoog gelijktijdig resourcegebruik kan minder reken-, opslag- en netwerkbandbreedteresources achterlaten voor schaalaanpassing, met name voor kleinere rekenkracht.

Billing

U wordt gefactureerd voor elk uur dat een database bestaat met behulp van de hoogste servicelaag + rekenkracht die tijdens dat uur wordt toegepast, ongeacht het gebruik of dat de database gedurende minder dan een uur actief was. Als u bijvoorbeeld één database maakt en deze vijf minuten later verwijdert, worden er kosten in rekening gebracht voor één databaseuur.

Opslaggrootte wijzigen

Aankoopmodel op basis van vCore

• Opslag kan worden ingericht tot de maximale groottelimiet voor gegevensopslag met behulp van stappen van 1 GB. De minimale configureerbare gegevensopslag is 1 GB. Zie voor maximale groottelimieten voor gegevensopslag in elke servicedoelstelling documentatiepagina's voor resourcelimieten voor individuele databases met behulp van het vCore-aankoopmodel en resourcelimieten voor individuele databases met behulp van het DTU-aankoopmodel.

• Gegevensopslag voor één database kan worden ingericht door de maximale grootte te vergroten of te verlagen met behulp van de Azure Portal, Transact-SQL, PowerShell, Azure CLI of REST API. Als de maximale groottewaarde is opgegeven in bytes, moet deze een veelvoud van 1 GB (1073741824 bytes).

• De hoeveelheid gegevens die in de gegevensbestanden van een database kan worden opgeslagen, wordt beperkt door de maximale grootte van de geconfigureerde gegevensopslag. Naast die opslag voegt Azure SQL Database automatisch 30% meer opslagruimte toe om te worden gebruikt voor het transactielogboek. De opslagprijs voor één database of een elastische pool is de som van de opslag- en transactielogboekopslagbedragen vermenigvuldigd met de opslageenheidprijs van de servicelaag. Als de gegevensopslag bijvoorbeeld is ingesteld op 10 GB, is de extra opslag voor transactielogboeken 10 GB * 30% = 3 GB en is de totale hoeveelheid factureerbare opslag 10 GB + 3 GB = 13 GB.

  Notitie

  De maximale grootte van het transactielogboekbestand wordt automatisch beheerd en kan in sommige gevallen groter zijn dan 30% van de maximale grootte van de gegevensopslag. Hierdoor wordt de opslagprijs voor de database niet verhoogd.

• Azure SQL Database wijst automatisch 32 GB per vCore toe voor de tempdb database. tempdb bevindt zich op de lokale SSD-opslag in alle servicelagen. De kosten van tempdb deze gegevens zijn inbegrepen in de prijs van één database of een elastische pool.

• Zie prijzen voor Azure SQL Database voor meer informatie over de opslagprijs.

Aankoopmodel op basis van DTU

• De DTU-prijs voor een individuele database bevat een bepaalde hoeveelheid opslagruimte zonder extra kosten. Extra opslag buiten het inbegrepen bedrag kan worden ingericht voor extra kosten tot de maximale groottelimiet in stappen van 250 GB tot 1 TB en vervolgens in stappen van 256 GB boven 1 TB. Zie Individuele database voor opgenomen opslagbedragen en maximale groottelimieten : Opslaggrootten en rekengrootten.
• Extra opslag voor één database kan worden ingericht door de maximale grootte te vergroten met behulp van de Azure Portal, Transact-SQL, PowerShell, de Azure CLI of de REST API.
• De prijs van extra opslag voor één database is de extra opslaghoeveelheid vermenigvuldigd met de prijs voor extra opslageenheden van de servicelaag. Zie prijzen voor Azure SQL Database voor meer informatie over de prijs van extra opslag.

Geo-gerepliceerde databases

Als u de databasegrootte van een gerepliceerde secundaire database wilt wijzigen, wijzigt u de grootte van de primaire database. Deze wijziging wordt vervolgens ook gerepliceerd en geïmplementeerd in de secundaire database.

P11- en P15-beperkingen wanneer de maximale grootte groter is dan 1 TB

Meer dan 1 TB opslagruimte in de Premium-laag is momenteel beschikbaar in alle regio's, met uitzondering van: China - oost, China - noord, Duitsland - centraal en Duitsland - noordoost. In deze regio’s is de maximale opslagruimte in de Premium-laag beperkt tot 1 TB. De volgende overwegingen en beperkingen zijn van toepassing op P11- en P15-databases met een maximale grootte van meer dan 1 TB:

• Als de maximale grootte voor een P11- of P15-database ooit is ingesteld op een waarde die groter is dan 1 TB, kan deze alleen worden hersteld of gekopieerd naar een P11- of P15-database. Vervolgens kan de database opnieuw worden geschaald naar een andere rekengrootte, mits de hoeveelheid ruimte die is toegewezen op het moment van de schaalbewerking niet groter is dan de maximale groottelimieten van de nieuwe rekengrootte.
• Voor actieve geo-replicatiescenario's:
  • Een geo-replicatierelatie instellen: als de primaire database P11 of P15 is, moeten de secundaire(e) ook P11 of P15 zijn. Lagere rekenkracht wordt geweigerd als secundaire bestanden, omdat ze niet meer dan 1 TB kunnen ondersteunen.
  • De primaire database bijwerken in een geo-replicatierelatie: als u de maximale grootte wijzigt in meer dan 1 TB op een primaire database, wordt dezelfde wijziging in de secundaire database geactiveerd. Beide upgrades moeten zijn geslaagd voor de wijziging op de primaire versie om van kracht te worden. Regiobeperkingen voor de optie van meer dan 1 TB zijn van toepassing. Als de secundaire zich in een regio bevindt die niet meer dan 1 TB ondersteunt, wordt de primaire niet bijgewerkt.
• Het gebruik van de Import/Export-service voor het laden van P11/P15-databases met meer dan 1 TB wordt niet ondersteund. Gebruik SqlPackage om gegevens te importeren en exporteren .

Gerelateerde inhoud

Zie resourcelimieten op basis van Azure SQL Database vCore voor algemene resourcelimieten : individuele databases en resourcelimieten op basis van Azure SQL Database DTU - individuele databases.