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 Azure SQL nel livello di calcolo con provisioning. In alternativa, il livello di calcolo serverless fornisce la scalabilità automatica e le fatture di calcolo al secondo per il calcolo usato.

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

Importante

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

Impatto

La modifica del livello di servizio o delle dimensioni di calcolo prevede principalmente 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 richiesto e le dimensioni di calcolo. 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 implica la copia dei dati e può influire fortemente sulla 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. Passare al 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 riattaccati 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 ripristinare le transazioni interrotte. Il ripristino accelerato del database può ridurre l'impatto dell'interruzione delle transazioni a esecuzione prolungata.

Importante

Nessun dato viene perso durante qualsiasi passaggio del flusso di lavoro. Assicurarsi di aver implementato una logica di ripetizione dei tentativi nelle applicazioni e nei componenti che usano Azure SQL Database mentre viene modificato il livello di servizio.

Latenza

La latenza stimata per modificare il livello di servizio, ridimensionare le dimensioni di calcolo di un singolo database o pool elastico, spostare un database in/fuori da un pool elastico o spostare un database tra pool elastici è parametrizzato come indicato di seguito:

Livello di servizio Database singolo di base,
Standard (S0-S1)
Pool elastico di base,
Standard (S2-S12),
per utilizzo generico database singolo o pool elastico
Database singolo o pool elastico Premium o Business Critical Hyperscale
Database singolo di base,
Standard (S0-S1)
• Latenza tempo costante indipendentemente da 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 usato
• Latenza proporzionale allo spazio del database usato a causa della copia
dei dati• In genere, meno di 1 minuto per GB di spazio usato
• Latenza proporzionale allo spazio del database usato a causa della copia
dei dati• In genere, meno di 1 minuto per GB di spazio usato
Pool elastico di base,
Standard (S2-S12),
per utilizzo generico database singolo o pool elastico
• Latenza proporzionale allo spazio del database usato a causa della copia
dei dati• In genere, meno di 1 minuto per GB di spazio usato
• Per i database singoli, la latenza temporale costante indipendente dallo spazio usato
• In genere, meno di 5 minuti per i singoli database• 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 usato
• Latenza proporzionale allo spazio del database usato a causa della copia
dei dati• In genere, meno di 1 minuto per GB di spazio usato
Database singolo o pool elastico Premium o Business Critical • Latenza proporzionale allo spazio del database usato a causa della copia
dei dati• In genere, meno di 1 minuto per GB di spazio usato
• Latenza proporzionale allo spazio del database usato a causa della copia
dei dati• In genere, meno di 1 minuto per GB di spazio usato
• Latenza proporzionale allo spazio del database usato a causa della copia
dei dati• In genere, meno di 1 minuto per GB di spazio usato
• Latenza proporzionale allo spazio del database usato a causa della copia
dei dati• In genere, meno di 1 minuto per GB di spazio usato
Hyperscale N/D Vedere Eseguire la migrazione inversa da Hyperscale N/D • Latenza tempo costante indipendentemente da spazio usato
• In genere, meno di 2 minuti

Nota

Inoltre, per i database Standard (S2-S12) e per utilizzo generico, latenza per lo spostamento di un database in/fuori da un pool elastico o tra pool elastici sarà proporzionale alle dimensioni del database se il database usa l'archiviazione PFS (Premium File Share).

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à ridondante della zona rimarrà invariata per impostazione predefinita quando si esegue il ridimensionamento dal business critical al livello di per utilizzo generico. La latenza per questo downgrade quando la ridondanza della zona è abilitata e la latenza per passare alla ridondanza della zona per il livello per utilizzo generico sarà proporzionale alle dimensioni del database.

Annullamento delle modifiche

È possibile annullare un'operazione di ridimensionamento del livello di servizio o di calcolo.

Portale di Azure

Nel pannello Panoramica del database passare a Notifiche e fare clic sul riquadro che indica che è in corso un'operazione:

Operazione in corso

Fare quindi clic sul pulsante etichettato Annulla questa operazione.

Annullare l'operazione in corso

PowerShell

Da un prompt dei comandi di PowerShell impostare , $resourceGroupName$serverNamee $databaseNamequindi eseguire il comando seguente:

$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 dimensionare i database tramite T-SQL, sono necessarie le autorizzazioni ALTER DATABASE. Per ridimensionare un database un account di accesso deve essere l'account di accesso amministratore del server (creato quando è stato effettuato il provisioning del server logico del database Azure SQL), l'amministratore di Azure AD del server, un membro del ruolo del database dbmanager in master, un membro del ruolo del database db_owner nel database corrente o dbo nel database corrente. 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.

Altre considerazioni

  • 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 ridimensionato su S3, un costo di archiviazione aggiuntivo si applica poiché S3 supporta una dimensione massima di 1 TB e la relativa quantità di archiviazione inclusa è solo 250 GB. Lo spazio di archiviazione extra è quindi 500 GB - 250 GB = 250 GB. Per i prezzi dell'archiviazione aggiuntiva, vedere prezzi del database Azure SQL. 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 che il database secondario venga aggiornato per primo.
  • 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, è un requisito che il database primario venga eseguito prima di tutto.
  • 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 del 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 è necessaria la copia dei dati per ridimensionare un database (vedere Latenza) quando si modifica il livello di servizio, l'utilizzo elevato delle risorse simultaneo all'operazione di ridimensionamento potrebbe 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 l'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 e le dimensioni di calcolo più elevate applicate durante tale ora, indipendentemente dall'utilizzo o dal fatto che il database sia 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

  • È possibile effettuare il provisioning dell'archiviazione fino al limite massimo di dimensioni di archiviazione dei dati usando incrementi di 1 GB. L'archiviazione minima dei dati configurabile è 1 GB. Per i limiti delle 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, Azure SQL Database alloca automaticamente il 30% di spazio di archiviazione da usare per il log delle transazioni.
  • Azure SQL Database alloca automaticamente 32 GB per vCore per il tempdb database. tempdb si trova nell'archiviazione SSD locale in tutti i livelli di servizio.
  • Il prezzo dell'archiviazione per un database singolo o un pool elastico è la somma degli importi di archiviazione dei dati e di archiviazione dei log delle transazioni moltiplicati per il prezzo unitario di archiviazione del livello di servizio. Il costo di tempdb è incluso nel prezzo. Per informazioni dettagliate sul prezzo di archiviazione, vedere prezzi di Azure SQL database.

Importante

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

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 dell'archiviazione aggiuntiva, vedere prezzi di Azure SQL Database.

Importante

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

Database con replica geografica

Per modificare le dimensioni del database 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 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 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. Le dimensioni di calcolo inferiori vengono rifiutate come database secondari 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.exe per importare ed esportare i dati.

Passaggi successivi

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