Come gestire un database Hyperscale

Si applica a: Database SQL di Azure

Il livello di servizio Hyperscale offre un livello altamente scalabile per le prestazioni di archiviazione e calcolo, e sfrutta l'architettura di Azure per aumentare il numero di istanze per le risorse di archiviazione e di calcolo per un database SQL di Azure sostanzialmente oltre i limiti disponibili per i livelli di utilizzo generico e business critical. Questo articolo descrive come svolgere attività amministrative essenziali per i database Hyperscale, eseguire la migrazione di un database esistente a Hyperscale, effettuare il ripristino di un database Hyperscale in un'area diversa, eseguire la migrazione inversa da Hyperscale a un altro livello di servizio e monitorare lo stato delle operazioni in corso e recenti su un database Hyperscale.

Informazioni su come creare un nuovo database Hyperscale in Avvio rapido: Creare un database Hyperscale in database SQL di Azure.

Suggerimento

Prezzi semplificati per database SQL Hyperscale a dicembre 2023. Per informazioni dettagliate, consultare il blog sui prezzi di Hyperscale.

Eseguire la migrazione di un database esistente a Hyperscale

È possibile eseguire la migrazione di database SQL di Azure esistenti al livello di servizio Hyperscale usando il portale di Azure, l’interfaccia della riga di comando di Azure, Powershell o Transact-SQL.

Il tempo necessario per spostare in Hyperscale un database esistente equivale a quello necessario per copiare i dati e riprodurre le modifiche apportate nel database di origine durante la copia dei dati. Il tempo necessario per copiare i dati è proporzionale alle dimensioni dei dati. È consigliabile eseguire la migrazione a Hyperscale durante un periodo di attività di scrittura limitata, in modo da ridurre il tempo di riproduzione delle modifiche accumulate.

Durante il cutover finale al livello di servizio Hyperscale può verificarsi un breve periodo di inattività della durata di alcuni minuti.

Prerequisiti

Per spostare in Hyperscale un database che fa parte di una relazione di replica geografica primaria o secondaria, è necessario prima terminare la replica dei dati tra la replica primaria e secondaria. I database in un gruppo di failover devono essere prima rimossi dal gruppo.

Dopo che un database è stato spostato in Hyperscale, è possibile creare una nuova replica geografica Hyperscale per tale database.

La migrazione diretta dal livello di servizio Basic al livello di servizio Hyperscale non è supportata. Per eseguire questa migrazione, modificare prima di tutto il database in qualsiasi livello di servizio diverso da Basic (ad esempio, Utilizzo generico) e quindi procedere con la migrazione a Hyperscale.

Informazioni su come eseguire la migrazione di un database al livello di servizio Hyperscale

Per eseguire la migrazione di un database esistente in database SQL di Azure al livello di servizio Hyperscale, occorre prima identificare l'obiettivo del servizio di destinazione. In caso di dubbi su quale obiettivo di servizio sia adatto per il database, esaminare i limiti delle risorse per i database singoli. In molti casi, è possibile scegliere un obiettivo di servizio con lo stesso numero di vCore e la stessa generazione hardware del database originale. Se necessario, è possibile modificare l'obiettivo di servizio con tempi di inattività minimi.

Selezionare la scheda per lo strumento preferito per eseguire la migrazione del database:

Portale

Il portale di Azure consente di eseguire la migrazione al livello di servizio Hyperscale modificando il piano tariffario per il database.

1. Spostarsi al database di cui si vuole eseguire la migrazione nel portale di Azure.
2. Nella barra di spostamento sinistra, selezionare Calcolo + Archiviazione.
3. Selezionare l'elenco a discesa Livello di servizio per espandere le opzioni per i livelli di servizio.
4. Selezionare Hyperscale (archiviazione scalabile su richiesta) dal menu a discesa.
5. Esaminare la configurazione hardware elencata. Se necessario, selezionare Modifica configurazione per scegliere la configurazione hardware più appropriata per il carico di lavoro.
6. Selezionare il dispositivo di scorrimento vCore se si intende modificare il numero di vCore disponibili per il database nel livello di servizio Hyperscale.
7. Selezionare il dispositivo di scorrimento High-AvailabilitySecondaryReplicas se si desidera modificare il numero di repliche nel livello di servizio Hyperscale.
8. Selezionare Applica.

È possibile monitorare le operazioni per un database Hyperscale mentre l'operazione è in corso.

Interfaccia della riga di comando di Azure

Questo esempio di codice az sql db update consente di eseguire la migrazione di un database esistente in database SQL di Azure al livello di servizio Hyperscale. È necessario specificare sia l'edizione che l'obiettivo del servizio.

Sostituire resourceGroupName, serverName, databaseNamee serviceObjective con i valori appropriati prima di eseguire l'esempio di codice seguente:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="HS_Gen5_2"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition Hyperscale --service-objective $serviceObjective

È possibile monitorare le operazioni per un database Hyperscale mentre l'operazione è in corso.

PowerShell

Nell'esempio seguente viene usato il cmdlet Set-AzSqlDatabase per eseguire la migrazione di un database esistente in database SQL di Azure al livello di servizio Hyperscale. È necessario specificare sia l'edizione che l'obiettivo del servizio.

Sostituire $resourceGroupName, $serverName, $databaseNamee $serviceObjective con i valori appropriati prima di eseguire questo esempio di codice:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "HS_Gen5_2"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "Hyperscale" `
    -RequestedServiceObjectiveName $serviceObjective

È possibile monitorare le operazioni per un database Hyperscale mentre l'operazione è in corso.

Transact-SQL

Per eseguire la migrazione di un database esistente in database SQL di Azure al livello di servizio Hyperscale con Transact-SQL, connettersi prima al master database nel server SQL logico usando l'editor di query del portale di Azure per database SQL di Azure, SQL Server Management Studio (SSMS) o Azure Data Studio.

Nell'istruzione ALTER DATABASE è necessario specificare sia l'edizione che l'obiettivo del servizio.

Questa istruzione di esempio esegue la migrazione di un database denominato mySampleDatabase al livello di servizio Hyperscale con HS_Gen5_2 l'obiettivo di servizio. Sostituire il nome del database con il valore appropriato prima di eseguire l'istruzione.

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_2');
GO

È possibile monitorare le operazioni per un database Hyperscale mentre l'operazione è in corso.

Eseguire la migrazione inversa da Hyperscale

La migrazione inversa al livello di servizio per utilizzo generico permette ai clienti che di recente hanno eseguito la migrazione di un database esistente nel database SQL di Azure al livello di servizio Hyperscale di tornare indietro in caso di emergenza se Hyperscale non soddisfa le loro esigenze. Anche se la migrazione inversa viene avviata da una modifica al livello di servizio, si tratta essenzialmente di uno spostamento di dimensioni dei dati tra architetture diverse.

Limitazioni per la migrazione inversa

La migrazione inversa è disponibile alle condizioni seguenti:

• La migrazione inversa è disponibile solo entro 45 giorni dalla migrazione originale a Hyperscale.
• I database creati originariamente nel livello di servizio Hyperscale non sono idonei alla migrazione inversa.
• È possibile eseguire la migrazione inversa solo al livello di servizio per utilizzo generico. La migrazione dal livello di servizio Hyperscale a quello di utilizzo generico può avere come destinazione i livelli di calcolo serverless o con provisioning. Se si vuole eseguire la migrazione del database a un altro livello di servizio, ad esempio Business Critical o un livello di servizio basato su DTU, eseguire prima la migrazione inversa al livello di servizio per utilizzo generico, e successivamente modificare il livello di servizio.
• La migrazione inversa ai database con meno di 2 vcore non è supportata. È possibile ridurre il database a meno di 2 vcore al termine della migrazione.
• La migrazione inversa diretta da o verso un pool elastico non è supportata. È possibile invertire la migrazione solo di un database singolo Hyperscale a un database singolo per utilizzo generico.
  • Se il database Hyperscale fa parte di un pool elastico Hyperscale, prima di eseguire la migrazione inversa è necessario rimuoverlo dal pool elastico Hyperscale.
  • Se necessario, al termine della migrazione inversa, è possibile aggiungere facoltativamente il database singolo per utilizzo generico a un pool elastico per utilizzo generico.
• Per i database che non sono idonei alla migrazione inversa, l'unico modo per eseguire la migrazione da Hyperscale a un livello di servizio non Hyperscale consiste nell'eseguire l'esportazione o l'importazione usando un file con estensione BACPAC o altre tecnologie di spostamento dati (copia bulk, Azure Data Factory, Azure Databricks, SSIS e così via). L'esportazione e l'importazione di file BACPAC dal portale di Azure, da PowerShell usando New-AzSqlDatabaseExport o New-AzSqlDatabaseImport, dall'interfaccia della riga di comando di Azure usando az sql db export e az sql db import e dall'API REST non sono supportate. L'importazione e l'esportazione di file BACPAC per database Hyperscale di dimensioni inferiori (fino a 150 GB) sono supportate tramite SSMS e SqlPackage versione 18.4 e successive. Per i database di dimensioni superiori, l'esportazione o l'importazione di file BACPAC potrebbe richiedere molto tempo e avere esito negativo per diversi motivi.

Durata e tempo di inattività

A differenza delle normali operazioni di modifica degli obiettivi a livello di servizio in Hyperscale, la migrazione a Hyperscale e la migrazione inversa al livello di servizio per utilizzo generico sono operazioni di dimensioni dei dati.

La durata di un’operazione di migrazione inversa dipende principalmente dalle dimensioni del database e dalle attività di scrittura eseguite simultaneamente durante la migrazione. Il numero di vCore assegnati al database di destinazione per utilizzo generico incide sulla durata della migrazione inversa. È consigliabile effettuare il provisioning del database per utilizzo generico di destinazione con un numero di vCore maggiore o uguale al numero di vCore assegnati al database Hyperscale di origine per supportare carichi di lavoro analoghi.

Durante la migrazione inversa, il database Hyperscale di origine può riscontrare una riduzione delle prestazioni in caso di carico di lavoro considerevole. In particolare, la velocità del log delle transazioni potrebbe essere ridotta (limitata) per garantire l'avanzamento della migrazione inversa.

Durante il cutover finale al nuovo database per utilizzo generico di destinazione si verifica un breve periodo di inattività della durata di alcuni minuti.

Prerequisiti

Prima di avviare una migrazione inversa da Hyperscale al livello di servizio per utilizzo generico, è necessario assicurarsi che il database soddisfi le limitazioni per la migrazione inversa e che:

• La replica geografica non sia abilitata nel database.
• Il database non abbia repliche denominate.
• Il database (dimensioni allocate) sia sufficientemente piccolo da adattarsi al livello di servizio di destinazione.
• Se si specifica la dimensione massima del database per utilizzo generico di destinazione, assicurarsi che le dimensioni allocate del database siano sufficientemente piccole per adattarsi a tale dimensione massima.

I controlli dei prerequisiti vengono eseguiti prima dell'avvio di un'operazione di migrazione inversa. Se i prerequisiti non sono soddisfatti, l'operazione di migrazione inversa ha un immediato esito negativo.

Criteri di backup

Vengono fatturati i prezzi regolari per tutti i backup del database esistenti entro il periodo di conservazione configurato. Vengono addebitati gli snapshot dell'archivio di backup Hyperscale e i BLOB di archiviazione dei dati di dimensioni che devono essere conservati per poter ripristinare il backup.

È possibile eseguire la migrazione di un database a Hyperscale e la migrazione inversa al livello di servizio per utilizzo generico diverse volte. Per il ripristino sono disponibili solo i backup del livello di servizio corrente e direttamente precedente del database. Se è stata eseguita la migrazione dal livello di servizio per utilizzo generico a Hyperscale e nuovamente a utilizzo generico, gli unici backup disponibili sono quelli del database per utilizzo generico corrente e del database Hyperscale immediatamente precedente. Questi backup vengono conservati e fatturati in base alla fatturazione per database SQL di Azure. Tutti i livelli precedentemente provati non avranno backup disponibili e non verranno fatturati.

Ad esempio, è possibile eseguire la migrazione tra i livelli di servizio Hyperscale e non Hyperscale:

1. Utilizzo generico
2. Eseguire la migrazione a Hyperscale
3. Eseguire la migrazione inversa a Utilizzo generico
4. Modifica del livello di servizio a Business critical
5. Eseguire la migrazione a Hyperscale
6. Eseguire la migrazione inversa a Utilizzo generico

In questo caso, gli unici backup disponibili sono relativi ai passaggi 5 e 6 della timeline, se compresi entro il periodo di conservazione configurato. Eventuali backup dei passaggi precedenti non saranno disponibili. Valutare attentamente la disponibilità dei backup quando si eseguono più migrazioni ripetute dello stesso database tra Hyperscale e il livello di servizio per utilizzo generico. I backup di database precedenti al database immediatamente precedente diventano non disponibili non appena viene avviata una migrazione inversa e rimangono non disponibili anche se la migrazione viene annullata.

Come eseguire la migrazione inversa di un database Hyperscale al livello di servizio per utilizzo generico

Per eseguire la migrazione inversa di un database Hyperscale esistente in database SQL di Azure al livello di servizio per utilizzo generico, occorre prima identificare l'obiettivo del servizio di destinazione nel livello di servizio per utilizzo generico e stabilire se si intende eseguire la migrazione ai livelli di calcolo con provisioning o serverless. In caso di dubbi su quale obiettivo di servizio sia adatto per il database, esaminare i limiti delle risorse per i database singoli.

Se si intende eseguire una modifica aggiuntiva del livello di servizio dopo la migrazione inversa a utilizzo generico, identificare anche l'obiettivo del servizio di destinazione finale e assicurarsi che le dimensioni allocate del database siano sufficientemente piccole da adattarsi a tale obiettivo del servizio.

Selezionare la scheda corrispondente al metodo preferito per eseguire la migrazione inversa del database:

Portale

Il portale di Azure consente di eseguire la migrazione inversa al livello di servizio per utilizzo generico modificando il piano tariffario per il database.

1. Spostarsi al database di cui si vuole eseguire la migrazione nel portale di Azure.
2. Nella barra di spostamento sinistra, selezionare Calcolo + Archiviazione.
3. Selezionare l'elenco a discesa Livello di servizio per espandere le opzioni per i livelli di servizio.
4. Selezionare Utilizzo generico (opzioni di calcolo e archiviazione scalabili) dal menu a discesa.
5. Esaminare la configurazione hardware elencata. Se necessario, selezionare Modifica configurazione per scegliere la configurazione hardware più appropriata per il carico di lavoro.
6. Selezionare il dispositivo di scorrimento vCore se si intende modificare il numero di vCore disponibili per il database nel livello di servizio per Utilizzo generico.
7. Selezionare Applica.

Interfaccia della riga di comando di Azure

Questo esempio di codice az sql db update consente di eseguire la migrazione inversa di un database Hyperscale esistente al livello di servizio per utilizzo generico. È necessario specificare sia l'edizione che l'obiettivo del servizio. È possibile selezionare Provisioned o Serverless per il modello di calcolo di destinazione.

Sostituire resourceGroupName, serverName, databaseNamee serviceObjective con i valori appropriati prima di eseguire l'esempio di codice seguente:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel

È inoltre possibile includere l'argomento maxsize. Se il maxsize valore supera le dimensioni massime valide per l'obiettivo del servizio di destinazione, viene visualizzato un errore. Se maxsize l'argomento non viene specificato, per impostazione predefinita l'operazione corrisponde alla dimensione massima disponibile per l'obiettivo di servizio specificato. L'esempio seguente specifica maxsize:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"
maxsize="200GB"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel --max-size $maxsize

È possibile monitorare le operazioni per un database Hyperscale mentre l'operazione è in corso.

PowerShell

Questo esempio di codice usa il Set-AzSqlDatabase cmdlet per eseguire la migrazione inversa di un database esistente dal livello di servizio Hyperscale al livello di servizio per utilizzo generico. È necessario specificare sia l'edizione che l'obiettivo del servizio. È possibile selezionare Provisioned o Serverless per il livello di calcolo di destinazione.

Sostituire $resourceGroupName, $serverName, $databaseName, $serviceObjectivee $computeModel con i valori appropriati prima di eseguire l'esempio di codice seguente:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective

È inoltre possibile includere l'argomento maxsize. Se il maxsize valore supera le dimensioni massime valide per l'obiettivo del servizio di destinazione, viene visualizzato un errore. Se maxsize l'argomento non viene specificato, per impostazione predefinita l'operazione corrisponde alla dimensione massima disponibile per l'obiettivo di servizio specificato. L'esempio seguente specifica maxsize:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"
$maxSizeBytes = "268435456000"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective -MaxSizeBytes $maxSizeBytes

È possibile monitorare le operazioni per un database Hyperscale mentre l'operazione è in corso.

Transact-SQL

Per invertire la migrazione di un database Hyperscale al livello di servizio per utilizzo generico con Transact-SQL, connettersi prima al master database nel server SQL logico usando SQL Server Management Studio (SSMS), Azure Data Studio .

Nell'istruzione ALTER DATABASE è necessario specificare sia l'edizione che l'obiettivo del servizio.

Questa istruzione di esempio esegue la migrazione di un database denominato mySampleDatabase al livello di servizio per utilizzo generico con GP_Gen5_4 l'obiettivo di servizio. Prima di eseguire l'istruzione, sostituire il nome del database e l'obiettivo di servizio con i valori appropriati.

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2');
GO

È inoltre possibile includere l'argomento maxsize. Se il maxsize valore supera le dimensioni massime valide per l'obiettivo del servizio di destinazione, viene visualizzato un errore. Se maxsize l'argomento non viene specificato, per impostazione predefinita l'operazione corrisponde alla dimensione massima disponibile per l'obiettivo di servizio specificato. L'esempio seguente specifica maxsize:

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2', MAXSIZE = 200 GB);
GO

È possibile monitorare le operazioni per un database Hyperscale mentre l'operazione è in corso.

Monitorare le operazioni per un database Hyperscale

È possibile monitorare lo stato delle operazioni in corso o completate di recente per un database SQL di Azure usando il portale di Azure, l'interfaccia della riga di comando di Azure, PowerShell o Transact-SQL.

Selezionare la scheda corrispondente al metodo preferito per monitorare le operazioni.

Portale

Quando è in corso un'operazione, che si tratti di migrazione, migrazione inversa o ripristino, il portale di Azure mostra una notifica per un database in database SQL di Azure.

1. Spostarsi nel database nel portale di Azure.
2. Nella barra di spostamento a sinistra selezionare Panoramica.
3. Esaminare la sezione Notifiche nella parte inferiore del riquadro destro. Se le operazioni sono in corso, viene visualizzata una finestra di notifica.
4. Selezionare la casella di notifica per visualizzare i dettagli.
5. Viene visualizzato il riquadro Operazioni in corso. Esaminare i dettagli delle operazioni in corso.

Interfaccia della riga di comando di Azure

Questo esempio di codice az sql db op list permette di restituire operazioni recenti o in corso per un database in database SQL di Azure.

Sostituire resourceGroupName, serverName, databaseNamee serviceObjective con i valori appropriati prima di eseguire l'esempio di codice seguente:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"

az sql db op list -g $resourceGroupName -s $serverName --database $databaseName

PowerShell

Il cmdlet Get-AzSqlDatabaseActivity restituisce operazioni recenti o in corso per un database in database SQL di Azure.

Impostare i parametri $resourceGroupName, $serverNamee $databaseName sui valori appropriati per il database prima di eseguire il codice di esempio:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"

Get-AzSqlDatabaseActivity -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName

Transact-SQL

Per monitorare le operazioni per un database Hyperscale, connettersi prima al master database nel server logico usando SQL Server Management Studio (SSMS), Azure Data Studio o il client prescelto per eseguire comandi Transact-SQL.

Eseguire la query sys.dm_operation_status sulla DMV per esaminare le informazioni sulle operazioni recenti eseguite sui database nel [server logico](logical-servers.md].

Questo esempio di codice restituisce tutti gli interi in sys.dm_operation_status per il database specificato, ordinati in base alle operazioni iniziate più di recente. Sostituire il nome del database con il valore appropriato prima di eseguire l'esempio di codice.

SELECT *
FROM sys.dm_operation_status
WHERE major_resource_id = 'mySampleDatabase'
ORDER BY start_time DESC;
GO

Visualizzare i database nel livello di servizio Hyperscale

Dopo la migrazione di un database a Hyperscale o la riconfigurazione di un database all'interno del livello di servizio Hyperscale, è possibile visualizzare e/o documentare la configurazione del database Hyperscale.

Portale

Il portale di Azure mostra un elenco di tutti i database in un server logico. La colonna Piano tariffario include il livello di servizio per ciascun database.

1. Nel portale di Azure passare al server logico.
2. Nella barra di spostamento a sinistra selezionare Panoramica.
3. Scorrere fino all'elenco delle risorse nella parte inferiore del riquadro. Nella finestra vengono visualizzati i pool elastici e i database SQL nel server logico.
4. Esaminare la colonna Piano tariffario per identificare i database nel livello di servizio Hyperscale.

Interfaccia della riga di comando di Azure

Questo esempio di codice dell'interfaccia della riga di comando di Azure az sql db list permette di elencare i database Hyperscale in un server logico specificando il nome, la posizione, l'obiettivo del livello di servizio, le dimensioni massime e il numero di repliche di disponibilità elevata.

Sostituire resourceGroupName e serverName con i valori appropriati prima di eseguire l'esempio di codice seguente:

resourceGroupName="myResourceGroup"
serverName="server01"

az sql db list -g $resourceGroupName -s $serverName --query "[].{Name:name, Location:location, SLO:currentServiceObjectiveName, Tier:currentSku.tier, maxSizeBytes:maxSizeBytes,HAreplicas:highAvailabilityReplicaCount}[?Tier=='Hyperscale']" --output table

PowerShell

Il cmdlet Get-AzSqlDatabase di Azure PowerShell restituisce un elenco di database Hyperscale in un server logico specificando il nome, la posizione, l'obiettivo del livello di servizio, le dimensioni massime e il numero di repliche di disponibilità elevata.

Impostare valori appropriati per i parametri $resourceGroupName e $serverName prima di eseguire il codice di esempio:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"

Get-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName | `
    Where-Object { $_.Edition -eq 'Hyperscale' } | `
        Select-Object DatabaseName, Location, currentServiceObjectiveName, Edition, `
        MaxSizeBytes, HighAvailabilityReplicaCount | `
            Format-Table

Esaminare la colonna Edition per identificare i database nel livello di servizio Hyperscale.

Transact-SQL

Per esaminare i livelli di servizio di tutti i database Hyperscale in un server logico con Transact-SQL, connettersi prima al master database usando SQL Server Management Studio (SSMS) o Azure Data Studio.

Eseguire la query sys.database_service_objectives sulla vista del catalogo di sistema per esaminare i database nel livello di servizio Hyperscale:

SELECT d.name, dso.edition, dso.service_objective
FROM sys.database_service_objectives AS dso
JOIN sys.databases as d on dso.database_id = d.database_id
WHERE dso.edition = 'Hyperscale';
GO

Contenuto correlato

Maggiori informazioni sui database Hyperscale sono disponibili negli articoli seguenti:

• Guida introduttiva: Creare un database Hyperscale in database SQL di Azure
• Livello di servizio Hyperscale
• Domande frequenti su Hyperscale per il database SQL di Azure
• Repliche secondarie Hyperscale
• Domande frequenti sulle repliche denominate di Hyperscale per il database SQL di Azure