Mettre à l’échelle des ressources de base de données unique dans Azure SQL Database

Article
09/17/2024

Cet article décrit la procédure de mise à l’échelle des ressources de calcul et de stockage disponibles pour une base de données Azure SQL dans le niveau de calcul configuré. Sinon, le niveau de calcul serverless offre une mise à l’échelle automatique du calcul et facture le calcul utilisé par seconde.

Après avoir choisi le nombre de vCores ou de DTU, vous pouvez mettre à l’échelle supérieure ou inférieure une base de données unique de façon dynamique sur la base de votre expérience avec :

Important

Dans certaines circonstances, vous devriez peut-être réduire une base de données pour récupérer l’espace inutilisé. Pour plus d’informations, consultez la section Gérer l’espace de fichiers pour les bases de données dans Azure SQL Database.

Remarque

Microsoft Entra ID était précédemment connu sous le nom d’Azure Active Directory (Azure AD).

Impact

La modification du niveau de service ou de la taille de calcul implique principalement que le service suive les étapes ci-après :

Création d’une instance de calcul pour la base de données.

Une nouvelle instance de calcul est créée pour le niveau de service et la taille de calcul demandés. Pour certaines combinaisons de modifications du niveau de service et de la taille de calcul, un réplica de la base de données doit être créé dans la nouvelle instance de calcul, ce qui implique de copier des données et peut avoir une incidence substantielle sur la latence globale. Malgré tout, la base de données reste en ligne pendant cette étape, et les connexions continuent d’être dirigées vers la base de données dans l’instance de calcul d’origine.
Basculement de l’acheminement des connexions vers la nouvelle instance de calcul.

Les connexions existantes à la base de données dans l’instance de calcul d’origine sont supprimées. Toutes les nouvelles connexions sont établies vers la base de données de la nouvelle instance de calcul. Pour certaines combinaisons de modifications du niveau de service et de la taille de calcul, les fichiers de base de données sont détachés, puis rattachés pendant ce basculement. Malgré tout, le basculement peut entraîner une brève interruption de service au cours de laquelle la base de données reste inaccessible pendant moins de 30 secondes, et le plus souvent, pendant quelques secondes seulement. Si des transactions longues sont en cours d’exécution quand des connexions sont supprimées, la durée de cette étape peut prendre plus de temps pour permettre la récupération des transactions abandonnées. La récupération de base de données accélérée dans Azure SQL permet de réduire l’impact de l’abandon des transactions durables.

Important

Aucune donnée n’est perdue au cours des étapes du workflow. Assurez-vous que vous avez implémenté une logique de nouvelle tentative dans les applications et les composants qui utilisent Azure SQL Database pendant la modification du niveau de service.

Latence

La latence estimée pour modifier le niveau de service, mettre à l’échelle la taille de calcul d’une base de données unique ou d’un pool élastique, déplacer une base de données dans un pool élastique ou hors de celui-ci, ou déplacer une base de données entre des pools élastiques est paramétrée comme suit :

Latence de mise à l’échelle de la base de données	Vers la base de données unique, base de données unique standard (S0-S1)	Vers une base de données unique Standard (S2-S12), base de données unique usage général , base de données élastique base , base de données mise en pool élastique standard , base de données mise en pool à usage général	Vers une base de données unique Premium ou une base de données mise en pool, base de données unique critique pour l’entreprise ou une base de données mise en pool	Vers une base de données unique Hyperscale ou une base de données mise en pool
À partir d’un base de données unique base, base de données standard (S0-S1)	• Temps de latence constant indépendant de l’espace utilisé. • En général, moins de 5 minutes.	• Latence proportionnelle à l’espace de base de données utilisé pour la copie des données. • En général, moins d’une minute par Go d’espace utilisé.	• Latence proportionnelle à l’espace de base de données utilisé pour la copie des données. • En général, moins d’une minute par Go d’espace utilisé.	• Latence proportionnelle à l’espace de base de données utilisé pour la copie des données. • En général, moins d’une minute par Go d’espace utilisé.
À partir d’une base de données mise en pool de base, d’une base de données unique standard (S2-S12) , d’une base de données mise en pool standard , d’une base de données unique à usage général ou d’une base de données mise en pool	• Latence proportionnelle à l’espace de base de données utilisé pour la copie des données. • En général, moins d’une minute par Go d’espace utilisé.	• Pour les bases de données uniques, temps de latence constant indépendant de l’espace utilisé. • En général, moins de 5 minutes pour les bases de données uniques. • Pour les pools élastiques, latence proportionnelle au nombre de bases de données.	• Latence proportionnelle à l’espace de base de données utilisé pour la copie des données. • En général, moins d’une minute par Go d’espace utilisé.	• Latence proportionnelle à l’espace de base de données utilisé pour la copie des données. • En général, moins d’une minute par Go d’espace utilisé.
À partir d’une base de données unique Premium ou d’une base de données mise en pool, d’une base de données unique critique pour l’entreprise ou d’une base de données mise en pool	• Latence proportionnelle à l’espace de base de données utilisé pour la copie des données. • En général, moins d’une minute par Go d’espace utilisé.	• Latence proportionnelle à l’espace de base de données utilisé pour la copie des données. • En général, moins d’une minute par Go d’espace utilisé.	• Latence proportionnelle à l’espace de base de données utilisé pour la copie des données. • En général, moins d’une minute par Go d’espace utilisé.	• Latence proportionnelle à l’espace de base de données utilisé pour la copie des données. • En général, moins d’une minute par Go d’espace utilisé.
À partir d’une base de données unique Hyperscale ou d’une base de données mise en pool	S/O	Consultez Migration inverse à partir d’Hyperscale pour connaître les scénarios et les limitations pris en charge.	S/O	• Temps de latence constant indépendant de l’espace utilisé. • En général, moins de 2 minutes.

Remarque

En outre, pour des bases de données standard (S2-S12) et à usage général, la latence du déplacement d’une base de données à l’intérieur ou à l’extérieur d’un pool élastique, ou entre des pools élastiques, sera proportionnelle à la taille de la base de données si celle-ci utilise un stockage de partage de fichiers Premium (PFS).
En cas de déplacement d’une base de données vers/à partir d’un pool élastique, seul l’espace utilisé par la base de données a un impact sur la latence, pas l’espace utilisé par le pool élastique.
Pour déterminer si une base de données utilise un stockage PFS, exécutez la requête suivante dans le contexte de la base de données. Si la valeur de la colonne AccountType est PremiumFileStorage ou PremiumFileStorage-ZRS, la base de données utilise un stockage 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');

Remarque

La propriété de redondance de zone restera la même par défaut lors de la mise à l’échelle d’une base de données unique du niveau critique pour l’entreprise au niveau usage général.
La latence de l’opération de mise à l’échelle lorsque la redondance de zone est modifiée pour une base de données unique usage général est proportionnelle à la taille de la base de données.

Conseil

Pour surveiller des opérations en cours, voir : Gérer des opérations à l’aide de l’API REST SQL, Gérer des opérations à l’aide de l’interface de ligne de commande, Surveiller des opérations à l’aide de T-SQL et les deux commandes PowerShell suivantes : Get-AzSqlDatabaseActivity et Stop-AzSqlDatabaseActivity.

Surveiller ou annuler les modifications de mise à l’échelle

Vous pouvez surveiller et annuler une modification du niveau de service ou une opération de remise à l’échelle du calcul.

Sur la page Vue d’ensemble de la base de données SQL, recherchez la bannière indiquant qu’une opération de mise à l’échelle est en cours et sélectionnez le lien Voir plus pour accéder au déploiement en cours.

Sur la page Opérations en cours qui s’affiche, sélectionnez Annuler cette opération.

Pour appeler les commandes PowerShell sur un ordinateur, vous devez installer localement le Package Az version 9.7.0 ou une version plus récente. Vous pouvez également utiliser Azure Cloud Shell pour exécuter Azure PowerShell sur shell.azure.com.

Tout d’abord, connectez-vous à Azure et définissez le contexte approprié pour votre abonnement :

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

Pour surveiller les opérations sur une base de données, notamment les opérations de mise à l’échelle, utilisez Get-AzSqlDatabaseActivity. L’exemple suivant retourne un OperationId pour chaque opération en cours d’exécution.

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

Pour annuler une opération asynchrone comme une échelle de base de données, identifiez l’opération, puis utilisez Stop-AzSqlDatabaseActivity avec un élément spécifique OperationId, comme dans l’exemple suivant.

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

À partir d’un terminal Cloud Shell, utilisez l’exemple de commande suivant pour identifier les opérations en cours d’exécution. À partir d’un terminal Cloud Shell, définissez les variables $resourceGroupName, $serverName et $databaseName, puis exécutez la commande suivante :

$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

Pour arrêter une opération asynchrone comme une échelle de base de données, à partir d’un terminal Cloud Shell, définissez les variables $resourceGroupName, $serverName et $databaseName, puis exécutez la commande suivante :

$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"
}

autorisations

Pour mettre à l’échelle des bases de données via Transact-SQL : ALTER DATABASE est utilisée. Pour mettre à l’échelle une base de données, une connexion doit être la connexion administrateur du serveur (créée lorsque le serveur logique Azure SQL Database a été provisionné), l’administrateur Microsoft Entra du serveur, un membre du rôle de base de données dbmanager dans master, un membre du rôle de base de données db_owner dans la base de données actuelle, ou dbo de la base de données. Pour en savoir plus, consultez ALTER DATABASE.

Pour mettre à l’échelle des bases de données via le portail Azure, PowerShell, Azure CLI ou API REST : des autorisations Azure RBAC sont nécessaires, en particulier le Contributeur, rôle Collaborateur SQL DB ou Contributeur SQL Server rôles RBAC Azure. Pour plus d’informations, consultez Azure RBAC : pour les ressources Azure.

Considérations supplémentaires

Si vous effectuez la mise à niveau vers un niveau de service ou une taille de calcul supérieurs, la taille maximale de la base de données n’augmente pas, à moins que vous n’en fassiez la demande (maxsize).
Pour pouvoir passer à une version antérieure, l’espace utilisé par la base de données doit être inférieur à la taille maximale autorisée pour le service cible et la taille de calcul.
Lorsque vous rétrogradez du niveau Premium vers le niveau Standard, un coût de stockage supplémentaire s’applique si (1) la taille maximale de la base de données est prise en charge dans la taille de calcul cible et (2) la taille maximale dépasse la quantité de stockage incluse dans la taille de calcul cible. Par exemple, si une base de données P1 avec une taille maximale de 500 Go est rétrogradée en S3, un coût de stockage supplémentaire s’applique, car S3 prend en charge une taille maximale de 1 To et la quantité de stockage incluse est de seulement 250 Go. Par conséquent, la quantité de stockage supplémentaire est de 500 Go - 250 Go = 250 Go. Pour la tarification du stockage supplémentaire, consultez Tarification d’Azure SQL Database. Si la quantité réelle d’espace utilisé est inférieure à la quantité de stockage incluse, ce coût supplémentaire peut être évité en réduisant la taille maximale de la base de données à la quantité incluse.
Lors de la mise à niveau d’une base de données pour laquelle la géoréplication est activée, vous devez commencer par mettre à niveau les bases de données secondaires associées vers le niveau de service et la taille de calcul souhaités avant de procéder à la mise à niveau de la base de données primaire (conseil général pour de meilleures performances). Lors de la mise à niveau vers une autre édition, il est impératif que la base de données secondaire soit mise à niveau en premier.
Lors de la mise à niveau descendante d’une base de données pour laquelle la géoréplication est activée, vous devez commencer par mettre à niveau les bases de données primaires associées vers le niveau de service et la taille de calcul inférieurs souhaités avant de procéder à la mise à niveau descendante de la base de données secondaire (conseil général pour de meilleures performances). Lors de la rétrogradation vers une autre édition, il est impératif que la base de données primaire soit rétrogradée en premier.
Les offres de service de restauration sont différentes selon les niveaux de service. Si vous repassez au niveau de service De base, la rétention des fichiers de sauvegarde sera de plus courte durée. Consultez Sauvegardes automatisées dans la base de données Azure SQL.
Les nouvelles propriétés de la base de données ne sont appliquées qu’une fois les modifications terminées.
Quand la copie des données est nécessaire pour mettre à l’échelle une base de données (voir Latence) lors de la modification du niveau de service, une forte utilisation des ressources simultanément avec l’opération de mise à l’échelle peut entraîner des temps de mise à l’échelle plus longs. Avec la récupération de base de données accélérée (ADR), l’annulation des transactions longues n’est pas une source importante de délai, mais une forte utilisation simultanée des ressources peut réduire les ressources de calcul, de stockage et de bande passante réseau pour la mise à l’échelle, en particulier pour les tailles de calcul les plus petites.

Billing

Vous êtes facturé pour chaque heure d’existence de la base de données avec le niveau de service le plus élevé, la taille de calcul appliquée pendant cette heure, quel que soit l’usage, ou si la base de données a été active pendant moins d’une heure. Par exemple, si vous avez créé une base de données unique et que vous l’avez supprimée cinq minutes après, votre facture mentionne le coût d’une heure de base de données.

Modifier la taille de stockage

Modèle d’achat vCore

Le stockage peut être configuré jusqu’à la limite de taille maximale du stockage de données par incréments de 1 Go. Le stockage de données minimum configurable est de 1 Go. Pour les limites de stockage de données dans chaque objectif de service, consultez les pages de documentation sur les limites de ressources pour les Limites de ressources pour des bases de données uniques suivant le modèle d’achat vCore et les Limites de ressources pour des bases de données uniques suivant le modèle d’achat DTU.
Vous pouvez configurer le stockage de données d’une base de données unique en augmentant ou en diminuant sa taille maximale à l’aide du portail Azure, de Transact-SQL, de PowerShell, d’Azure CLI ou de l’API REST. Si la valeur de taille maximale est spécifiée en octets, elle doit être un multiple de 1 Go (1073741824 octets).
Le volume de données qui peut être stocké dans les fichiers de données d’une base de données est limité par la taille maximale configurée pour le stockage de données. En plus de ce stockage, la base de données Azure SQL ajoute automatiquement 30 % de stockage supplémentaire pour le journal des transactions. Le prix du stockage d’une base de données unique ou d’un pool élastique est égal à la somme des volumes de stockage de données et de stockage des journaux de transactions multipliée par le prix unitaire du stockage du niveau de service. Par exemple, si le stockage de données est défini sur 10 Go, le stockage supplémentaire du journal des transactions est de 10 Go * 30 % = 3 Go, et la quantité totale de stockage facturable est de 10 Go + 3 Go = 13 Go.

Remarque

La taille maximale du fichier journal de transactions est gérée automatiquement et, dans certains cas, peut être supérieure à 30 % de la taille maximale du stockage de données. Cela n’augmente pas le prix du stockage pour la base de données.
Azure SQL Database alloue automatiquement 32 Go par vCore pour la base de données tempdb. Quel que soit le niveau de service, tempdb se trouve toujours sur le stockage SSD local. Le coût de tempdb est inclus dans le prix d’une base de données unique ou d’un pool élastique.
Pour plus d’informations sur le prix du stockage, consultez Tarification d’Azure SQL Database.

Important

Modèle d’achat DTU

Le prix des DTU pour une base de données unique inclut une certaine quantité de stockage sans coût supplémentaire. Un espace de stockage en plus du volume inclus peut être approvisionné pour un coût supplémentaire jusqu’à la limite de taille par incréments de 250 Go jusqu’à 1 To, puis par incréments de 256 Go au-delà de 1 To. Pour les quantités de stockage et limites de taille maximale incluses, voir l’article Base de données unique : tailles de stockage et tailles de calcul.
Vous pouvez approvisionner un espace de stockage supplémentaire pour une base de données unique en augmentant la taille maximale à l’aide du Portail Azure, de Transact-SQL, de PowerShell, d’Azure CLI ou de l’API REST.
Le prix de l’espace de stockage supplémentaire pour une base de données unique est égal à la quantité de stockage supplémentaire multiplié par le prix unitaire du stockage supplémentaire pour le niveau de service. Pour plus d’informations sur le prix du stockage supplémentaire, consultez Tarification d’Azure SQL Database.

Important

Base de données géorépliquée

Pour changer la taille d’une base de données secondaire répliquée, changez la taille de la base de données primaire. Cette modification est ensuite répliquée et implémentée également sur la base de données secondaire.

Contraintes P11 et P15 lorsque la taille maximale est supérieure à 1 To

Un espace de stockage supérieur à 1 To au niveau Premium est actuellement disponible dans les toutes régions sauf les suivantes : Chine Est, Chine Nord, Allemagne Centre et Allemagne Nord-Est. Dans ces régions, l’espace de stockage maximal au niveau Premium est limité à 1 To. Les considérations et limitations suivantes s’appliquent aux bases de données P11 et P15 avec une taille maximale supérieure à 1 To :

Si une base de données P11 ou P15 présentait une taille maximale supérieure à 1 To, vous pouvez uniquement la restaurer ou la copier sous la forme d’une base de données P11 ou P15. Par la suite, vous pourrez remettre à l’échelle la base de données avec une autre taille de calcul à condition que l’espace alloué lors de cette opération ne dépasse pas les limites de taille maximale de la nouvelle taille de calcul.
Pour les scénarios de géoréplication active :
- Configuration d’une relation de géoréplication : Si la base de données primaire est P11 ou P15, les bases de données secondaires doivent également être P11 ou P15. Les bases de données dont les tailles de calcul sont inférieures sont rejetées en tant que réplicas secondaires, car elles ne peuvent pas prendre en charge plus de 1 To.
- Mise à niveau de la base de données primaire dans une relation de géoréplication : Le fait de modifier la taille maximale de la base de données primaire pour plus de 1 To déclenche la même modification sur la base de données secondaire. Les deux mises à niveau doivent aboutir pour que la modification sur la base de données principale prenne effet. Des limitations de région pour les options de plus de 1 To s’appliquent. Si la base de données secondaire se situe dans une région qui ne prend pas en charge plus de 1 To, la base de données primaire n’est pas mise à niveau.
L’utilisation du service Import/Export pour le chargement des bases de données P11/P15 avec plus de 1 To n’est pas prise en charge. Utilisez SqlPackage pour importer et exporter des données.

Partager via

Mettre à l’échelle des ressources de base de données unique dans Azure SQL Database

Impact

Latence

Surveiller ou annuler les modifications de mise à l’échelle

autorisations

Considérations supplémentaires

Billing

Modifier la taille de stockage

Modèle d’achat vCore

Modèle d’achat DTU

Base de données géorépliquée

Contraintes P11 et P15 lorsque la taille maximale est supérieure à 1 To

Commentaires

Ressources supplémentaires

Partager via

Mettre à l’échelle des ressources de base de données unique dans Azure SQL Database

Impact

Latence

Surveiller ou annuler les modifications de mise à l’échelle

autorisations

Considérations supplémentaires

Billing

Modifier la taille de stockage

Modèle d’achat vCore

Modèle d’achat DTU

Base de données géorépliquée

Contraintes P11 et P15 lorsque la taille maximale est supérieure à 1 To

Contenu connexe

Commentaires

Ressources supplémentaires