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 :

Important

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

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.

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 :

Niveau de service Base de données unique de base,
Standard (S0-S1)
Pool élastique de base,
Standard (S2-S12),
Base de données unique ou pool élastique à usage général
Base de données unique ou pool élastique Premium ou critique pour l’entreprise Hyperscale
Base de données unique de base,
Standard (S0-S1)
•  Latence constante indépendante de l’espace utilisé
•  Généralement moins de 5 minutes
•  Latence proportionnelle à l’espace de base de données utilisé en raison de la copie des données
•  En règle générale, moins de 1 minute par Go d’espace utilisé
•  Latence proportionnelle à l’espace de base de données utilisé en raison de la copie des données
•  En règle générale, moins de 1 minute par Go d’espace utilisé
•  Latence proportionnelle à l’espace de base de données utilisé en raison de la copie des données
•  En règle générale, moins de 1 minute par Go d’espace utilisé
Pool élastique de base,
Standard (S2-S12),
Base de données unique ou pool élastique à usage général
•  Latence proportionnelle à l’espace de base de données utilisé en raison de la copie des données
•  En règle générale, moins de 1 minute par Go d’espace utilisé
•  Pour les bases de données individuelles, latence constante indépendante de l’espace utilisé
•  En règle générale, moins de 5 minutes pour les bases de données individuelles
•  Pour les pools élastiques, proportionnelle au nombre de bases de données
•  Latence proportionnelle à l’espace de base de données utilisé en raison de la copie des données
•  En règle générale, moins de 1 minute par Go d’espace utilisé
•  Latence proportionnelle à l’espace de base de données utilisé en raison de la copie des données
•  En règle générale, moins de 1 minute par Go d’espace utilisé
Base de données unique ou pool élastique Premium ou critique pour l’entreprise •  Latence proportionnelle à l’espace de base de données utilisé en raison de la copie des données
•  En règle générale, moins de 1 minute par Go d’espace utilisé
•  Latence proportionnelle à l’espace de base de données utilisé en raison de la copie des données
•  En règle générale, moins de 1 minute par Go d’espace utilisé
•  Latence proportionnelle à l’espace de base de données utilisé en raison de la copie des données
•  En règle générale, moins de 1 minute par Go d’espace utilisé
•  Latence proportionnelle à l’espace de base de données utilisé en raison de la copie des données
•  En règle générale, moins de 1 minute par Go d’espace utilisé
Hyperscale N/A N/A N/A •  Latence constante indépendante de l’espace utilisé
•  Généralement moins de 2 minutes

Notes

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

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

Notes

La propriété de redondance de zone restera la même par défaut lors de la mise à l’échelle du niveau critique pour l’entreprise au niveau usage général. La latence pour ce passage à une version antérieure lorsque la redondance de zone est activée, ainsi que la latence pour le basculement vers la redondance de zone pour le niveau usage général, sera proportionnelle à la taille de la base de données.

Annulation des modifications

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

Le portail Azure

Dans le panneau de vue d’ensemble de la base de données, accédez à Notifications, puis cliquez sur la vignette indiquant qu’une opération est en cours :

Opération en cours

Ensuite, cliquez sur le bouton intitulé Annuler cette opération.

Annulation de l’opération en cours

PowerShell

À partir d’une invite de commande PowerShell, définissez les valeurs $resourceGroupName, $serverName et $databaseName, puis exécutez la commande suivante :

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

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, Azure SQL Database alloue automatiquement 30 % de stockage supplémentaire pour le journal des transactions.
  • 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 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. Le coût de tempdb est inclus dans le prix. Pour plus d'informations sur le prix du stockage, consultez Tarification d'Azure SQL Database.

Important

Dans certaines circonstances, vous devrez peut-être réduire une base de données pour récupérer l’espace inutilisé. Pour plus d’informations, consultez Gérer l’espace des fichiers dans 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.

Important

Dans certaines circonstances, vous devrez peut-être réduire une base de données pour récupérer l’espace inutilisé. Pour plus d’informations, consultez Gérer l’espace des fichiers dans 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 la taille de calcul est inférieure 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.exe pour importer et exporter les données.

Étapes suivantes

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.