Ridimensionare le risorse di database singoli nel database SQL di Azure

Si applica a:database SQL di Azure

Questo articolo descrive come ridimensionare le risorse di calcolo e di archiviazione disponibili per un database SQL di Azure nel livello di calcolo con provisioning. In alternativa, il livello di elaborazione serverless fornisce la scalabilità automatica di calcolo e le fatture al secondo per le risorse di calcolo usate.

Dopo avere inizialmente selezionato il numero di vCore o DTU, è possibile aumentare o diminuire dinamicamente le dimensioni di un database singolo in base all'effettiva esperienza tramite:

• Transact-SQL
• Azure portal
• PowerShell
• Interfaccia della riga di comando di Azure
• REST API

Impatto

La modifica del livello di servizio o delle dimensioni di calcolo comporta principalmente l'esecuzione dei seguenti passaggi:

1. Creare una nuova istanza di ambiente di calcolo per il database.

   Viene creata una nuova istanza di ambiente di calcolo con il livello di servizio e le dimensioni di calcolo richieste. Per alcune combinazioni di modifiche al livello di servizio e alle dimensioni di calcolo, è necessario creare una replica del database nella nuova istanza di ambiente di calcolo, che comporta la copia dei dati e può influenzare notevolmente la latenza complessiva. Indipendentemente da ciò, i database rimangono online durante questo passaggio e le connessioni continuino a essere indirizzate ai database nell'istanza di ambiente di calcolo originale.

2. Cambiare il routing delle connessioni a una nuova istanza di ambiente di calcolo.

   Le connessioni esistenti al database nell'istanza di ambiente di calcolo originale vengono eliminate. Tutte le nuove connessioni vengono stabilite al database nella nuova istanza di ambiente di calcolo. Per alcune combinazioni di modifiche al livello di servizio e alle dimensioni di calcolo, i file di database vengono scollegati e ricollegati durante la commutazione. Indipendentemente da ciò, la commutazione può causare una breve interruzione del servizio quando il database non è disponibile in genere per meno di 30 secondi e spesso solo per pochi secondi. Se sono in esecuzione transazioni a esecuzione prolungata quando vengono eliminate le connessioni, la durata di questo passaggio potrebbe richiedere più tempo per recuperare le transazioni interrotte. Il ripristino accelerato del database può ridurre l'impatto dell'interruzione delle transazioni di lunga durata.

Latenza

La latenza stimata per modificare il livello di servizio, dimensionare le dimensioni di calcolo di un database singolo o di un pool elastico, spostare un database all'interno/esterno di un pool elastico o spostare un database tra pool elastici è parametrizzato come segue:

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

Monitorare o annullare le modifiche di ridimensionamento

Un'operazione di modifica di livello di servizio o di ridimensionamento del calcolo può essere monitorata e annullata.

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

Autorizzazioni

Per ridimensionare i database tramite Transact-SQL: viene usato ALTER DATABASE. Per dimensionare un database, un account di accesso deve essere l'amministratore del server (creato durante il provisioning del server logico di database SQL di Azure), l'amministratore Microsoft Entra del server, un membro del ruolo del database dbmanager in master, un membro del ruolo del database db_owner nel database corrente o dbo del database. Per altre informazioni, vedere ALTER DATABASE.

Per dimensionare i database tramite il portale di Azure, PowerShell, l'interfaccia della riga di comando di Azure o l'API REST: sono necessarie le autorizzazioni di Controllo degli accessi in base al ruolo di Azure, in particolare i ruoli Controllo degli accessi in base al ruolo di Azure Contributore, Contributore Database SQL o Contributore SQL Server. Per altre informazioni, vedere Controllo degli accessi in base al ruolo di Azure: ruoli predefiniti.

Considerazioni aggiuntive

• Se si esegue l'aggiornamento a un livello di servizio o a dimensioni di calcolo superiori, le dimensioni massime del database non aumentano a meno che non si specifichino esplicitamente dimensioni più elevate (massime).
• Per effettuare il downgrade di un database, la relativa quantità di spazio usato deve essere inferiore alle dimensioni massime consentite per il livello di servizio e le dimensioni di calcolo di destinazione.
• Quando si effettua il downgrade dal livello Premium al livello Standard, viene applicato un costo per le risorse di archiviazione extra se (1) le dimensioni massime del database sono supportate nelle dimensioni di calcolo di destinazione e (2) le dimensioni massime superano lo spazio di archiviazione incluso delle dimensioni di calcolo di destinazione. Se ad esempio un database P1 con una dimensione massima di 500 GB viene ridotto a S3, viene applicato un costo per le risorse di archiviazione extra, poiché S3 supporta una dimensione massima di 1 TB e lo spazio di archiviazione incluso è solo di 250 GB. Lo spazio di archiviazione extra è quindi 500 GB - 250 GB = 250 GB. Per i prezzi delle risorse di archiviazione extra, vedere Prezzi di database SQL di Azure. Se la quantità effettiva di spazio usato è inferiore allo spazio di archiviazione incluso, questo costo aggiuntivo può essere evitato riducendo le dimensioni massime del database fino allo spazio incluso.
• Quando si aggiorna un database con la replica geografica abilitata, aggiornare i database secondari al livello di servizio e alle dimensioni di calcolo desiderati prima di aggiornare il database primario (indicazione generale per ottenere prestazioni ottimali). Durante l'aggiornamento a un'edizione diversa, è obbligatorio aggiornare per primo il database secondario.
• Quando si effettua il downgrade di un database con la replica geografica abilitata, eseguire il downgrade dei database primari al livello di servizio e alle dimensioni di calcolo desiderati prima del downgrade del database secondario (indicazione generale per ottenere prestazioni ottimali). Al momento del downgrade a un'edizione diversa, è obbligatorio effettuare il downgrade partendo dal database primario.
• Le offerte per il ripristino del servizio sono diverse per i vari livelli di servizio. In caso di downgrade al livello Basic, il periodo di conservazione dei backup sarà inferiore. Vedere Backup automatici in database SQL di Azure.
• Le nuove proprietà del database non vengono applicate finché non sono state completate le modifiche.
• Quando si richiede di copiare i dati per dimensionare un database (vedere Latenza) durante la modifica del livello di servizio, un utilizzo elevato delle risorse in contemporanea con l'operazione di ridimensionamento può prolungare i tempi. Con il ripristino accelerato del database , il rollback delle transazioni prolungate non è una fonte significativa di ritardo, ma l'elevato utilizzo simultaneo delle risorse potrebbe lasciare meno risorse di calcolo, archiviazione e larghezza di banda di rete per lo scaling, in particolare per dimensioni di calcolo più piccole.

Fatturazione

Viene fatturata ogni ora per cui un database esiste usando il livello di servizio più elevato e le dimensioni di calcolo applicati in quell'ora, indipendentemente dall'uso o dal fatto che il database sia stato attivo per meno di un'ora. Ad esempio, se si crea un database singolo che viene eliminato cinque minuti dopo, in fattura viene riportato l'addebito relativo a un'ora di database.

modifica delle dimensioni di archiviazione

Modello di acquisto basato su vCore

• Il provisioning dell'archiviazione può essere effettuato fino al limite massimo delle dimensioni dell'archiviazione dei dati tramite incrementi di 1 GB. Lo spazio di archiviazione dei dati minimo configurabile è 1 GB. Per i limiti di dimensione massima dell'archiviazione dei dati in ogni obiettivo di servizio, vedere le pagine della documentazione relativa ai limiti delle risorse per i database singoli tramite il modello di acquisto vCore e i limiti delle risorse per i database singoli tramite il modello di acquisto DTU.

• Il provisioning dell'archiviazione dati per un database singolo può essere effettato aumentandone o diminuendone le dimensioni massime tramite il portale di Azure, Transact-SQL, PowerShell, l'interfaccia della riga di comando di Azure o l'API REST. Se il valore della dimensione massima viene specificato in byte, deve essere un multiplo di 1 GB (1.073.741.824 byte).

• La quantità di dati che è possibile archiviare nei file di dati di un database è limitata dalle dimensioni massime di archiviazione dati configurate. Oltre a tale archiviazione, il database SQL di Azure aggiunge automaticamente il 30% di spazio di archiviazione in più da usare per il log delle transazioni. Il prezzo dell'archiviazione per un database singolo o un pool elastico corrisponde alla somma delle dimensioni di archiviazione dei dati e degli spazi di archiviazione dei log delle transazioni moltiplicata per il prezzo unitario dell'archiviazione del livello di servizio. Ad esempio, se l'archiviazione dati è impostata su 10 GB, l'archiviazione aggiuntiva del log delle transazioni è di 10 GB * 30% = 3 GB e la quantità totale di spazio di archiviazione fatturabile è di 10 GB + 3 GB = 13 GB.

  Nota

  Le dimensioni massime del file di log delle transazioni vengono gestite automaticamente e in alcuni casi possono essere superiori al 30% delle dimensioni massime di archiviazione dei dati. Questo non aumenta il prezzo di archiviazione per il database.

• Il database SQL di Azure alloca automaticamente 32 GB per vCore per il database tempdb. tempdb si trova nell'archiviazione SSD locale in tutti i livelli di servizio. Il costo di tempdb è incluso nel prezzo di un database singolo o di un pool elastico.

• Per informazioni dettagliate sul prezzo dell'archiviazione, vedere Prezzi di database SQL di Azure.

Modello di acquisto basato su DTU

• Il prezzo DTU per un singolo database include una determinata quantità di risorse di archiviazione senza costi aggiuntivi. Le risorse di archiviazione extra rispetto alla quantità inclusa possono essere sottoposte a provisioning per un costo aggiuntivo fino alla quantità massima in incrementi di 250 GB fino a 1 TB e quindi in incrementi di 256 GB oltre 1 TB. Per gli spazi di archiviazione inclusi e i limiti di dimensioni massime, vedere Database singolo: dimensioni di archiviazione e dimensioni di calcolo.
• Il provisioning delle risorse di archiviazione extra per un database singolo può essere effettuato aumentandone le dimensioni massime tramite il portale di Azure, Transact-SQL, PowerShell, l'interfaccia della riga di comando di Azure o l'API REST.
• Il prezzo delle risorse di archiviazione extra per un singolo database corrisponde allo spazio di archiviazione extra moltiplicato per il prezzo unitario del livello di servizio. Per informazioni dettagliate sul prezzo delle risorse di archiviazione extra, vedere Prezzi di database SQL di Azure.

Database con replica geografica

Per modificare le dimensioni di un database secondario replicato, modificare le dimensioni del database primario. Questa modifica verrà quindi replicata e implementata anche nel database secondario.

Vincoli P11 e P15 in caso di dimensione massima maggiore di 1 TB

Nel livello Premium è attualmente disponibile più di 1 TB di spazio di archiviazione in tutte le aree ad eccezione delle seguenti: Cina orientale, Cina settentrionale, Germania centrale, Germania nord-orientale. In queste aree la quantità massima di spazio di archiviazione nel livello Premium è limitata a 1 TB. Ai database P11 e P15 con dimensioni massime maggiori di 1 TB vengono applicate le considerazioni e le limitazioni seguenti:

• Se le dimensioni massime per un database P11 o P15 sono state impostate su un valore maggiore di 1 TB, il database può essere ripristinato o copiato solo in un database P11 o P15. Successivamente, il database può essere ridimensionato a una dimensione di calcolo diversa, a condizione che la quantità di spazio allocata al momento dell'operazione di ridimensionamento non superi i limiti di dimensioni massime delle nuove dimensioni di calcolo.
• Per gli scenari di replica geografica attiva:
  • Configurazione di una relazione di replica geografica: se il database primario è P11 o P15, anche i database secondari devono essere P11 o P15. Dimensioni di calcolo inferiori vengono rifiutate come repliche secondarie perché non sono in grado di supportare più di 1 TB.
  • Aggiornamento del database primario in una relazione di replica geografica: portando a oltre 1 TB le dimensioni massime di un database primario, viene attivata la stessa modifica nel database secondario. Entrambi gli aggiornamenti devono avere esito positivo per applicare la modifica al database primario. Vengono applicate limitazioni per l'opzione da oltre 1 TB. Se il database secondario si trova in un'area che non supporta l'opzione da oltre 1 TB, il database primario non viene aggiornato.
• Il servizio di importazione/esportazione per caricare i database P11 o P15 con oltre 1 TB non è supportato. Usare SqlPackage per importare ed esportare i dati.

Contenuto correlato

• Limiti di risorse per i database singoli usando il modello di acquisto vCore
• Limiti delle risorse per database singoli usando il modello di acquisto DTU - Database SQL di Azure