Modèle d’achat vCore - Azure SQL Database

Article
03/25/2025

s’applique à : Azure SQL Database

Cet article passe en revue le modèle d’achat vCore pour Azure SQL Database.

Aperçu

Un cœur virtuel (vCore) représente un processeur logique et vous offre la possibilité de choisir les caractéristiques physiques du matériel (par exemple, le nombre de cœurs, la mémoire et la taille de stockage). Le modèle d’achat vCore vous offre une flexibilité, un contrôle, une transparence de la consommation de ressources individuelle et un moyen simple de traduire les exigences de charge de travail locales vers le cloud. Ce modèle optimise le prix et vous permet de choisir des ressources de calcul, de mémoire et de stockage en fonction des besoins de votre charge de travail.

Dans le modèle d’achat vCore, vos coûts dépendent du choix et de l’utilisation de :

Niveau de service
Configuration matérielle
Ressources de calcul (nombre de vCores et quantité de mémoire)
Stockage de base de données réservée
Stockage de sauvegarde réel

Important

Les ressources de calcul, les E/S et le stockage des données et des journaux sont facturés par base de données ou pool élastique. Le stockage de sauvegarde est facturé par base de données. Pour plus d’informations sur la tarification, consultez la page de tarification Azure SQL Database.

Comparer les modèles d’achat vCore et DTU

Le modèle d’achat vCore utilisé par Azure SQL Database offre plusieurs avantages sur le modèle d’achat DTU :

Limites de calcul, de mémoire, d’E/S et de stockage supérieures.
Choix de la configuration matérielle pour mieux correspondre aux exigences de calcul et de mémoire de la charge de travail.
Remises tarifaires pour Azure Hybrid Benefit (AHB).
Plus de transparence dans les détails matériels qui alimentent le calcul, ce qui facilite la planification des migrations à partir de déploiements locaux.
La tarification des instances réservées est disponible uniquement pour le modèle d’achat vCore.
Plus grande granularité de mise à l’échelle avec plusieurs tailles de calcul disponibles.

Consultez les différences entre les modèles d’achat vCore et DTU pour vous aider à choisir.

Calcul

Le modèle d’achat vCore a un niveau de calcul approvisionné et un niveau de calcul serverless. Dans le niveau de calcul provisionné, le coût de calcul reflète la capacité de calcul totale approvisionnée en continu pour l’application indépendamment de l’activité de charge de travail. Choisissez l’allocation de ressources qui convient le mieux à vos besoins métier en fonction des besoins en vCore et en mémoire, puis augmentez et diminuez les ressources en fonction des besoins de votre charge de travail. Dans le niveau de calcul serverless pour Azure SQL Database, les ressources de calcul sont automatiquement mises à l’échelle en fonction de la capacité de charge de travail et facturées pour la quantité de calcul utilisée, par seconde.

Pour résumer :

Bien que le niveau de calcul provisionné fournit une quantité spécifique de ressources de calcul qui sont approvisionnées en permanence indépendamment de l’activité de charge de travail, le niveau de calcul serverless met automatiquement à l’échelle les ressources de calcul en fonction de l’activité de charge de travail.
Bien que le niveau de calcul provisionné facture la quantité de calcul provisionnée à un prix fixe par heure, le niveau de calcul sans serveur facture la quantité de calcul utilisée, par seconde.

Quel que soit le niveau de calcul, trois réplicas secondaires haute disponibilité supplémentaires sont automatiquement alloués dans le niveau de service Critique pour l’entreprise pour fournir une résilience élevée face aux défaillances et aux basculements rapides. Ces répliques supplémentaires rendent le coût environ 2,7 fois supérieur à celui du niveau de service à Usage général. De même, le coût de stockage plus élevé par Go dans le niveau de service Critique pour l’entreprise reflète les limites d’E/S supérieures et la latence inférieure du stockage SSD local.

Dans Hyperscale, les clients contrôlent le nombre de réplicas à haute disponibilité supplémentaires de 0 à 4 pour obtenir le niveau de résilience requis par leurs applications tout en contrôlant les coûts.

Pour plus d’informations sur le calcul dans Azure SQL Database, consultez ressources de calcul (processeur et mémoire).

Limites des ressources

Pour les limites de ressources vCore, passez en revue les configurations matérielles disponibles , puis passez en revue les limites de ressources pour :

serveurs logiques
Bases de données uniques
bases de données dans des pools élastiques

Stockage des données et des fichiers journaux

Les facteurs suivants affectent la quantité de stockage utilisée pour les fichiers journaux et les données, et s’appliquent aux niveaux Usage général et Critique pour l’entreprise.

Chaque taille de calcul prend en charge une taille de données maximale configurable, avec une valeur par défaut de 32 Go.
Lorsque vous configurez la taille maximale des données, un stockage facturable supplémentaire de 30 % est automatiquement ajouté pour le fichier journal.
Dans le niveau de service Usage général, tempdb utilise le stockage SSD local et ce coût de stockage est inclus dans le prix vCore.
Dans le niveau de service Entreprise Critique, tempdb partage le stockage SSD local avec les fichiers de données et les fichiers journaux, et le coût de stockage de tempdb est inclus dans le prix vCore.
Dans les niveaux Usage général et Critique pour l’entreprise, vous êtes facturé pour la taille de stockage maximale configurée pour une base de données ou un pool élastique.
Pour SQL Database, vous pouvez sélectionner n’importe quelle taille de données maximale comprise entre 1 Go et la taille de stockage prise en charge, par incréments de 1 Go.

Les considérations relatives au stockage suivantes s’appliquent à Hyperscale :

La taille maximale de stockage des données est définie sur 128 To et n’est pas configurable.
Vous êtes facturé uniquement pour le stockage de données alloué, et non pour le stockage maximal de données.
Le stockage des journaux n’est pas facturé.
tempdb utilise le stockage SSD local et son coût est inclus dans le prix vCore. Pour monitorer la taille de stockage de données actuellement allouée et utilisée dans SQL Database, utilisez respectivement les métriques Azure Monitor allocated_data_storage et storage.

Pour monitorer la taille de stockage actuellement allouée et utilisée par les données individuelles et les fichiers journaux dans une base de données avec T-SQL, utilisez la vue sys.database_files et la fonction FILEPROPERTY(... , 'SpaceUsed').

Conseil

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

Stockage de sauvegarde

Le stockage des sauvegardes de base de données est alloué pour prendre en charge les capacités de restauration à un point dans le temps (PITR) et de rétention à long terme (LTR) du SQL Database. Ce stockage est distinct du stockage de données et de fichiers journaux et est facturé séparément.

PITR: Dans les niveaux Usage général et Critique pour l’entreprise, les sauvegardes de base de données individuelles sont copiées automatiquement dans le stockage Azure. La taille de stockage augmente dynamiquement à mesure que de nouvelles sauvegardes sont créées. Le stockage est utilisé par les sauvegardes complètes, différentielles et de journal des transactions. La consommation de stockage dépend du taux de modification de la base de données et de la période de rétention configurée pour les sauvegardes. Vous pouvez configurer une période de rétention distincte pour chaque base de données comprise entre 1 et 35 jours pour SQL Database. Une quantité de stockage de sauvegarde égale à la taille maximale configurée des données est fournie sans frais supplémentaires.
LTR: vous pouvez également configurer la rétention à long terme des sauvegardes complètes pendant 10 ans. Si vous configurez une stratégie LTR, ces sauvegardes sont stockées automatiquement dans le stockage Blob Azure, mais vous pouvez contrôler la fréquence à laquelle les sauvegardes sont copiées. Pour répondre à différentes exigences de conformité, vous pouvez sélectionner différentes périodes de rétention pour les sauvegardes hebdomadaires, mensuelles et/ou annuelles. La configuration que vous choisissez détermine la quantité de stockage utilisée pour les sauvegardes LTR. Pour plus d’informations, consultez la rétention à long terme des sauvegardes .

Pour le stockage de sauvegarde dans Hyperscale, consultez sauvegardes automatisées pour les bases de données Hyperscale.

Niveaux de service

Les options de niveau de service dans le modèle d’achat vCore incluent Usage général, Critique pour l’entreprise et Hyperscale. Le niveau de service détermine généralement le type de stockage et les performances, la haute disponibilité et les options de récupération d’urgence, ainsi que la disponibilité de certaines fonctionnalités telles que In-Memory OLTP.

Cas d’utilisation	Usage général	critique pour l’entreprise	Hyperscale
Idéal pour	La plupart des charges de travail professionnelles. Offre des options de calcul et de stockage économiques, équilibrées et évolutives.	Offre aux applications métier la plus grande résilience aux défaillances à l’aide de plusieurs réplicas secondaires à haute disponibilité et offre les performances d’E/S les plus élevées.	La plus grande variété de charges de travail, y compris celles avec des exigences de stockage et de mise à l’échelle de lecture hautement évolutives. Offre une résilience accrue aux défaillances en autorisant la configuration de plusieurs réplicas secondaires à haute disponibilité.
Taille de calcul	2 à 128 vCores	2 à 128 vCores	2 à 128 vCores
type de stockage	Stockage Premium à distance (par instance)	Stockage SSD local super rapide (par instance)	Stockage découplé avec cache SSD local (par réplique de calcul)
taille de stockage	1 Go – 4 To	1 Go – 4 To	10 Go – 128 To
IOPS	320 IOPS par vCore avec 16 000 IOPS maximum	4 000 IOPS par vCore avec 327 680 IOPS maximum	327 680 IOPS avec un disque SSD local maximal Hyperscale est une architecture multiniveau avec mise en cache à plusieurs niveaux. Les E/S par seconde effectives dépendent de la charge de travail.
Mémoire/vCore	5,1 Go	5,1 Go	5,1 Go ou 10,2 Go
Sauvegardes	Choix de stockage de sauvegarde géoredondant, redondant interzone ou localement redondant, rétention de 1 à 35 jours (par défaut 7 jours) Rétention à long terme disponible jusqu’à 10 ans	Choix de stockage de sauvegarde géoredondant, redondant interzone ou localement redondant, rétention de 1 à 35 jours (par défaut 7 jours) Rétention à long terme disponible jusqu’à 10 ans	Un choix de stockage localement redondant (LRS), redondant interzone (ZRS) ou géoredondant (GRS) Rétention de 1 à 35 jours (7 jours par défaut), avec jusqu’à 10 ans de rétention à long terme disponible
Disponibilité	Un réplica, aucun réplica avec échelle lecture, haute disponibilité (HA) redondante interzone	Trois réplicas,un réplica avec échelle lecture, haute disponibilité (HA) redondante interzone	haute disponibilité (HA) redondante interzone
Tarification et facturation	vCore, le stockage réservé et le stockage de sauvegarde sont facturés. Les IOPS ne sont pas facturées.	vCore, le stockage réservé et le stockage de sauvegarde sont facturés. Les IOPS ne sont pas facturées.	Les vCore pour chaque réplica et le stockage utilisé sont facturés. Les IOPS ne sont pas facturées.
Modèles de remise	Réservations Azure Azure Hybrid Benefit (non disponible sur les abonnements dev/test) Abonnements Entreprise et offre Dev/Test - Paiement à l'utilisation	Réservations Azure Azure Hybrid Benefit (non disponible sur les abonnements dev/test) Abonnements Entreprise et offre Dev/Test - Paiement à l'utilisation	Azure Hybrid Benefit (non disponible sur les abonnements dev/test) ¹ Abonnements Entreprise et de l’offre Dev/Test - Paiement à l'utilisation
tables OLTP en mémoire	Non	Oui	Aucun

¹ Une tarification simplifiée pour SQL Database Hyperscale bientôt. Pour plus d’informations, consultez le blog de tarification Hyperscale.

Pour plus d’informations, passez en revue les limites des ressources pour le serveur logique , les bases de données uniques , et les bases de données mises en pool .

Remarque

Pour plus d’informations sur le contrat de niveau de service (SLA), consultez contrat SLA pour Azure SQL Database

Usage général

Le modèle architectural pour le niveau de service Usage général est basé sur une séparation du calcul et du stockage. Ce modèle architectural s’appuie sur la haute disponibilité et la fiabilité du stockage Blob Azure qui réplique en toute transparence les fichiers de base de données et ne garantit aucune perte de données si une défaillance de l’infrastructure sous-jacente se produit.

La figure suivante montre quatre nœuds dans le modèle architectural standard avec les couches de calcul et de stockage séparées.

Diagramme illustrant la séparation du calcul et du stockage.

Dans le modèle architectural du niveau de service Usage général, il existe deux couches :

Couche de calcul sans état qui exécute le processus de sqlservr.exe et contient uniquement des données temporaires et mises en cache (par exemple, cache de plan, pool de mémoires tampons, pool columnstore). Ce nœud sans état est géré par Azure Service Fabric qui initialise le processus, contrôle l’intégrité du nœud et effectue un basculement vers un autre emplacement si nécessaire.
Une couche de données avec état comprenant les fichiers de base de données (.mdf/.ldf) stockés dans le Stockage Blob Azure. Le stockage Blob Azure garantit qu’il n’existe aucune perte de données d’un enregistrement placé dans un fichier de base de données. Le stockage Azure dispose d’une disponibilité/redondance de données intégrée qui garantit que chaque enregistrement dans le fichier journal ou la page du fichier de données est conservé même si le processus se bloque.

Chaque fois que le moteur de base de données ou le système d’exploitation est mis à niveau, une partie de l’infrastructure sous-jacente échoue ou si un problème critique est détecté dans le processus de sqlservr.exe, Azure Service Fabric déplace le processus sans état vers un autre nœud de calcul sans état. Afin de réduire le temps de basculement, un ensemble de nœuds de réserve se tient prêt à exécuter le nouveau service de calcul en cas de basculement du nœud principal. Les données de la couche stockage Azure ne sont pas affectées et les fichiers de données/journaux sont attachés au processus nouvellement initialisé. Ce processus garantit une disponibilité de 99,99 %% par défaut et de 99,995 %% lorsque la redondance de zone est activée. Il peut y avoir des impacts sur les performances des charges lourdes en vol en raison du temps de transition et parce que le nouveau nœud commence avec un cache froid.

Quand choisir le niveau de service Général.

Le niveau de service Usage général est le niveau de service par défaut dans Azure SQL Database conçu pour la plupart des charges de travail génériques. Si vous avez besoin d’un moteur de base de données complètement managé avec un contrat SLA et une latence de stockage par défaut compris entre 5 ms et 10 ms, le niveau Usage général est l’option pour vous.

Critique pour l’entreprise

Le modèle de niveau de service Critique pour l’entreprise est basé sur un cluster de processus de moteur de base de données. Ce modèle architectural s’appuie sur un quorum de nœuds du moteur de base de données pour réduire les impacts sur les performances de votre charge de travail, même pendant les activités de maintenance. Les mises à niveau et les correctifs du système d’exploitation sous-jacent, des pilotes et du moteur de base de données se produisent de manière transparente, avec un temps d’arrêt minimal pour les utilisateurs finaux.

Dans le modèle critique pour l’entreprise, le calcul et le stockage sont intégrés sur chaque nœud. La réplication des données entre les processus du moteur de base de données sur chaque nœud d’un cluster à quatre nœuds obtient une haute disponibilité, chaque nœud utilisant un DISQUE SSD attaché localement comme stockage de données. Le diagramme suivant montre comment le niveau de service Critique pour l’entreprise organise un cluster de nœuds de moteur de base de données dans les réplicas de groupe de disponibilité.

Le processus du moteur de base de données et les fichiers .mdf/.ldf sous-jacents sont placés sur le même nœud avec un stockage SSD attaché localement, ce qui offre une faible latence à votre charge de travail. La haute disponibilité est implémentée à l’aide de technologies similaires à SQL Server groupes de disponibilité Always On. Chaque base de données est un cluster de nœuds de base de données avec une réplique principale accessible pour les charges de travail client, et trois répliques secondaires contenant des copies de données. Le réplica principal envoie constamment des modifications aux réplicas secondaires afin de garantir que les données sont disponibles sur les réplicas secondaires si le réplica principal échoue pour une raison quelconque. Le basculement est géré par Service Fabric et le moteur de base de données : un réplica secondaire devient le réplica principal et un autre réplica secondaire est créé pour garantir un nombre suffisant de nœuds dans le cluster. La charge de travail est automatiquement redirigée vers le nouveau réplica principal.

Par ailleurs, le cluster Critique pour l’entreprise intègre la fonctionnalité Échelle lecture qui fournit un réplica en lecture seule gratuit. Ce dernier permet d’exécuter des requêtes en lecture seule (comme des rapports) qui n’affectent pas les performances de la charge de travail sur votre réplica principal.

Quand choisir le niveau de service Critique pour l’entreprise

Le niveau de service Critique pour l’entreprise est conçu pour les applications qui nécessitent des réponses à faible latence du stockage SSD sous-jacent (1 à 2 ms en moyenne), une récupération plus rapide si l’infrastructure sous-jacente échoue ou doit désactiver les rapports, l’analytique et les requêtes en lecture seule sur le réplica secondaire accessible en lecture gratuite de la base de données primaire.

Les principales raisons pour lesquelles vous devez choisir le niveau de service Critique pour l’entreprise au lieu du niveau Usage général sont les suivantes :

exigences en matière de latence d’E/S faibles : les charges de travail nécessitant une réponse rapide cohérente de la couche de stockage (1 à 2 millisecondes en moyenne) doivent utiliser le niveau Critique pour l’entreprise.
Charge de travail avec requêtes de rapports et requêtes analytiques où seul un réplica secondaire en lecture seule gratuit suffit.
Meilleure résilience et récupération plus rapide des défaillances. En cas de défaillance du système, la base de données sur l’instance principale est désactivée et l’un des réplicas secondaires devient immédiatement la nouvelle base de données primaire en lecture-écriture, prête à traiter les requêtes.
protection avancée contre la corruption des données. Comme le niveau Critique pour l’entreprise utilise des réplicas de bases de données en arrière-plan, le service utilise la réparation de page automatique disponible avec la mise en miroir et les groupes de disponibilité pour atténuer l’altération des données. Si un réplica ne peut pas lire une page en raison d’un problème d’intégrité des données, une nouvelle copie de la page est récupérée à partir d’un autre réplica, en remplaçant la page non lisible sans perte de données ni temps d’arrêt du client. Cette fonctionnalité est disponible dans le niveau de service Usage général si la base de données a une copie secondaire géographique.
plus haute disponibilité : le niveau Critique pour l’entreprise dans une configuration de zone à haute disponibilité offre une résilience aux défaillances zonales et un contrat SLA de disponibilité plus élevé.
Géorécupération rapide : lorsque la géoréplication active est configurée, le niveau Critique pour l’entreprise a un objectif de point de récupération (RPO) garanti de 5 secondes et un objectif de délai de récupération (RTO) de 30 secondes pour 100 % des heures déployées.

Hyperscale

Le niveau de service Hyperscale convient à tous les types de charges de travail. Son architecture native cloud fournit un stockage et un calcul évolutifs indépendamment pour prendre en charge la plus grande variété d’applications traditionnelles et modernes. Les ressources de calcul et de stockage dans Hyperscale dépassent considérablement les ressources disponibles dans les niveaux Usage général et Critique pour l’entreprise.

Pour plus d’informations, consultez niveau de service Hyperscale pour Azure SQL Database.

Quand choisir le niveau de service Hyperscale

Le niveau de service Hyperscale supprime la plupart des limites pratiques généralement observées dans les bases de données cloud. Lorsque la plupart des autres bases de données sont limitées par les ressources disponibles dans un seul nœud, les bases de données du niveau de service Hyperscale n’ont aucune limite de ce type. Avec son architecture de stockage flexible, une base de données Hyperscale augmente en fonction des besoins et vous êtes facturé uniquement pour la capacité de stockage que vous utilisez.

Outre ses fonctionnalités de mise à l’échelle avancées, Hyperscale est une excellente option pour toute charge de travail, pas seulement pour les bases de données volumineuses. Avec Hyperscale, vous pouvez :

Obtenez une résilience élevée et une récupération rapide après une défaillance tout en contrôlant les coûts, en choisissant le nombre de réplicas haute disponibilité (de 0 à 4).
Améliorez la haute disponibilité de et en activant la redondance de zone pour le calcul et le stockage.
Obtenez une faible latence d’E/S (1 à 2 millisecondes en moyenne) pour la partie fréquemment consultée de votre base de données. Pour les bases de données plus petites, cela peut s’appliquer à l’ensemble de la base de données.
Implémentez une grande variété de scénarios d’échelle lecture avec des réplicas nommés.
Bénéficiez de la mise à l’échelle rapide, sans attendre que les données soient copiées dans le stockage local sur de nouveaux nœuds.
Profitez de sauvegarde continue de base de données sans impact et de restauration rapide.
Prenez en charge les exigences de la continuité d’activité en utilisant des groupes de basculement et la géoréplication.

Configuration matérielle

Les configurations matérielles courantes dans le modèle vCore incluent la série standard (Gen5), la série Fsv2 et la série DC. Hyperscale offre également une option pour le matériel de la série Premium et de la série Premium à mémoire optimisée. La configuration matérielle définit les limites de calcul et de mémoire et d’autres caractéristiques qui affectent les performances de la charge de travail.

Certaines configurations matérielles telles que la série standard (Gen5) peuvent utiliser plusieurs types de processeurs (PROCESSEUR), comme décrit dans ressources de calcul (processeur et mémoire). Bien qu’une base de données ou un pool élastique donné reste sur le matériel avec le même type d’UC pendant une longue période (généralement pendant plusieurs mois), certains événements peuvent entraîner le déplacement d’une base de données ou d’un pool vers du matériel qui utilise un autre type d’UC.

Une base de données ou un pool peut être déplacé pour divers scénarios, y compris, mais pas limité à quand :

L’objectif de service est modifié
L’infrastructure actuelle dans un centre de données approche des limites de capacité
Le matériel actuellement utilisé est mis hors service en raison de sa fin de vie
La configuration redondante interzone est activée, et est déplacée vers un autre matériel pour des raisons de capacité disponible

Pour certaines charges de travail, un déplacement vers un autre type d’UC peut changer les performances. SQL Database configure le matériel avec l’objectif de fournir des performances de charge de travail prévisibles même si le type de processeur change, en conservant les modifications de performances dans une bande étroite. Toutefois, dans le large éventail des charges de travail client dans SQL Database et à mesure que de nouveaux types de processeurs deviennent disponibles, il est parfois possible de voir des changements plus visibles dans les performances, si une base de données ou un pool passe à un autre type d’UC.

Quel que soit le type de processeur utilisé, les limites de ressources pour une base de données ou un pool élastique (comme le nombre de cœurs, la mémoire, les IOPS maximales, le taux de journal maximal et le nombre maximal de travailleurs simultanés) restent les mêmes tant que la base de données reste au même niveau de service.

Ressources de calcul (processeur et mémoire)

Le tableau suivant compare les ressources de calcul dans différentes configurations matérielles et niveaux de calcul :

Configuration matérielle	UC	Mémoire
Série standard (Gen5)	Calcul approvisionné - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), Intel® 8272CL (Cascade Lake) 2,5 GHz, Intel® Xeon® Platinum 8370C (Ice Lake), processeurs AMD EPYC 7763v (Milan) - Approvisionnement dans la limite de 128 vCores (hyper-thread) Calcul serverless* - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), Intel® 8272CL (Cascade Lake) 2,5 GHz, Intel® Xeon® Platinum 8370C (Ice Lake)*, processeurs AMD EPYC 7763v (Milan) – Mise à l’échelle automatique dans la limite de 80 vCores (hyper-thread) - Le ratio mémoire-à-vCore s’adapte dynamiquement à l’utilisation de la mémoire et du processeur en fonction de la demande de charge de travail et peut être aussi élevé que 24 Go par vCore. Par exemple, à un moment donné, une charge de travail peut utiliser et être facturée pour une mémoire de 240 Go et seulement 10 vCores.	Calcul approvisionné - 5,1 Go par vCore – Provisionnement jusqu’à 625 Go Calcul serverless - Mise à l’échelle automatique dans la limite de 24 Go par vCore - Mise à l’échelle automatique dans la limite de 240 Go
Série Fsv2	- Processeurs Intel® 8168 (Skylake) - Fréquence d’horloge turbo tous cœurs prolongée de 3,4 GHz et fréquence d’horloge turbo monocœur maximale de 3,7 GHz. - Approvisionnement dans la limite de 72 vCores (hyper-thread)	- 1,9 Go par vCore - Approvisionnement dans la limite de 136 Go
Série DC	- Processeurs Intel® Xeon® E-2288G - Avec l’extension Intel Software Guard (Intel SGX) - Approvisionnement dans la limite de 8 vCores (physiques)	4,5 Go par vCore

* Dans la vue de gestion dynamique sys.dm_user_db_resource_governance, la génération de matériel pour les bases de données utilisant des processeurs Intel® SP-8160 (Skylake) apparaît comme Gen6, la génération de matériel pour les bases de données utilisant Intel® 8272CL (Cascade Lake) apparaît comme Gen7 et la génération de matériel pour les bases de données à l’aide d’Intel® Xeon® Platinum 8370C (Ice Lake) ou AMD® EPYC® 7763v (Milan) apparaissent comme Gen8. Pour une taille de calcul et une configuration matérielle donnée, les limites de ressources sont identiques, quel que soit le type de processeur (Intel Broadwell, Skylake, Ice Lake, Cascade Lake ou AMD Milan).

Pour plus d’informations, consultez les limites de ressources pour les bases de données simples et les pools élastiques .

Pour connaître les ressources de calcul et la spécification de la base de données Hyperscale, consultez ressources de calcul Hyperscale.

Série standard (Gen5)

Le matériel de série standard (Gen5) fournit des ressources de calcul et de mémoire équilibrées, et convient à la plupart des charges de travail de base de données.

Le matériel de série standard (Gen5) est disponible dans toutes les régions publiques dans le monde entier.

Série Premium Hyperscale

Les options matérielles de la série Premium utilisent la dernière technologie processeur et mémoire d’Intel et AMD. La série Premium offre une amélioration des performances de calcul par rapport au matériel de série standard.

L’option de série Premium offre des performances de processeur plus rapides par rapport à la série Standard et un nombre plus élevé de vCores maximum.
L’option optimisée en mémoire de la série Premium offre deux fois la quantité de mémoire par rapport à la série Standard.

La série Standard, la série Premium et la série Premium à mémoire optimisée sont disponibles pour les pools élastiques Hyperscale.

Pour plus d’informations, consultez l’annonce de blog de la série Hyperscale Premium .

Pour connaître les régions disponibles, consultez Disponibilité de la série Premium Hyperscale.

Série Fsv2

La série Fsv2 est une configuration matérielle optimisée pour le calcul qui offre une faible latence du processeur et une vitesse d’horloge élevée pour les charges de travail les plus exigeantes du processeur. Comme pour les configurations matérielles de la série Premium Hyperscale, la série Fsv2 est alimentée par les dernières technologies de processeur et de mémoire d’Intel et AMD, ce qui permet aux clients de tirer parti des matériels les plus récents tout en utilisant des bases de données et des pools élastiques dans le niveau de service à usage général.
Selon la charge de travail, la série Fsv2 peut fournir plus de performances processeur par vCore que d’autres types de matériel. Par exemple, la taille de calcul 72 vCore Fsv2 peut fournir plus de performances de processeur que 80 vCores sur la série Standard (Gen5), à moindre coût.
Fsv2 fournit moins de mémoire et de tempdb par vCore que d’autres matériels, de sorte que les charges de travail sensibles à ces limites peuvent s’avérer plus performantes sur la série standard (Gen5).

La série Fsv2 n'est prise en charge que dans le niveau Usage général. Pour les régions où la série Fsv2 est disponible, consultez la disponibilité de la série Fsv2 .

Série DC

Le matériel de la série DC utilise des processeurs Intel avec la technologie Software Guard Extensions (Intel SGX).
La série DC est nécessaire pour les charges de travail Always Encrypted avec des enclaves sécurisées qui nécessitent une protection renforcée des enclaves matérielles, par rapport aux enclaves de sécurité basée sur la virtualisation (VBS).
La série DC est conçue pour les charges de travail qui traitent les données sensibles et demandent des fonctionnalités de traitement des requêtes confidentielles, fournies par Always Encrypted avec enclaves sécurisées.
Le matériel de la série DC fournit des ressources de calcul et de mémoire équilibrées.

La série DC est uniquement prise en charge pour le calcul provisionné (Serverless n’est pas prise en charge) et ne prend pas en charge la redondance de zone. Dans les régions où la série DC est disponible, consultez Disponibilité de la série DC.

Types d’offres Azure pris en charge par la série DC

Pour créer des bases de données ou des pools élastiques sur du matériel de série DC, l’abonnement doit être un type d’offre payante, comme le paiement à l’utilisation ou un Accord Entreprise (EA). Pour obtenir la liste complète des types d’offres Azure pris en charge par la série DC, consultez offres actuelles sans limites de dépense.

Sélectionner la configuration matérielle

Vous pouvez sélectionner la configuration matérielle d’une base de données ou d’un pool élastique dans SQL Database au moment de la création. Vous pouvez également modifier la configuration matérielle d’une base de données ou d’un pool élastique existant.

Pour sélectionner une configuration matérielle lors de la création d’une base de données SQL ou d’un pool

Pour plus d’informations, consultez Créer une base de données SQL.

Sous l’onglet Informations de base, sélectionnez le lien Configurer la base de données dans la section Calcul + stockage, puis sélectionnez le lien de configuration Modifier la configuration :

Sélectionnez la configuration matérielle souhaitée :

Pour modifier la configuration matérielle d’une base de données SQL existante ou d’un de pool

Pour une base de données, dans la page Vue d’ensemble, sélectionnez le lien niveau tarifaire :

Pour un pool, dans la page Vue d’ensemble, sélectionnez Configurer.

Suivez les étapes pour modifier la configuration, puis sélectionnez la configuration matérielle, comme décrit dans les étapes précédentes.

Disponibilité matérielle

Pour plus d’informations sur la disponibilité du matériel de génération précédente, consultez disponibilité matérielle de génération précédente.

Pour plus d’informations sur la disponibilité du matériel de génération actuelle, consultez disponibilité des fonctionnalités par région pour Azure SQL Database.

Matériel de génération précédente

Gen4

Le matériel Gen4 a été mis hors service et n’est plus disponible pour l’approvisionnement, le scale-up ou le scale-down. Migrez votre base de données vers une génération de matériel prise en charge pour une gamme plus étendue de vCore et d’extensibilité du stockage, de mise en réseau accélérée, de meilleures performances d’E/S et d’une latence minimale. Passez en revue les options matérielles pour les bases de données uniques et les options matérielles pour les pools élastiques. Pour plus d'informations, consultez le document L'assistance est terminée pour le matériel de génération 4 sur Azure SQL Database.

Étape suivante

Démarrage rapide : Créer une base de données unique - Azure SQL Database