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

Cet article décrit la procédure de mise à l’échelle des ressources de calcul et de stockage disponibles pour Azure SQL Database 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 :

• Transact-SQL
• Azure portal
• PowerShell
• Azure CLI
• REST API

Impact

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

1. 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.

2. 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 permet de réduire l’impact de l’abandon des transactions durables.

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 :

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');

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.

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

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

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

$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

$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, l’autorisation 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 l’API REST, des autorisations Azure RBAC sont nécessaires, en particulier les rôles Azure RBAC Contributeur, Contributeur SQL DB ou Contributeur SQL Server. Pour plus d’informations, consultez Rôles intégrés Azure RBAC.

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 l’article relatif aux sauvegardes Azure SQL Database.
• 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, 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.

Facturation

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.

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.

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.

Contenu connexe

Pour les limites de ressources globales, consultez Limites de ressources vCore Azure SQL Database - bases de données uniques et Limites de ressources DTU Azure SQL Database - bases de données uniques.