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

Belangrijk

In sommige gevallen moet u mogelijk een database verkleinen om ongebruikte ruimte vrij te maken. Zie Bestandsruimte beheren in Azure SQL Database voor meer informatie.

Notitie

Microsoft Entra-id is de nieuwe naam voor Azure Active Directory (Azure AD). Op dit moment wordt de documentatie bijgewerkt.

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.

Belangrijk

Er gaan geen gegevens verloren tijdens een stap in de werkstroom. Zorg ervoor dat u een aantal logica voor opnieuw proberen hebt geïmplementeerd in de toepassingen en onderdelen die gebruikmaken van Azure SQL Database terwijl de servicelaag wordt gewijzigd.

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:

Latentie voor het schalen van databases	Naar Eenvoudige individuele database, Standaard individuele database (S0-S1)	Naar Standaard individuele database (S2-S12), Individuele database voor algemeen gebruik,Eenvoudige elastische pooldatabase,Standard elastische pooldatabase,pooldatabase voor algemeen gebruik	Voor Een Premium-database of pooldatabase, Bedrijfskritiek individuele database of pooldatabase	Naar een individuele of pooldatabase van Hyperscale
Van individuele Basic-database, Standaard individuele database (S0-S1)	• Constante tijdlatentie onafhankelijk van de gebruikte ruimte. • Doorgaans minder dan 5 minuten.	• Latentie evenredig met de databaseruimte die wordt gebruikt vanwege het kopiëren van gegevens. • Doorgaans minder dan 1 minuut per GB aan gebruikte ruimte.	• Latentie evenredig met de databaseruimte die wordt gebruikt vanwege het kopiëren van gegevens. • Doorgaans minder dan 1 minuut per GB aan gebruikte ruimte.	• Latentie evenredig met de databaseruimte die wordt gebruikt vanwege het kopiëren van gegevens. • Doorgaans minder dan 1 minuut per GB aan gebruikte ruimte.
Uit een basic gegroepeerde database, een standard individuele database (S2-S12), een pooldatabase met standard, individuele database voor algemeen gebruik of een pooldatabase	• Latentie evenredig met de databaseruimte die wordt gebruikt vanwege het kopiëren van gegevens. • Doorgaans minder dan 1 minuut per GB aan gebruikte ruimte.	• Voor individuele databases is constante tijdlatentie onafhankelijk van de gebruikte ruimte. • Doorgaans minder dan 5 minuten voor individuele databases. • Voor elastische pools, evenredig met het aantal databases.	• Latentie evenredig met de databaseruimte die wordt gebruikt vanwege het kopiëren van gegevens. • Doorgaans minder dan 1 minuut per GB aan gebruikte ruimte.	• Latentie evenredig met de databaseruimte die wordt gebruikt vanwege het kopiëren van gegevens. • Doorgaans minder dan 1 minuut per GB aan gebruikte ruimte.
Van Individuele Premium-database of pooldatabase, Bedrijfskritiek individuele database of pooldatabase	• Latentie evenredig met de databaseruimte die wordt gebruikt vanwege het kopiëren van gegevens. • Doorgaans minder dan 1 minuut per GB aan gebruikte ruimte.	• Latentie evenredig met de databaseruimte die wordt gebruikt vanwege het kopiëren van gegevens. • Doorgaans minder dan 1 minuut per GB aan gebruikte ruimte.	• Latentie evenredig met de databaseruimte die wordt gebruikt vanwege het kopiëren van gegevens. • Doorgaans minder dan 1 minuut per GB aan gebruikte ruimte.	• Latentie evenredig met de databaseruimte die wordt gebruikt vanwege het kopiëren van gegevens. • Doorgaans minder dan 1 minuut per GB aan gebruikte ruimte.
Van individuele of pooldatabase met Hyperscale	N.v.t.	Zie Omgekeerde migratie van Hyperscale voor ondersteunde scenario's en beperkingen.	N.v.t.	• Constante tijdlatentie onafhankelijk van de gebruikte ruimte. • Doorgaans minder dan 2 minuten.

Notitie

• Daarnaast is de latentie voor standaarddatabases (S2-S12) en algemeen gebruik voor het verplaatsen van een database in/uit een elastische pool of tussen elastische pools evenredig met de databasegrootte als de database gebruikmaakt van PFS-opslag (Premium File Share).
• In het geval van het verplaatsen van een database naar/van een elastische pool, heeft alleen de ruimte die door de database wordt gebruikt invloed op de latentie, niet op de ruimte die door de elastische pool wordt gebruikt.
• Als u wilt bepalen of een database PFS-opslag gebruikt, voert u de volgende query uit in de context van de database. Als de waarde in de kolom AccountType is PremiumFileStorage of PremiumFileStorage-ZRS, gebruikt de database PFS-opslag.

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

Notitie

• De zoneredundante eigenschap blijft standaard hetzelfde bij het schalen van één database van de Bedrijfskritiek naar de laag Algemeen gebruik.
• Latentie voor de schaalbewerking wanneer zoneredundantie wordt gewijzigd voor een individuele database voor algemeen gebruik, is evenredig met de grootte van de database.

Tip

Als u actieve bewerkingen wilt bewaken, raadpleegt u: Bewerkingen beheren met behulp van de SQL REST API, Bewerkingen beheren met CLI, Bewerkingen bewaken met behulp van T-SQL en deze twee PowerShell-opdrachten: Get-AzSqlDatabaseActivity en Stop-AzSqlDatabaseActivity.

Wijzigingen in schalen controleren of annuleren

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

Azure-portal

Zoek op de overzichtspagina van de SQL-database naar de banner die aangeeft dat er een schaalbewerking wordt uitgevoerd en selecteer de koppeling Meer weergeven voor de implementatie die wordt uitgevoerd.

Selecteer Op de resulterende pagina Lopende bewerkingen de optie Deze bewerking annuleren.

PowerShell

Als u de PowerShell-opdrachten op een computer wilt aanroepen, moet Az-pakketversie 9.7.0 of een nieuwere versie lokaal worden geïnstalleerd. U kunt ook de Azure Cloud Shell gebruiken om Azure PowerShell uit te voeren op shell.azure.com.

Meld u eerst aan bij Azure en stel de juiste context in voor uw abonnement:

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

Gebruik Get-AzSqlDatabaseActivity om bewerkingen op een database te bewaken, inclusief schaalbewerkingen. Het volgende voorbeeld retourneert een OperationId voor elke bewerking die momenteel wordt uitgevoerd.

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

Als u een asynchrone bewerking zoals een databaseschaal wilt annuleren, identificeert u de bewerking en gebruikt u Stop-AzSqlDatabaseActivity met een specifieke OperationId, zoals in het volgende voorbeeld.

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

Azure-CLI

Gebruik vanuit een Cloud Shell-terminal de volgende voorbeeldopdracht om bewerkingen te identificeren die momenteel worden uitgevoerd. Stel vanuit een Cloud Shell-terminal de $resourceGroupNamevariabelen in $serverNameen $databaseName voer vervolgens de volgende opdracht uit:

$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

Als u een asynchrone bewerking zoals een databaseschaal wilt stoppen, stelt u vanuit een Cloud Shell-terminal de $resourceGroupName, $serverNameen $databaseName variabelen in en voert u de volgende opdracht uit:

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

Belangrijk

In sommige gevallen moet u mogelijk een database verkleinen om ongebruikte ruimte vrij te maken. Zie Bestandsruimte beheren in Azure SQL Database voor meer informatie.

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.

Belangrijk

In sommige gevallen moet u mogelijk een database verkleinen om ongebruikte ruimte vrij te maken. Zie Bestandsruimte beheren in Azure SQL Database voor meer informatie.

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.