Resources voor elastische pools schalen in Azure SQL database

Van toepassing op: Azure SQL Database

In dit artikel wordt beschreven hoe u de reken- en opslagresources kunt schalen die beschikbaar zijn voor elastische pools en pooldatabases in Azure SQL Database.

Rekenresources (vCores of DTU's) wijzigen

Nadat u in eerste instantie het aantal vCores of eDTU's hebt opgehaald, kunt u een elastische pool dynamisch omhoog of omlaag schalen op basis van de werkelijke ervaring met behulp van een van de onderstaande methoden:

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

Gevolgen van het wijzigen van de servicelaag of het opnieuw schalen van de rekenkracht

Het wijzigen van de servicelaag of rekenkracht van een elastische pool volgt een vergelijkbaar patroon als voor individuele databases en omvat voornamelijk de service die de volgende stappen uitvoert:

1. Een nieuw rekenproces maken voor de elastische pool

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

2. Schakelen tussen routering van verbindingen naar een nieuw rekenproces

   Bestaande verbindingen met de databases in het oorspronkelijke rekenproces worden verwijderd. Nieuwe verbindingen worden tot stand gebracht met de databases in het nieuwe rekenproces. Voor sommige combinaties van wijzigingen in de servicelaag en rekengrootte worden databasebestanden losgekoppeld en opnieuw gekoppeld tijdens de switch. Hoe dan ook, de switch kan resulteren in een korte serviceonderbreking wanneer databases over het algemeen minder dan 30 seconden niet beschikbaar zijn en vaak slechts een paar seconden. Als er actieve langlopende transacties zijn 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.

Latentie van het wijzigen van de servicelaag of het opnieuw schalen van de rekenkracht

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 elastische pools	Naar Basic, Standard, elastische pool voor algemeen gebruik	Naar Premium Bedrijfskritiek elastische pool	Naar elastische Hyperscale-pool
Van basic, standard, elastische pool voor algemeen gebruik	Proportioneel aan 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.	N.v.v.: databases moeten afzonderlijk worden toegevoegd aan elastische Hyperscale-pools. Latentie schalen per database die wordt beschreven in resources van één database schalen.
Vanuit Premium Bedrijfskritiek elastische pool	• 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.	N.v.v.: databases moeten afzonderlijk worden toegevoegd aan elastische Hyperscale-pools. Latentie schalen per database die wordt beschreven in resources van één database schalen.
Van elastische Hyperscale-pool	N.v.t.	N.v.t.	• Constante tijdlatentie onafhankelijk van de gebruikte ruimte. • Doorgaans minder dan 2 minuten.

Notitie

• Wanneer u de servicelaag wijzigt of rekenkracht wijzigt voor een niet-Hyperscale elastische pool, moet de som van de ruimte die wordt gebruikt voor alle databases in de pool, worden gebruikt om de schatting te berekenen. Latentie voor elastische Hyperscale-pools is onafhankelijk van de gebruikte ruimte.
• Voor elastische pools voor Standaard en Algemeen gebruik is de latentie van het verplaatsen van een database in/uit een elastische pool of tussen elastische pools evenredig met de grootte van de database als de elastische pool gebruikmaakt van PFS-opslag (Premium File Share). Als u wilt bepalen of een pool PFS-opslag gebruikt, voert u de volgende query uit in de context van een database in de pool. Als de waarde in de kolom AccountType is PremiumFileStorage of PremiumFileStorage-ZRS, gebruikt de pool 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 een elastische pool van de Bedrijfskritiek naar de laag Algemeen gebruik.
• Latentie voor de schaalbewerking wanneer zoneredundantie wordt gewijzigd voor een elastische pool voor algemeen gebruik, is evenredig met de grootte van de database.
• Het wijzigen van een bestaande niet-Hyperscale elastische pool in de Hyperscale-editie wordt niet ondersteund. Zie elastische Hyperscale-pools voor meer informatie. In plaats daarvan moeten databases afzonderlijk worden toegevoegd aan elastische Hyperscale-pools.
• Het wijzigen van de editie van een elastische Hyperscale-pool in een niet-Hyperscale-editie wordt niet ondersteund. Zie elastische Hyperscale-pools voor meer informatie.

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-AzSqlElasticPoolActivity en Stop-AzSqlElasticPoolActivity.

Aanvullende overwegingen bij het wijzigen van de servicelaag of het opnieuw schalen van de rekenkracht

• Wanneer u vCores of eDTU's voor een elastische pool verlaagt, moet de gebruikte ruimte voor de pool kleiner zijn dan de maximale gegevensgroottelimiet van de doelservicelaag en de rekenkracht van de pool.
• Wanneer u eDTU's voor een elastische pool verhoogt, kunnen extra opslagkosten van toepassing zijn als:
  • De maximale gegevensgrootte van de pool wordt ondersteund door de doelgroep en
  • De maximale gegevensgrootte van de pool overschrijdt de inbegrepen opslaghoeveelheid van de doelgroep.
• Als een standardpool van 100 eDTU met een maximale gegevensgrootte van 100 GB bijvoorbeeld wordt verkleind naar een standardpool van 50 eDTU, zijn er extra opslagkosten van toepassing omdat de doelgroep een maximale gegevensgrootte van 100 GB ondersteunt en de inbegrepen opslagruimte slechts 50 GB is. De extra opslagruimte is dus 100 GB – 50 GB = 50 GB. Zie de prijzen van SQL Database 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 gegevensgrootte te verlagen tot het inbegrepen bedrag.

Facturering tijdens het aanpassen van de schaal

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.

Elastische pool opslaggrootte wijzigen

De opslaggrootte (maximale gegevensgrootte) voor de elastische pool kan worden opgegeven met behulp van Azure Portal, PowerShell, de Azure CLI of de REST API. Wanneer u de maximale gegevensgrootte van de elastische pool verhoogt, mag de opgegeven waarde niet groter zijn dan de maximale gegevensgroottelimiet van de servicedoelstelling van de pool. Wanneer u de maximale gegevensgrootte verlaagt, moet de opgegeven nieuwe waarde gelijk zijn aan of groter zijn dan de som van de ruimte die is toegewezen aan alle databases in de pool.

Belangrijk

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

Aankoopmodel op basis van vCore

• De opslaggrootte (maximale gegevensgrootte) voor elastische pools in de lagen Algemeen gebruik of Bedrijfskritiek kunnen worden opgegeven tot de maximale gegevensgroottelimieten die zijn opgegeven in Resourcelimieten voor elastische pools met behulp van het vCore-aankoopmodel. De maximale gegevensgrootte voor de elastische pool kan worden verhoogd of verlaagd in veelvouden van 1 GB.
• De prijs van opslag voor een elastische pool is de maximale gegevensgrootte die is opgegeven, vermenigvuldigd met de prijs van de opslageenheid van de servicelaag. Zie prijzen voor SQL Database voor meer informatie over opslagprijzen.

Belangrijk

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

Aankoopmodel op basis van DTU

• De eDTU-prijs voor een elastische pool omvat een bepaalde hoeveelheid opslag zonder extra kosten. Extra gegevensopslag buiten het inbegrepen bedrag kan worden ingericht voor extra kosten tot de maximale gegevensgroottelimiet die overeenkomt met de ingerichte eDTU's. Zie Resourceslimieten voor elastische pools met behulp van het DTU-aankoopmodel voor opgenomen opslagbedragen en maximale gegevensgroottelimieten.
• De prijs van extra opslagruimte voor een elastische pool is de extra opslaghoeveelheid vermenigvuldigd met de prijs van de extra opslageenheid van de servicelaag. Zie prijzen voor SQL Database voor meer informatie over de prijs van extra opslag.
• Geldige waarden voor de maximale gegevensgrootte voor een elastische pool in de Standard- of Premium-laag kunnen een van de volgende waarden zijn: 50 GB, 100 GB, 150 GB, 200 GB, 250 GB, 300 GB, 400 GB, 500 GB, 750 GB, 800 GB, 1024 GB, 1200 GB, 1280 GB, 1536 GB, 1600 GB, 1792 GB, 2000 GB, 2048 GB, 2304 GB, 2500 GB, 2560 GB, 2816 GB, 3000 GB, 3072 GB, 3328 GB, 3584 GB, 3840 GB, 4096 GB. De opgegeven maximale gegevensgrootte mag niet groter zijn dan de maximale gegevensgrootte die is opgegeven voor de ingerichte eDTU's.

Belangrijk

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

Wijzigingen in schalen controleren of annuleren

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

Azure-portal

Ga op de overzichtspagina van de elastische SQL-pool naar Meldingen en selecteer de tegel die aangeeft dat er een lopende bewerking is:

Selecteer Annuleren op de resulterende implementatiepagina.

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-AzSqlElasticPoolActivity om bewerkingen in een elastische pool te bewaken, inclusief schaalbewerkingen. Het volgende voorbeeld retourneert een OperationId voor elke bewerking die momenteel wordt uitgevoerd.

Get-AzSqlElasticPoolActivity -ResourceGroupName "ResourceGroup01" -ElasticPoolName "Pool01" ServerName "Server01" 

Als u een asynchrone beheerbewerking voor elastische pools wilt annuleren, zoals een elastische poolschaal, identificeert u de bewerking en gebruikt u Vervolgens Stop-AzSqlElasticPoolActivity met een specifieke OperationId, zoals in het volgende voorbeeld.

Stop-AzSqlElasticPoolActivity -ResourceGroupName "ResourceGroup01" -ElasticPoolName "Pool01" -ServerName "Server01" -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 $elasticPoolName voer vervolgens de volgende opdracht uit:

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$elasticPoolName = "<elastic pool name>"
az sql elastic-pool op list --resource-group $resourceGroupName --server $serverName --elastic-pool $elasticPoolName --query "[?state=='IN_PROGRESS'].name" --out tsv

Als u een asynchrone elastische poolbeheerbewerking, zoals een schaalbewerking, wilt stoppen vanuit een Cloud Shell-terminal, stelt u de $resourceGroupName, $serverNameen $elasticPoolName variabelen in en voert u vervolgens de volgende opdracht uit:

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$elasticPoolName = "<elastic pool name>"
$operationId = (az sql elastic-pool op list --resource-group $resourceGroupName --server $serverName --elastic-pool $elasticPoolName --query "[?state=='IN_PROGRESS'].name" --out tsv)
if (-not [string]::IsNullOrEmpty($operationName)) {
    (az sql elastic-pool op cancel --resource-group $resourceGroupName --server $serverName --elastic-pool $elasticPoolName --name $operationId)
        "Operation " + $operationName + " has been canceled"
}
else {
    "No management operation on the elastic pool found"
}

Bevoegdheden

Als u een elastische pool 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.

Gerelateerde inhoud

Zie resourcelimieten op basis van SQL Database vCore, elastische pools en resourcelimieten op basis van SQL Database DTU, elastische pools voor algemene resourcelimieten.