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

Importante

In alcune circostanze, può essere necessario compattare un database per recuperare spazio inutilizzato. Per altre informazioni, vedere Gestire lo spazio file nel database SQL di Azure.

Nota

Microsoft Entra ID era precedentemente conosciuto come Azure Active Directory (Azure AD).

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 a esecuzione prolungata.

Importante

Durante qualsiasi passaggio del flusso di lavoro non vengono persi dati. Assicurarsi di aver implementato una logica di ripetizione dei tentativi nelle applicazioni e nei componenti che usano il database SQL di Azure mentre il livello di servizio viene modificato.

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:

Latenza di ridimensionamento del database	A database singolo Basic, database singolo Standard (S0-S1)	A database singolo Standard (S2-S12), database singolo Per utilizzo generico, database in pool elastico Basic, database in pool elastico Standard, database in pool Per utilizzo generico	A database singolo Premium o database in pool, database singolo business critical o database in pool	A database singolo Hyperscale o un database in pool
Da database singolo Basic, database singolo Standard (S0-S1)	• Latenza temporale costante indipendentemente dallo spazio usato. • In genere, meno di 5 minuti.	• Latenza proporzionale allo spazio del database usato a causa della copia dei dati. • In genere, meno di 1 minuto per GB di spazio utilizzato.	• Latenza proporzionale allo spazio del database usato a causa della copia dei dati. • In genere, meno di 1 minuto per GB di spazio utilizzato.	• Latenza proporzionale allo spazio del database usato a causa della copia dei dati. • In genere, meno di 1 minuto per GB di spazio utilizzato.
Da database in pool basic, database singolo Standard (S2-S12), database in pool Standard, database singolo per utilizzo generico o database in pool	• Latenza proporzionale allo spazio del database usato a causa della copia dei dati. • In genere, meno di 1 minuto per GB di spazio utilizzato.	• Per i database singoli, la latenza temporale costante indipendentemente dallo spazio usato. • In genere, meno di 5 minuti per database singoli. • Per i pool elastici, proporzionale al numero di database.	• Latenza proporzionale allo spazio del database usato a causa della copia dei dati. • In genere, meno di 1 minuto per GB di spazio utilizzato.	• Latenza proporzionale allo spazio del database usato a causa della copia dei dati. • In genere, meno di 1 minuto per GB di spazio utilizzato.
Da database singolo Premium o database in pool, database singolo business critical o database in pool	• Latenza proporzionale allo spazio del database usato a causa della copia dei dati. • In genere, meno di 1 minuto per GB di spazio utilizzato.	• Latenza proporzionale allo spazio del database usato a causa della copia dei dati. • In genere, meno di 1 minuto per GB di spazio utilizzato.	• Latenza proporzionale allo spazio del database usato a causa della copia dei dati. • In genere, meno di 1 minuto per GB di spazio utilizzato.	• Latenza proporzionale allo spazio del database usato a causa della copia dei dati. • In genere, meno di 1 minuto per GB di spazio utilizzato.
Da database singolo Hyperscale o database in pool	N/D	Vedere Eseguire la migrazione inversa da Hyperscale per limitazioni e scenari supportati.	N/D	• Latenza temporale costante indipendentemente dallo spazio usato. • In genere, meno di 2 minuti.

Nota

• Inoltre, per i database Standard (S2-S12) e Per utilizzo generico, la latenza per lo spostamento di un database all'interno/esterno di un pool elastico o tra pool elastici sarà proporzionale alle dimensioni del database se il database usa l'archiviazione di condivisione di file Premium (PFS).
• Nel caso di spostamento di un database da/verso un pool elastico, solo lo spazio usato dal database influisce sulla latenza e non lo spazio usato dal pool elastico.
• Per determinare se un database usa l'archiviazione PFS, eseguire la query seguente nel contesto del database. Se il valore nella colonna AccountType è PremiumFileStorage o PremiumFileStorage-ZRS, il database usa l'archiviazione PFS.

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

Nota

• La proprietà con ridondanza della zona rimarrà identica per impostazione predefinita quando si ridimensiona un database singolo dal livello Business Critical al livello Per utilizzo generico.
• La latenza per l'operazione di ridimensionamento quando la ridondanza della zona viene modificata per un database singolo Per utilizzo generico è proporzionale alle dimensioni del database.

Suggerimento

Per monitorare le operazioni in corso, vedere: Gestire le operazioni tramite l'API REST SQL, Gestire le operazioni tramite l'interfaccia della riga di comando, Monitorare le operazioni tramite T-SQL e i due comandi PowerShell seguenti: Get-AzureRmSqlDatabaseActivity e Stop-AzureRmSqlDatabaseActivity.

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.

Azure portal

Nella pagina di Panoramica del database SQL, cercare il banner che indica che è in corso un'operazione di ridimensionamento e selezionare il link Visualizza altro per la distribuzione in corso.

Nella pagina Operazioni in corso risultante, selezionare Annulla questa operazione.

PowerShell

Per richiamare i comandi di PowerShell in un computer, è necessario installare localmente il pacchetto Az versione 9.7.0 o una versione successiva. In alternativa, prendere in considerazione l'uso di Azure Cloud Shell per eseguire Azure PowerShell su shell.azure.com.

Per prima cosa, accedere ad Azure e impostare il contesto appropriato per la sottoscrizione:

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

Per monitorare le operazioni in un database, incluse le operazioni di ridimensionamento, usare Get-AzSqlDatabaseActivity. Nell'esempio seguente, viene restituito un OperationId per ogni operazione attualmente in esecuzione.

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

Per annullare un'operazione asincrona come una scalabilità del database, identificare l'operazione e quindi usare Stop-AzSqlDatabaseActivity con uno specifico OperationId, come nell'esempio seguente.

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

Interfaccia della riga di comando di Azure

Da un terminale cloud shell, usare il comando di esempio seguente per identificare le operazioni attualmente in esecuzione. Da un terminale di Cloud Shell impostare le variabili $resourceGroupName, $serverName e $databaseName e poi eseguire il comando seguente:

$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

Per arrestare un'operazione asincrona come una scalabilità del database, da un terminale di Cloud Shell, impostare le variabili $resourceGroupName, $serverName e $databaseName e poi eseguire il comando seguente:

$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 Collaboratore, Collaboratore Database SQL o Collaboratore SQL Server. Per altre informazioni, vedere Ruoli predefiniti di Controllo degli accessi in base al ruolo di Azure.

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 l'articolo relativo ai backup del 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 a esecuzione prolungata non è una fonte significativa di ritardo, ma un utilizzo elevato delle risorse in contemporanea può lasciare meno risorse di calcolo, archiviazione e larghezza di banda di rete per il ridimensionamento, in particolare per risorse di calcolo di dimensioni inferiori.

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 è specificato in byte, deve essere un multiplo di 1 GB (1073741824 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.

Importante

In alcune circostanze, può essere necessario compattare un database per recuperare spazio inutilizzato. Per altre informazioni, vedere Gestire lo spazio file nel 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.

Importante

In alcune circostanze, può essere necessario compattare un database per recuperare spazio inutilizzato. Per altre informazioni, vedere Gestire lo spazio file nel 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 dimensione massima 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

Per i limiti generali delle risorse, vedere Limiti delle risorse basate su vCore del database SQL di Azure - database singoli e Limiti delle risorse basate su DTU del database SQL di Azure - database singoli.