Resources van een individuele database schalen in Azure SQL Database

In dit artikel wordt beschreven hoe u de reken- en opslagbronnen die beschikbaar zijn voor een Azure SQL Database in de inrichtende rekenlaag kunt schalen. De serverloze rekenlaag biedt ook automatische rekenkracht en facturen per seconde voor het gebruikte rekenmodel.

Nadat u in eerste instantie het aantal vCores of DTUs hebt kiest, kunt u één 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

Bij het wijzigen van de servicelaag of rekengrootte moet de service de volgende stappen uitvoeren:

1. Maak een nieuw reken-exemplaar voor de database.

   Er wordt een nieuw rekenmodel gemaakt met de aangevraagde servicelaag en rekenkracht. Voor sommige combinaties van wijzigingen in de servicelaag en rekengrootte moet een replica van de database worden gemaakt in het nieuwe rekenexemplaar. Dit omvat het kopiëren van gegevens en kan een grote invloed hebben op de algehele latentie. Hoe dan ook, de database blijft online tijdens deze stap en verbindingen worden nog steeds omgeleid naar de database in de oorspronkelijke reken-instantie.

2. Schakel de routering van verbindingen naar een nieuw reken-exemplaar over.

   Bestaande verbindingen met de database in het oorspronkelijke reken exemplaar worden verwijderd. Nieuwe verbindingen worden tot stand gebracht met de database in de nieuwe reken-instantie. Voor sommige combinaties van wijzigingen in de servicelaag en de rekengrootte worden databasebestanden losgekoppeld en opnieuw vastgemaakt tijdens de switch. Hoe dan ook, de switch kan leiden tot een korte serviceonderbreking wanneer de database doorgaans minder dan 30 seconden en vaak slechts een paar seconden niet beschikbaar is. Als er langlopende transacties worden uitgevoerd wanneer verbindingen worden afgebroken, kan de duur van deze stap langer duren om afgebroken transacties te herstellen. Accelerated Database Recovery kunt de impact van het afbreken van langlopende transacties verminderen.

Latentie

De geschatte latentie voor het wijzigen van de servicelaag, het schalen van de rekengrootte van een individuele 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 annuleren

Een wijziging in de servicelaag of herschalen van rekenkracht kan worden geannuleerd.

Azure Portal

Navigeer op de overzichtsblade van de database naar Meldingen en klik op de tegel die aangeeft dat er een bewerking wordt uitgevoerd:

Klik vervolgens op de knop met het label Deze bewerking annuleren.

PowerShell

Stel vanaf een PowerShell-opdrachtprompt $resourceGroupName de , en in en voer de volgende opdracht $serverName $databaseName uit:

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

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 (maxsize) opgeeft.
• Als u een database wilt downgraden, moet de gebruikte databaseruimte kleiner zijn dan de maximaal toegestane grootte van de doelservicelaag en rekenkracht.
• Bij het downgraden van Premium naar de Standard-laag zijn extra opslagkosten van toepassing als beide (1) de maximale grootte van de database worden ondersteund in de doelrekengrootte en (2) de maximale grootte groter is dan de inbegrepen opslaggrootte van de doelrekengrootte. Als een P1-database met een maximale grootte van 500 GB bijvoorbeeld wordt ge downsized naar S3, zijn er extra opslagkosten van toepassing omdat S3 een maximale grootte van 1 TB ondersteunt en de inbegrepen opslag slechts 250 GB is. De extra opslagruimte is dus 500 GB – 250 GB = 250 GB. Zie prijzen voor Azure SQL Database voor prijzen van extra opslag. Als de werkelijke hoeveelheid ruimte kleiner is dan de inbegrepen opslagruimte, kunnen deze extra kosten worden vermeden door de maximale grootte van de database te verkleinen tot de inbegrepen hoeveelheid.
• Wanneer u een database bijwerkt met geo-replicatie ingeschakeld, moet u de secundaire databases bijwerken naar de gewenste servicelaag en rekenkracht voordat u de primaire database bijwerkt (algemene richtlijnen voor de beste prestaties). Bij een upgrade naar een andere editie is het een vereiste dat de secundaire database eerst wordt bijgewerkt.
• Wanneer u een database downgradet met geo-replicatie ingeschakeld, downgradet u de primaire databases naar de gewenste servicelaag en rekenkracht voordat u de secundaire database downgradet (algemene richtlijnen voor de beste prestaties). Wanneer u downgradet naar een andere editie, is het een vereiste dat de primaire database eerst wordt gedowngraded.
• De mogelijkheden om de service te herstellen verschillen voor de verschillende servicelagen. Als u downgradet naar de basic-laag, is er een lagere bewaarperiode voor back-ups. Zie Azure SQL Database Backups ( Back-ups).
• De nieuwe eigenschappen voor de database worden pas toegepast wanneer de wijzigingen zijn voltooid.
• Wanneer het kopiëren van gegevens vereist is voor het schalen van een database (zie Latentie) bij het wijzigen van de servicelaag, kan een hoog resourcegebruik dat gelijktijdig is met de schaalbewerking leiden tot langere schaaltijden. Met Accelerated Database Recovery (ADR)is het terugdraaien van langlopende transacties geen belangrijke bron van vertraging, maar kan een hoog gelijktijdig resourcegebruik leiden tot minder reken-, opslag- en netwerkbandbreedteresources voor schalen, met name bij kleinere rekenkracht.

Billing

U wordt gefactureerd voor elk uur dat een database bestaat met de hoogste servicelaag en rekenkracht die in dat uur zijn toegepast, ongeacht het gebruik of of de database minder dan een uur actief was. Als u bijvoorbeeld een individuele database maakt en deze vijf minuten later verwijdert, worden kosten voor één databaseuur op uw factuur weergegeven.

Opslaggrootte wijzigen

Aankoopmodel op basis van vCore

• Storage kunnen worden ingericht tot de maximale grootte van de gegevensopslag met stappen van 1 GB. De minimaal configureerbare gegevensopslag is 1 GB. Zie de pagina's met documentatie over resourcelimieten voor individuele databases met behulp van het vCore-aankoopmodel en Resourcelimieten voor individuele databases met behulp van het DTU-aankoopmodel voor maximale grootte van gegevensopslag in elke servicedoelstelling.
• 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 dit een veelvoud van 1 GB (1073741824 bytes).
• De hoeveelheid gegevens die kan worden opgeslagen in de gegevensbestanden van een database, wordt beperkt door de maximale grootte van de geconfigureerde gegevensopslag. Naast deze opslag wijst Azure SQL Database automatisch 30% meer opslagruimte toe die moet worden gebruikt voor het transactielogboek.
• 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 opslagprijs voor één database of elastische pool is de som van de opslagbedragen voor gegevensopslag en transactielogboek, vermenigvuldigd met de opslageenheidprijs van de servicelaag. De kosten van tempdb zijn opgenomen in de prijs. Zie Prijzen voor Azure SQL Database meer informatie over de opslagprijs.

Aankoopmodel op basis van DTU

• De DTU-prijs voor een individuele database omvat een bepaalde hoeveelheid opslag, zonder extra kosten. Extra opslag buiten het inbegrepen bedrag kan worden ingericht tegen extra kosten tot aan de maximale groottelimiet in stappen van 250 GB tot 1 TB en vervolgens in stappen van 256 GB boven 1 TB. Zie Individuele database: Storage en rekengrootten voor inbegrepen opslagbedragen en maximale groottelimieten.
• 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 CLIof de REST API.
• De prijs van extra opslag voor een individuele database is de extra opslagruimte vermenigvuldigd met de extra opslageenheidprijs van de servicelaag. Zie prijzen voor meer informatie over de prijs van Azure SQL Database opslag.

Geo-gerepliceerde database

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 aan opslag in de Premium-laag is momenteel beschikbaar in alle regio's, behalve: 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 groter dan 1 TB, kan deze alleen worden hersteld of gekopieerd naar een P11- of P15-database. De database kan vervolgens opnieuw worden geschaald naar een andere rekenkracht, mits de hoeveelheid ruimte die is toegewezen op het moment van de herschaalbewerking de maximale grootte van de nieuwe rekenkracht niet overschrijdt.
• Voor actieve geo-replicatiescenario's:
  • Een geo-replicatierelatie instellen: als de primaire database P11 of P15 is, moeten de secundaire database(s) ook P11 of P15 zijn. Een lagere rekenkracht wordt geweigerd als secondaries omdat ze niet meer dan 1 TB kunnen ondersteunen.
  • Een upgrade uitvoeren van de primaire database 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 activeert. Beide upgrades moeten zijn geslaagd om de wijziging op de primaire van kracht te laten worden. Regiobeperkingen voor de optie van meer dan 1 TB zijn van toepassing. Als de secundaire zich in een regio met geen ondersteuning voor meer dan 1 TB, wordt de primaire niet bijgewerkt.
• Het gebruik Import/Export voor het laden van P11-/P15-databases met meer dan 1 TB wordt niet ondersteund. Gebruik SqlPackage.exe om gegevens te importeren en te exporteren.

Volgende stappen

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