Delen via

Resources voor elastische pools schalen in Azure SQL Database

  • Artikel

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.

Rekenbronnen (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:

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. Desondanks blijven de databases online tijdens deze stap, en blijven verbindingen naar de databases in de oorspronkelijke rekeninstantie worden geleid.

  2. Routering van verbindingen omleiden naar een nieuwe compute-instantie

    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 impact van het afbreken van langlopende transacties verminderen.

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, elastische pool met bedrijfskritiek Naar een 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.		 Niet van toepassing – databases moeten afzonderlijk worden toegevoegd aan Hyperscale elastische pools . Schaallatentie per database zoals gedocumenteerd in Schaal de resources van één database.
Van Premium, bedrijfskritieke 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.t. - databases moeten afzonderlijk worden toegevoegd aan Hyperscale elastische pools. De latentie per database, zoals gedocumenteerd in , wordt geschaald volgens de resources voor een afzonderlijke database.
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 of de rekencapaciteit van een niet-Hyperscale elastische pool wijzigt, moet de schatting worden berekend op basis van de som van de gebruikte ruimte van alle databases in de pool. De schaal latentie voor elastische Hyperscale-pools is onafhankelijk van de hoeveelheid gebruikte ruimte.
  • Voor elastische pools van Standard 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 Premium-bestandsshare (PFS-) opslag. 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 PremiumFileStorage of PremiumFileStorage-ZRSis, 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 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 voor meer informatie Hyperscale elastische pools. In plaats daarvan moeten databases afzonderlijk worden toegevoegd aan elastische Hyperscale-pools.
  • Het wijzigen van de editie van een Hyperscale-elastische pool naar een niet-Hyperscale-editie wordt niet ondersteund. Voor meer informatie, zie Hyperscale elastische pools.

Tip

Hier volgt hoe u lopende bewerkingen kunt monitoren: Beheer bewerkingen met behulp van de SQL REST API, Beheer bewerkingen met CLI, Monitor bewerkingen met T-SQL en de volgende 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 SQL Database prijzenvoor de prijs van 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.

Opslaggrootte voor elastische pools wijzigen

De opslaggrootte (maximale gegevensgrootte) voor de elastische pool kan worden opgegeven met behulp van de Azure Portal, PowerShell-, de Azure CLI-of de REST API-. Wanneer u de maximale gegevensgrootte van de elastische pool verhoogt, kan 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 voor databases beheren in Azure SQL Databasevoor meer informatie.

Aankoopmodel op basis van vCore

  • De opslaggrootte (maximale gegevensgrootte) voor elastische pools in de lagen Algemeen gebruik of Bedrijfskritiek kan 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 SQL Database-prijzenvoor details over opslagprijzen.

Belangrijk

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

Aankoopmodel op basis van DTU

  • De eDTU-prijs voor een elastische pool omvat een bepaalde hoeveelheid opslagruimte 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 Resources-limieten voor elastische pools met behulp van het DTU-aankoopmodelvoor 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. Voor meer informatie over de prijzen van extra opslagruimte, zie prijzen voor SQL Database.
  • Geldige waarden voor de maximale gegevensgrootte voor een elastische pool in de Standard- of Premium-laag kunnen een van deze waarden zijn: 50 GB, 100 GB, 150 GB, 200 GB, 250 GB, 300 GB, 400 GB, 500 GB, 750 GB, 800 GB, 1.024 GB, 1.200 GB, 1.280 GB, 1.536 GB, 1.600 GB, 1.792 GB, 2.000 GB, 2048 GB, 2.304 GB, 2.500 GB, 2.560 GB, 2.816 GB, 3.000 GB, 3.072 GB, 3.328 GB, 3.584 GB, 3.840 GB, 4.096 GB. De opgegeven maximale gegevensgrootte kan 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 voor databases beheren in Azure SQL Databasevoor meer informatie.

Schaalwijzigingen controleren of annuleren

Een wijziging van een servicelaag of een rescaling operatie kan worden bewaakt en geannuleerd.

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

schermopname van Azure Portal van een lopende implementatie die wordt uitgevoerd.

Selecteer op de resulterende implementatie wordt uitgevoerd pagina Annuleren.

Machtigingen

Als u een elastische pool wilt schalen via de Azure-portal, PowerShell, Azure CLI of REST API, hebt u Azure RBAC-machtigingen nodig, met name de rol Inzender, SQL DB-inzender of de Azure RBAC-rol Inzender voor SQL Server. Zie Azure RBAC ingebouwde rollenvoor meer informatie.

Verwante inhoud