Ridimensionare le risorse di database singoli nel database SQL di Azure

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

Dopo aver selezionato inizialmente il numero di vCore o DTU, è possibile ridimensionare un singolo database in modo dinamico in base all'esperienza effettiva usando:

• 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 noto come Azure Active Directory (Azure AD).

Impatto

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

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

   Viene creata una nuova istanza 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 calcolo, che comporta la copia dei dati e può influenzare fortemente la latenza complessiva. Indipendentemente dal fatto che il database rimanga online durante questo passaggio e le connessioni continuino a essere indirizzate al database nell'istanza di calcolo originale.

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

   Le connessioni esistenti al database nell'istanza di calcolo originale vengono eliminate. Tutte le nuove connessioni vengono stabilite al database nella nuova istanza 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 l'opzione. Indipendentemente dal fatto che l'opzione possa causare una breve interruzione del servizio quando il database non è disponibile in genere per meno di 30 secondi e spesso 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 database SQL di Azure mentre il livello di servizio viene modificato.

Latenza

La latenza stimata per modificare il livello di servizio, ridimensionare 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	Per database singolo Basic, database singolo Standard (S0-S1)	Per database singolo Standard (S2-S12), database singolo per utilizzo generico, database elastico di base in pool, database elastico standard in pool, database in pool per utilizzo generico	Per database singolo Premium o database in pool, database singolo business critical o database in pool	Per un database singolo o un database in pool Hyperscale
Da database singolo Basic, database singolo Standard (S0-S1)	• Latenza temporale costante indipendentemente da quello 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 da quello 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 scenari e limitazioni supportati.	N/D	• Latenza temporale costante indipendentemente da quello 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 in/fuori di un pool elastico o tra pool elastici sarà proporzionale alle dimensioni del database se il database usa l'archiviazione PFS (Premium File Share).
• Nel caso di spostamento di un database da e verso un pool elastico, solo lo spazio usato dal database influisce sulla latenza e non sullo 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à la stessa per impostazione predefinita quando si ridimensiona un singolo database dal livello Business Critical al livello 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 usando l'API REST SQL, Gestire le operazioni tramite l'interfaccia della riga di comando, Monitorare le operazioni con T-SQL e questi due comandi di PowerShell: Get-AzSqlDatabaseActivity e Stop-AzSqlDatabaseActivity.

Monitorare o annullare le modifiche di ridimensionamento

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

Azure portal

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

Nella pagina Operazioni in corso risultanti 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 in 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 oggetto 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 un oggetto 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 $resourceGroupNamevariabili , $serverNamee $databaseName e quindi 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 $resourceGroupNamevariabili , $serverNamee $databaseName e quindi 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, ALTER DATABASE viene usato . Per ridimensionare un database, un account di accesso deve essere l'account di accesso amministratore del server (creato al momento del provisioning del server logico database SQL di Azure), l'amministratore di 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. Ad esempio, se un database P1 con dimensioni massime di 500 GB viene ridotto a S3, si applica un costo di archiviazione aggiuntivo poiché S3 supporta una dimensione massima di 1 TB e la quantità di archiviazione inclusa è di soli 250 GB. Lo spazio di archiviazione extra è quindi 500 GB - 250 GB = 250 GB. Per i prezzi di spazio di archiviazione aggiuntivo, vedere database SQL di Azure prezzi. 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). Quando si esegue l'aggiornamento a un'edizione diversa, è necessario prima aggiornare 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). Quando si esegue il downgrade a un'edizione diversa, è necessario prima effettuare il downgrade del database primario.
• Le offerte per il ripristino del servizio sono diverse per i vari livelli di servizio. Se si esegue il downgrade al livello Basic , è previsto un periodo di conservazione dei backup inferiore. Vedere l'articolo relativo ai backup del database SQL di Azure.
• Le nuove proprietà per il database non vengono applicate fino al completamento delle modifiche.
• Quando la copia dei dati è necessaria per ridimensionare un database (vedere Latenza) quando si modifica il livello di servizio, l'utilizzo elevato delle risorse simultaneo all'operazione di ridimensionamento può causare tempi di ridimensionamento più lunghi. Con il ripristino accelerato del database (ADR), il rollback delle transazioni a esecuzione prolungata non è una fonte significativa di ritardo, ma un utilizzo elevato delle risorse simultanee può lasciare meno risorse di calcolo, archiviazione e larghezza di banda di rete per il ridimensionamento, in particolare per dimensioni di calcolo più piccole.

Fatturazione

Viene addebitato un costo per ogni ora in cui un database esiste usando il livello di servizio più elevato e le dimensioni di calcolo applicate durante tale ora, indipendentemente dall'utilizzo o dal fatto che il database fosse 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

• Archiviazione è possibile eseguire il provisioning fino al limite di dimensioni massime di archiviazione dei dati usando incrementi di 1 GB. L'archiviazione minima dei dati configurabile è 1 GB. Per i limiti di dimensioni massime dell'archiviazione dei dati in ogni obiettivo di servizio, vedere le pagine della documentazione relativa ai limiti delle risorse per i database singoli usando il modello di acquisto vCore e i limiti delle risorse per i database singoli usando 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, database SQL di Azure aggiunge automaticamente il 30% di spazio di archiviazione da usare per il log delle transazioni. Il prezzo dell'archiviazione per un database singolo o un pool elastico è la somma degli importi di archiviazione dei dati e di archiviazione del log delle transazioni moltiplicati per il prezzo unitario di 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.

• database SQL di Azure alloca automaticamente 32 GB per vCore per il tempdb database. 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 di archiviazione, vedere prezzi 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 di spazio di archiviazione aggiuntivo, vedere database SQL di Azure prezzi.

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 quando la dimensione massima è maggiore di 1 TB

Più di 1 TB di spazio di archiviazione nel livello Premium sono attualmente disponibili in tutte le aree, ad eccezione della Cina orientale, della Cina settentrionale, della Germania centrale e della 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 mai state impostate su un valore maggiore di 1 TB, 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 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. Le 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 più di 1 TB, il database primario non viene aggiornato.
• L'uso del servizio Importazione/Esportazione per il caricamento di database P11/P15 con più di 1 TB non è supportato. Usare SqlPackage per importare ed esportare dati.

Contenuto correlato

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