Comment gérer une base de données Hyperscale

S’applique à : Azure SQL Database

Ce niveau de service Hyperscale fournit un stockage hautement scalable et un niveau de performances de calcul qui tire partie de l’architecture Azure pour effectuer un scale-out du stockage et des ressources de calcul d’une base de données Azure SQL bien au-delà des limites disponibles des niveaux Usage général et Critique pour l’entreprise. Cet article explique comment effectuer des tâches d’administration essentielles pour les bases de données Hyperscale, notamment la migration d’une base de données existante vers Hyperscale, la restauration d’une base de données Hyperscale vers une autre région, la migration inversée d’Hyperscale vers un autre niveau de service et la surveillance de l’état des opérations en cours et récentes sur une base de données Hyperscale.

Découvrez comment créer une base de données Hyperscale dans le Guide de démarrage rapide : Créer une base de données Hyperscale dans Azure SQL Database.

Conseil

La tarification simplifiée de SQL Database Hyperscale en décembre 2023. Pour en savoir plus, reportez-vous au blog de tarification Hyperscale.

Migrer une base de données existante vers Hyperscale

Vous pouvez migrer vos bases de données Azure SQL Database existantes vers Hyperscale à l’aide du portail Azure, de l’interface de ligne de commande Azure, de PowerShell ou de Transact-SQL.

Le temps nécessaire pour déplacer une base de données existante vers Hyperscale comprend le temps de copie des données et celui de relecture des modifications apportées dans la base de données source lors de la copie des données. Le temps de copie des données est proportionnel à la taille des données. Nous vous recommandons de migrer vers Hyperscale pendant une période d’activité d’écriture inférieure afin que le temps de relecture des modifications accumulées soit plus court.

Vous ne rencontrerez qu’une courte période de temps d’arrêt, généralement quelques minutes, pendant le basculement final vers le niveau de service Hyperscale.

Prérequis

Pour déplacer une base de données faisant partie d’une relation de géo-réplication, en tant que base de données primaire ou secondaire, vers le niveau Hyperscale, vous devez arrêter la réplication des données entre le réplica principal et le réplica secondaire. Les bases de données d’un groupe de basculement doivent d’abord être supprimées du groupe.

Une fois qu’une base de données a été déplacée vers le niveau Hyperscale, vous pouvez créer un nouveau géo-réplica de niveau Hyperscale pour cette base de données.

La migration directe du niveau de service Essentiel vers le niveau de service Hyperscale n’est pas prise en charge. Pour effectuer cette migration, commencez par modifier la base de données à n’importe quel niveau de service autre qu’Essentiel (par exemple, Usage général), puis passez à la migration vers Hyperscale.

Comment migrer une base de données vers le niveau de service Hyperscale

Pour migrer une base de données existante dans Azure SQL Database vers le niveau de service Hyperscale, identifiez d’abord votre objectif de service cible. Passez en revue les limites de ressources pour les bases de données uniques si vous ne savez pas quel objectif de service convient à votre base de données. Dans de nombreux cas, vous pouvez choisir un objectif de service avec le même nombre de vCores et la même génération de matériel que la base de données d’origine. Si nécessaire, vous pouvez modifier l’objectif de service avec un temps d’arrêt minimal.

Sélectionnez l’onglet de votre outil préféré pour migrer votre base de données :

Portail

Le portail Azure vous permet de migrer vers le niveau de service Hyperscale en modifiant le niveau tarifaire de votre base de données.

1. Accédez à la base de données que vous souhaitez migrer dans le portail Azure.
2. Dans la barre de navigation de gauche, sélectionnez Calcul+stockage.
3. Sélectionnez le menu déroulant Niveau de service pour développer les options de niveaux de service.
4. Sélectionnez Hyperscale (stockage évolutif à la demande) dans le menu déroulant.
5. Passez en revue la configuration matérielle répertoriée. Si vous le souhaitez, sélectionnez Modifier la configuration pour sélectionner la configuration matérielle appropriée à votre charge de travail.
6. Sélectionnez le curseur vCores si vous souhaitez modifier le nombre de vCores disponibles pour votre base de données sous le niveau de service Hyperscale.
7. Sélectionnez le curseur High-AvailabilitySecondaryReplicas si vous souhaitez modifier le nombre de réplicas sous le niveau de service Hyperscale.
8. Sélectionnez Appliquer.

Vous pouvez surveiller les opérations d’une base de données Hyperscale pendant que l’opération est en cours.

Azure CLI

Cet exemple de code appelle az sql db update pour migrer une base de données existante dans Azure SQL Database vers le niveau de service Hyperscale. Vous devez spécifier l’édition et l’objectif du service.

Remplacez resourceGroupName, serverName, databaseName et serviceObjective par les valeurs appropriées avant d’exécuter l’exemple de code suivant :

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

Vous pouvez surveiller les opérations d’une base de données Hyperscale pendant que l’opération est en cours.

PowerShell

Cet exemple de code appelle le cmdlet Set-AzSqlDatabase pour migrer une base de données existante dans Azure SQL Database vers le niveau de service Hyperscale. Vous devez spécifier l’édition et l’objectif du service.

Remplacez $resourceGroupName, $serverName, $databaseName et $serviceObjective par les valeurs appropriées avant d’exécuter cet exemple de code :

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

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

Vous pouvez surveiller les opérations d’une base de données Hyperscale pendant que l’opération est en cours.

Transact-SQL

Pour migrer une base de données Azure SQL existante vers le niveau de service Hyperscale avec Transact-SQL, commencez par vous connecter à la base de données master sur votre serveur SQL logique à l’aide de l’éditeur de requêtes du portail Azure pour la base de données Azure SQL, de SQL Server Management Studio (SSMS) ou d’Azure Data Studio.

Vous devez spécifier l’édition et l’objectif du service dans l’instruction ALTER DATABASE.

Cet exemple d’instruction migre une base de données appelée mySampleDatabase vers le niveau de service Hyperscale avec l’objectif de service HS_Gen5_2. Remplacez le nom de la base de données par la valeur appropriée avant d’exécuter l’instruction.

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

Vous pouvez surveiller les opérations d’une base de données Hyperscale pendant que l’opération est en cours.

Migration inversée à partir d’Hyperscale

La migration inversée vers le niveau de service usage général permet aux clients qui ont récemment migré une base de données existante dans Azure SQL Database vers le niveau de service Hyperscale de revenir en cas d’urgence, si Hyperscale ne répond pas à leurs besoins. Bien que la migration inversée soit lancée par un changement de niveau de service, il s’agit essentiellement d’un déplacement de taille de données entre différentes architectures.

Limitations de la migration inversée

La migration inversée est disponible dans les conditions suivantes :

• La migration inversée est disponible uniquement dans les 45 jours suivant la migration d’origine vers Hyperscale.
• Les bases de données créées à l’origine dans le niveau de service Hyperscale ne sont pas éligibles à la migration inversée.
• Vous pouvez annuler la migration vers le niveau de service usage général uniquement. Votre migration d’Hyperscale vers le niveau d’usage général peut cibler les niveaux de calcul serverless ou provisionnés. Si vous souhaitez migrer la base de données vers un autre niveau de service, tel que critique pour l'entreprise ou niveau de service basé sur les DTU, effectuez d’abord une migration inversée vers le niveau de service usage général, puis modifiez le niveau de service.
• La migration inversée vers des bases de données avec moins de 2 vCores n’est pas prise en charge. Vous pouvez réduire la taille de la base de données à moins de 2 vCores une fois la migration terminée.
• La migration inversée directe depuis ou vers un pool élastique n’est pas prise en charge. Vous pouvez inverser la migration d’une seule base de données Hyperscale vers une base de données à usage général unique.
  • Si la base de données Hyperscale fait partie d’un pool élastique Hyperscale, vous devez d’abord la supprimer du pool élastique Hyperscale avant d’inverser la migration.
  • Une fois la migration inversée terminée, vous pouvez éventuellement ajouter la base de données unique à usage général à un pool élastique usage général si nécessaire.
• Pour les bases de données pour lesquelles la migration inversée n’est pas possible, la seule façon de migrer une base de données d’Hyperscale vers un niveau de service non-Hyperscale consiste à exporter/importer à l’aide d’un fichier bacpac ou d’autres technologies de déplacement de données (copie en bloc, Azure Data Factory, Azure Databricks, SSIS, etc.) L’exportation et l’importation bacpac à partir du portail Azure, à partir de PowerShell à l’aide des cmdlets New-AzSqlDatabaseExport ou New-AzSqlDatabaseImport, à partir d’Azure CLI à l’aide des commandes az sql db export et az sql db import, et d’une API REST, ne sont pas prises en charge. L'exportation et l'importation bacpac pour des bases de données Hyperscale de plus petite taille (jusqu'à 150  Go) est prise en charge à l'aide de SSMS et de SqlPackage versions 18.4 et ultérieures. Pour des bases de données plus volumineuses, l’exportation et l’importation bacpac peuvent prendre beaucoup de temps et échouer pour différentes raisons.

Durée et temps d’arrêt

Contrairement aux opérations régulières de changement d’objectif de niveau de service dans Hyperscale, la migration vers Hyperscale et la migration inversée vers l’usage général sont des opérations liées à la taille des données.

La durée de l’opération de migration inversée dépend principalement de la taille de la base de données et des activités d’écriture simultanées qui se produisent pendant la migration. Le nombre de vCores que vous affectez à la base de données à usage général cible a également un impact sur la durée de la migration inversée. Nous vous recommandons d’approvisionner la base de données à usage général cible avec un nombre de vCores supérieurs ou égal au nombre de vCores affectés à la base de données Hyperscale source pour des charges de travail similaires.

Lors de la migration inversée, la base de données Hyperscale source peut subir une dégradation des performances en cas de charge importante. Plus précisément, le taux de journalisation des transactions peut être réduit (limité) pour s’assurer que la migration inversée progresse.

Vous rencontrerez une courte période de temps d’arrêt, généralement quelques minutes, pendant le basculement final vers la nouvelle base de données à usage général.

Prérequis

Avant de lancer une migration inversée d’Hyperscale vers le niveau de service à usage général, vous devez vous assurer que votre base de données respecte les limitations de la migration inversée et :

• La géoréplication de votre base de données n’est pas activée.
• Votre base de données n’a pas de réplicas nommés.
• Votre base de données (taille allouée) est suffisamment petite pour s’adapter au niveau de service cible.
• Si vous spécifiez la taille maximale de base de données pour la base de données à usage général cible, assurez-vous que la taille allouée de la base de données est suffisamment petite pour s’adapter à cette taille maximale.

Ces vérifications des prérequis doivent avoir lieu avant le démarrage de l’opération de migration inversée. Si les conditions préalables ne sont pas remplies, l’opération de migration inversée échoue immédiatement.

Stratégies de sauvegarde

Vous serez facturé selon la tarification normale pour toutes les sauvegardes de base de données existantes au cours de la période de rétention configurée. Vous serez facturé pour les instantanés de stockage de sauvegarde Hyperscale et pour les objets blob de stockage de données qui doivent être conservés pour pouvoir restaurer la sauvegarde.

Vous pouvez migrer une base de données vers Hyperscale et revenir à l’usage général plusieurs fois. Seules les sauvegardes à partir du niveau actuel et du niveau précédent de votre base de données seront disponibles pour la restauration. Si vous êtes passé du niveau de service usage général à Hyperscale et que vous êtes revenu à l’usage général, les seules sauvegardes disponibles sont celles de la base de données à usage général actuelle et celle de la base de données Hyperscale précédente. Ces sauvegardes conservées sont facturées conformément à la facturation Azure SQL Database. Les niveaux précédents essayés n’ont pas de sauvegardes et ne seront pas facturés.

Par exemple, vous pouvez migrer entre les niveaux de service Hyperscale et non-Hyperscale :

1. Usage général
2. Migrer vers Hyperscale
3. Migration inversée vers usage général
4. Changement de niveau de service en critique pour l'entreprise
5. Migrer vers Hyperscale
6. Migration inversée vers usage général

Dans ce cas, les seules sauvegardes disponibles proviennent des étapes 5 et 6 de la chronologie, si elles sont toujours dans la période de rétention configurée. Toutes les sauvegardes des étapes précédentes ne sont pas disponibles. Examinez attentivement la disponibilité des sauvegardes lorsque vous tentez des migrations répétées de la même base de données entre les niveaux de service Hyperscale et Usage général. Les sauvegardes de bases de données antérieures à la base de données immédiatement précédente deviennent non disponible dès qu’une migration inversée est démarrée et restent non disponible même si la migration est annulée.

Comment inverser la migration d’une base de données Hyperscale vers le niveau de service usage général

Pour inverser la migration d’une base de données Hyperscale existante dans Azure SQL Database vers le niveau de service Hyperscale, commencez par identifier votre objectif de service cible dans le niveau de service à usage général et si vous souhaitez migrer vers les niveaux de calcul approvisionnés ou serverless. Passez en revue les limites de ressources pour les bases de données uniques si vous ne savez pas quel objectif de service convient à votre base de données.

Si vous souhaitez effectuer une modification de niveau de service supplémentaire après la migration inversée vers l’usage général, identifiez également votre objectif de service cible final et assurez-vous que la taille allouée de votre base de données est suffisamment petite pour s’adapter à cet objectif de service.

Sélectionnez l’onglet de votre méthode préférée pour inverser la migration de votre base de données :

Portail

Le portail Azure vous permet d’inverser la migration vers le niveau de service Usage général Hen modifiant le niveau tarifaire de votre base de données.

1. Accédez à la base de données que vous souhaitez migrer dans le portail Azure.
2. Dans la barre de navigation de gauche, sélectionnez Calcul+stockage.
3. Sélectionnez le menu déroulant Niveau de service pour développer les options de niveaux de service.
4. Sélectionnez Usage général (options de calcul et de stockage évolutives) dans le menu déroulant.
5. Passez en revue la configuration matérielle répertoriée. Si vous le souhaitez, sélectionnez Modifier la configuration pour sélectionner la configuration matérielle appropriée à votre charge de travail.
6. Sélectionnez le curseur vCores si vous souhaitez modifier le nombre de vCores disponibles dans votre base de données sous le niveau de service usage général.
7. Sélectionnez Appliquer.

Azure CLI

Cet exemple de code appelle az sql db update pour inverser la migration d’une base de données Hyperscale existante vers le niveau de service usage général. Vous devez spécifier l’édition et l’objectif du service. Vous pouvez sélectionner soit Provisioned soit Serverless comme modèle de calcul cible.

Remplacez resourceGroupName, serverName, databaseName et serviceObjective par les valeurs appropriées avant d’exécuter l’exemple de code suivant :

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

Vous pouvez aussi inclure l’argument maxsize. Si la valeur maxsize dépasse la taille maximale valide pour l’objectif de service cible, une erreur est retournée. Si l’argument maxsize n’est pas spécifié, l’opération est définie par défaut sur la taille maximale disponible pour l’objectif de service donné. L'exemple suivant spécifie 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

Vous pouvez surveiller les opérations d’une base de données Hyperscale pendant que l’opération est en cours.

PowerShell

Cet exemple de code utilise la cmdlet Set-AzSqlDatabase pour inverser la migration d’une base de données existante du niveau de service Hyperscale vers le niveau de service usage général. Vous devez spécifier l’édition et l’objectif du service. Vous pouvez sélectionner soit Provisioned soit Serverless comme niveau de calcul cible.

Remplacez $resourceGroupName, $serverName, $databaseName, $serviceObjective et $computeModel par les valeurs appropriées avant d’exécuter cet exemple de code :

$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

Vous pouvez aussi inclure l’argument maxsize. Si la valeur maxsize dépasse la taille maximale valide pour l’objectif de service cible, une erreur est retournée. Si l’argument maxsize n’est pas spécifié, l’opération est définie par défaut sur la taille maximale disponible pour l’objectif de service donné. L'exemple suivant spécifie 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

Vous pouvez surveiller les opérations d’une base de données Hyperscale pendant que l’opération est en cours.

Transact-SQL

Pour inverser la migration d’une base de données Hyperscale vers le niveau de service Usage général avec Transact-SQL, commencez par vous connecter à la base de données master sur votre serveur SQL logique à l’aide de SQL Server Management Studio (SSMS) ou d’Azure Data Studio.

Vous devez spécifier l’édition et l’objectif du service dans l’instruction ALTER DATABASE.

Cet exemple d’instruction migre une base de données appelée mySampleDatabase vers le niveau de service usage général avec l’objectif de service GP_Gen5_4. Remplacez le nom de la base de données et l’objectif de service par les valeurs appropriées avant d’exécuter l’instruction.

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

Vous pouvez aussi inclure l’argument maxsize. Si la valeur maxsize dépasse la taille maximale valide pour l’objectif de service cible, une erreur est retournée. Si l’argument maxsize n’est pas spécifié, l’opération est définie par défaut sur la taille maximale disponible pour l’objectif de service donné. L'exemple suivant spécifie maxsize :

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

Vous pouvez surveiller les opérations d’une base de données Hyperscale pendant que l’opération est en cours.

Surveiller les opérations pour une base de données Hyperscale

Vous pouvez surveiller l’état des opérations en cours ou terminées récemment pour une base de données Azure SQL Database à l’aide du Portail Azure, d’Azure CLI, de PowerShell ou de Transact-SQL.

Sélectionnez l’onglet de votre méthode préférée pour surveiller les opérations.

Portail

Le portail Azure affiche une notification pour une base de données dans Azure SQL Database lorsqu’une opération telle qu’une migration, une migration inversée ou une restauration est en cours.

1. Accédez à la base de données dans le Portail Azure.
2. Dans la barre de navigation gauche, sélectionnez Vue d’ensemble.
3. Passez en revue la section Notifications en bas du volet droit. Si des opérations sont en cours, une notification s’affiche.
4. Sélectionnez la notification pour en afficher les détails.
5. Le volet Opérations en cours s’ouvre. Passez en revue les détails des opérations en cours.

Azure CLI

Cet exemple de code appelle az sql db op list pour retourner les opérations récentes ou en cours pour une base de données dans Azure SQL Database.

Remplacez resourceGroupName, serverName, databaseName et serviceObjective par les valeurs appropriées avant d’exécuter l’exemple de code suivant :

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

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

PowerShell

La cmdlet Get-AzSqlDatabaseActivity retourne les opérations récentes ou en cours pour une base de données dans Azure SQL Database.

Définissez la valeur des paramètres $resourceGroupName, $serverName et $databaseName pour votre base de données avant d’exécuter l’exemple de code :

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

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

Transact-SQL

Pour monitorer les opérations d’une base de données Hyperscale, connectez-vous d’abord à la base de données master sur votre serveur logique à l’aide de SQL Server Management Studio (SSMS), Azure Data Studio ou du client de votre choix pour exécuter les commandes Transact-SQL.

Interrogez la vue de gestion dynamique sys.dm_operation_status pour passer en revue les informations sur les opérations récemment effectuées sur les bases de données sur votre [serveur logique][logical-servers.md].

Cet exemple de code retourne tous les entiers de sys.dm_operation_status de la base de données spécifiée, triés par les opérations qui ont commencé le plus récemment. Remplacez le nom de la base de données par la valeur appropriée avant d’exécuter l’exemple de code.

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

Consulter les bases de données du niveau de service Hyperscale

Après la migration d’une base de données vers Hyperscale ou la reconfiguration d’une base de données au sein du niveau de service Hyperscale, vous pouvez afficher et/ou documenter la configuration de votre base de données Hyperscale.

Portail

Le portail Azure affiche une liste de toutes les bases de données sur un serveur logique. La colonne Niveau tarifaire inclut le niveau de service de chaque base de données.

1. Accédez à votre serveur logique dans le Portail Azure.
2. Dans la barre de navigation gauche, sélectionnez Vue d’ensemble.
3. Descendez jusqu’à la liste des ressources en bas du volet. La fenêtre affiche les SQL pools élastiques et les bases de données sur le serveur logique.
4. Passez en revue la colonne du niveau tarifaire pour identifier les bases de données dans le niveau de service Hyperscale.

Azure CLI

Cet exemple de code Azure CLI appelle az sql db list pour répertorier les bases de données Hyperscale sur un serveur logique avec leur nom, leur emplacement, leur objectif de niveau de service, leur taille maximale et le nombre de réplicas à haute disponibilité.

Remplacez resourceGroupName et serverName par les valeurs appropriées avant d’exécuter l’exemple de code suivant :

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

La cmdlet Get-AzSqlDatabase Azure PowerShell retourne une liste de bases de données Hyperscale sur un serveur logique avec son nom, son emplacement, son objectif de niveau de service, sa taille maximale et son nombre de réplicas à haute disponibilité.

Définissez la valeur des paramètres $resourceGroupName et $serverName pour votre base de données avant d’exécuter l’exemple de code :

$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

Passez en revue la colonne de l’édition pour identifier les bases de données dans le niveau de service Hyperscale.

Transact-SQL

Pour passer en revue les niveaux de service de toutes les bases de données Hyperscale sur un serveur logique avec Transact-SQL, connectez-vous d’abord à la base de données master à l’aide de SQL Server Management Studio (SSMS) ou d’Azure Data Studio.

Interrogez la vue de catalogue système sys.database_service_objectives pour passer en revue les bases de données dans le niveau de service 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

Contenu connexe

En savoir plus sur les bases de données Hyperscale dans les articles suivants :

• Démarrage rapide : Créer une base de données Hyperscale dans Azure SQL Database
• Niveau de service Hyperscale
• Questions fréquentes (FAQ) sur le niveau Hyperscale dans Azure SQL Database
• Réplicas secondaires Hyperscale
• Questions fréquentes (FAQ) sur les réplicas nommés Hyperscale Azure SQL Database