Niveau de service Hyperscale

Azure SQL Database Hyperscale est une base de données cloud économique et performante.

Azure SQL Database est basée sur le Moteur de base de données SQL. Hyperscale diffère des autres niveaux de service Azure SQL Database :

Contrairement aux autres niveaux de service, Hyperscale n’a pas de frais de licence logicielle SQL, ce qui lui donne un avantage significatif par rapport à d’autres niveaux de service Azure SQL Database pour les bases de données hautes performances.
L’architecture Hyperscale est distincte : elle fournit des sauvegardes quasi instantanées, des restaurations rapides et un débit élevé pour les lectures et les écritures.
Hyperscale fournit une mise à l’échelle de calcul rapide à la demande sans déplacement de données.
Les stratégies d’échelle horizontale en lecture sont simples à mettre en œuvre, avec jusqu’à 30 réplicas nommés, chacun avec des ressources de calcul configurables indépendamment, ainsi que des réplicas intégrés de haute disponibilité et des géo-réplicas configurables à travers le monde.

Le niveau de service Hyperscale convient à tous les types de charges de travail. 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 Azure SQL Database.

Vous pouvez convertir une base de données existante dans Azure SQL Database vers Hyperscale facilement ou migrer de n’importe quelle base de données SQL Server vers Hyperscale. Pour migrer d’autres bases de données vers Azure SQL Database, consultez Azure Guides de migration de base de données.

Le niveau de service Hyperscale est actuellement disponible uniquement pour Azure SQL Database, et non pour Azure SQL Managed Instance.

Présentation des fonctionnalités Hyperscale

Le niveau de service Hyperscale dans Azure SQL Database fournit les fonctionnalités supplémentaires suivantes :

Montée en puissance rapide : augmentez vos ressources de calcul pour prendre en charge des charges de travail importantes lorsque nécessaire, puis réduisez-les lorsqu’elles ne sont plus nécessaires.
Effectuer une mise à l’échelle rapide : vous pouvez provisionner un ou plusieurs réplicas en lecture seule pour déplacer votre charge de travail de lecture et les utiliser comme serveurs de secours.
Scale-up, scale-down et facturation automatiques pour le calcul en fonction de l’utilisation avec le calcul serverless.
Prix/performances optimisés pour un groupe de bases de données Hyperscale présentant des besoins en ressources variables avec des pools élastiques.
Mise à l’échelle automatique du stockage avec prise en charge d’une taille de base de données pouvant atteindre 128 To ou de pool élastique pouvant atteindre 100 To.
Des performances globales plus élevées grâce à un débit plus important du journal des transactions et à des temps de validation des transactions plus rapides, quel que soit le volume des données.
Sauvegardes rapides de bases de données (basées sur des instantanés de fichiers), quelle que soit leur taille, sans impact des E/S sur les ressources de calcul.
Restaurations ou copies de base de données rapides (basées sur des instantanés de fichiers) en minutes plutôt qu’en heures ou en jours.

Le niveau de service Hyperscale supprime de nombreuses limites pratiques traditionnellement rencontrées dans les bases de données cloud. Là où 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 pas de limite. Avec son architecture de stockage flexible, le stockage augmente en fonction des besoins. En fait, les bases de données Hyperscale sont créées sans taille maximale définie. Une base de données Hyperscale augmente en fonction des besoins, et vous êtes facturé uniquement pour la capacité de stockage allouée. Pour les charges de travail de lecture intensives, le niveau de service Hyperscale permet un scale-out rapide en provisionnant des réplicas de supplémentaires en fonction des besoins pour déplacer les charges de travail de lecture.

Par ailleurs, le temps nécessaire pour créer des sauvegardes de base de données ou pour augmenter ou diminuer la puissance n’est plus lié au volume de données de la base de données. Les bases de données Hyperscale peuvent être sauvegardées quasi instantanément. Vous pouvez aussi effectuer en quelques minutes un scale-up ou un scale-down de plusieurs dizaines de téraoctets sur une base de données dans le niveau de calcul approvisionné, ou utiliser le mode serverless pour mettre automatiquement le calcul à l’échelle. Cette fonctionnalité vous évite d’être limité par votre choix de configuration initial.

Pour plus d’informations sur les tailles de calcul pour le niveau de service Hyperscale, consultez Caractéristiques du niveau de service.

Pour en savoir plus sur les niveaux de service Usage général et Critique pour l’entreprise du modèle d’achat vCore, consultez les niveaux de service Usage général et Critique pour l’entreprise. Pour obtenir une comparaison du modèle d’achat vCore avec le modèle d’achat DTU, consultez Compare vCore et les modèles d’achat DTU de Azure SQL Database.

À qui est destiné le niveau de service Hyperscale

Le niveau de service Hyperscale est destiné à tous les clients qui nécessitent des performances et une disponibilité plus élevées, une sauvegarde et une restauration rapides, ainsi qu’un stockage et une scalabilité de calcul rapides. Hyperscale est idéal pour les clients qui passent au cloud pour moderniser leurs applications ou pour les clients qui utilisent déjà d’autres niveaux de service dans Azure SQL Database. Le niveau de service Hyperscale prend en charge un large éventail de charges de travail, de l’OLTP pur à l’analytique pure. Il est optimisé pour les charges de travail OLTP et HTAP (traitement analytique et de transaction hybride).

Modèle tarifaire Hyperscale

Pour les bases de données hautes performances, Hyperscale offre un avantage tarifaire significatif sur d’autres niveaux de service Azure SQL Database. Pour plus d’informations, consultez Blog : annonce de la tarification d’Azure SQL Database Hyperscale lors d’Ignite 2023. Pour plus d’informations sur les modifications de tarification, consultez Blog : Azure SQL Database Hyperscale - tarification plus faible et simplifiée !

Le niveau de service Hyperscale est disponible uniquement dans le modèle vCore et est fourni dans deux niveaux de calcul. La facturation d’HyperScale est déterminée en fonction du niveau de calcul provisionné ou sans serveur :

Niveau de calcul provisionné :

Le coût de calcul vCore reflète la capacité de calcul totale approvisionnée en continu pour l’application. Le prix unitaire du calcul Hyperscale est par réplica.
Niveau de calcul serverless :

La facturation de calcul serverless est basée sur l’utilisation. Pour plus d’informations, consultez niveau de calcul sans serveur pour Azure SQL Database.

Vous ne spécifiez pas la taille maximale des données lors de la configuration d’une base de données Hyperscale. Dans le niveau Hyperscale, vous payez pour le stockage en fonction de l’allocation réelle. Le stockage est automatiquement alloué entre 10 Go et 128 To, et augmente selon les besoins. Pour plus d’informations, voir En quels incréments la taille de ma base de données augmente-t-elle ?

Avantages de scalabilité et de performances

Hyperscale sépare le moteur de base de données principal des composants qui fournissent un stockage à long terme et une durabilité pour les données. Cette architecture vous permet de mettre à l’échelle les ressources de calcul rapidement, sans déplacement de données et de mettre à l’échelle le stockage (jusqu’à 128 To) indépendamment du calcul. Pour plus d’informations, notamment un diagramme d’architecture, consultez l’architecture Hyperscale.

Avec la possibilité de faire tourner/descendre rapidement des nœuds de calcul en lecture seule supplémentaires, l’architecture Hyperscale permet des fonctionnalités de mise à l’échelle de lecture significatives et peut également libérer le nœud de calcul principal pour répondre à d’autres requêtes.
Vous pouvez allouer des ressources de calcul aux nœuds secondaires ou utiliser des ressources de calcul sans serveur. Dans les deux cas, vous pouvez rapidement augmenter ou réduire leur capacité grâce à l’architecture de stockage partagé d’Hyperscale.
- Les réplicas de nœuds de calcul à haute disponibilité secondaires dans Hyperscale suivent le niveau de calcul du serveur principal, ce qui entraîne des basculements à faible impact.
Lorsque vous utilisez le mode serverless, les nœuds de calcul principaux ou secondaires s’adaptent automatiquement en fonction des besoins de votre charge de travail.

La base de données Azure SQL Database Hyperscale principale gère à la fois les charges de travail en lecture et en écriture, mais vous pouvez facilement créer des répliques en lecture seule dans le cadre de votre stratégie applicative :

Vous pouvez ajuster le nombre total de réplicas secondaires à haute disponibilité de 0 à 4, en fonction des exigences de disponibilité et d’extensibilité.
Vous pouvez créer jusqu’à 30 répliques nommées pour prendre en charge les charges de travail d’échelle horizontale en lecture.
Vous pouvez assurer une mise à l’échelle horizontale en lecture géodistribuée dans les centres de données mondiaux Azure à l’aide de géo-réplicas.

Haute disponibilité de la base de données dans Hyperscale

Comme pour tous les autres niveaux de service, Hyperscale garantit la durabilité des données pour les transactions validées, quelle que soit la disponibilité des réplicas de calcul. L’étendue des temps d’arrêt dus au fait que le réplica principal devient indisponible dépend du type de basculement (planifié ou non planifié) que la redondance de zone soit configurée ou non, et de la présence d’au moins un réplica à haute disponibilité. Dans un basculement planifié (par exemple, un événement de maintenance), le système crée le réplica principal avant de lancer un basculement ou utilise un réplica à haute disponibilité existant comme cible de basculement. Dans un basculement non planifié (par exemple, une défaillance matérielle sur le réplica principal), le système utilise un réplica à haute disponibilité (s’il en existe un) comme cible de basculement ou crée un réplica principal à partir du pool de capacité de calcul disponible. Dans ce dernier cas, la durée d’inactivité est plus longue en raison des étapes supplémentaires nécessaires pour créer le réplica principal.

Vous pouvez choisir une fenêtre de maintenance pour rendre prévisibles et moins perturbants les événements de maintenance impactants pour votre charge de travail.

Pour le contrat SLA Hyperscale, consultez SLA pour Azure SQL Database.

Pool de mémoires tampons et extension de pool de mémoires tampons résilientes

Dans Azure Database Hyperscale, il existe une séparation distincte entre le calcul et le stockage. Le stockage contient toutes les pages de base de données d’une base de données et peut être réparti sur plusieurs machines à mesure que la base de données grandit. Le nœud de calcul, quant à lui, ne met en cache que les données récemment utilisées. Les pages les plus fréquemment sollicitées du calcul sont conservées en mémoire dans une structure appelée pool de mémoire tampon. Elles sont également stockées sur le SSD local, dans une extension résiliente appelée resilient buffer pool extension (RBPEX), ce qui permet un accès plus rapide en cas de redémarrage du processus de calcul.

Dans un système cloud, le calcul peut être déplacé dynamiquement vers d'autres machines si nécessaire. La couche de calcul peut comporter plusieurs réplicas. Une réplique est la réplique principale et reçoit toutes les mises à jour, tandis que les autres sont des répliques secondaires. Si le réplica principal tombe en panne, le système fait passer l’un des réplicas secondaires à haute disponibilité au rôle de réplica principal, dans le cadre d’un processus appelé « basculement ». Cependant, ce réplica secondaire peut ne pas disposer dans son pool de mémoire tampon (BP) et son RBPEX d’un cache optimisé pour la charge de travail principale.

amorçage continu

L’amorçage en continu est un processus qui collecte des informations sur les pages les plus fréquemment consultées dans l’ensemble des réplicas de calcul. Ce processus agrège ces informations, puis les réplicas secondaires à haute disponibilité utilisent cette liste des pages les plus sollicitées, représentative de la charge de travail typique des clients. Ce processus remplit en permanence à la fois le BP et le RBPEX avec les pages les plus sollicitées afin de s’adapter aux évolutions de la charge de travail du client.

Sans amorçage continu, ni BP ni RBPEX ne sont pas hérités par de nouvelles répliques à haute disponibilité et ne sont reconstruites que pendant la charge de travail utilisateur. L’amorçage continu permet donc de gagner du temps et d’éviter des performances irrégulières, puisqu’il n’y a plus d’attente avant que les caches ne soient à nouveau entièrement alimentés. Avec l’amorçage continu, tout nouveau réplica secondaire à haute disponibilité commence immédiatement à préparer son BP et son RBPEX. Cela permet de maintenir des performances plus constantes en cas de basculement.

L’amorçage continu fonctionne dans les deux sens : les réplicas secondaires à haute disponibilité mettent en cache les pages utilisées par le réplica principal, et ce dernier fait de même pour les charges de travail issues des réplicas secondaires.

L’amorçage continu est actuellement disponible dans le niveau de calcul provisionné Hyperscale.

Sauvegarde et restauration

Les opérations de sauvegarde et de restauration pour les bases de données Hyperscale sont basées sur des instantanés de fichiers. Cette approche rend ces opérations presque instantanées. Étant donné que l’architecture Hyperscale utilise la couche de stockage pour la sauvegarde et la restauration, elle réduit la charge de traitement et l’impact sur les performances sur les réplicas de calcul. Pour plus d’informations, consultez les sauvegardes Hyperscale et la redondance du stockage.

Récupération d’urgence pour les bases de données Hyperscale

Pour restaurer une base de données Hyperscale dans Azure SQL Database dans une région autre que celle dans laquelle elle est actuellement hébergée, effectuez une géorestauration. Cette méthode fonctionne pour les opérations de récupération d’urgence, les exercices, la réinstallation ou toute autre raison. La géorestauration est disponible uniquement lorsque vous choisissez un stockage géoredondant (RA-GRS) pour la redondance du stockage.

Pour plus d’informations, consultez la restauration d’une base de données Hyperscale dans une autre région.

Comparer les limites de ressources

Les niveaux de service vCore diffèrent selon la disponibilité de la base de données, le type de stockage, les performances et la taille de stockage maximale. Le tableau suivant décrit ces différences :

ㅤ	Usage général	Critique pour l’entreprise	Hyperscale
Idéal pour	Options équilibrées de calcul et de stockage économiques.	Applications OLTP avec des débits de transactions élevés et une faible latence des E/S. Résilience élevée aux défaillances et basculements rapides à l’aide de plusieurs réplicas de secours à chaud.	Niveau de service recommandé et par défaut pour toutes les charges de travail OLTP et HTAP nouvelles et modernisées. Adapté à la majorité des charges de travail, y compris celles avec des exigences de stockage et d’échelle 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 à 192 vCores³
Type de stockage	Stockage distant Premium (par instance)	Stockage SSD local ultra-rapide (par instance)	Stockage découplé avec cache disque SSD local (par réplica de calcul)
Taille du stockage	1 Go - 4 To	1 Go - 4 To	10 Go - 128 To
Nombre maximum d’E/S par seconde	320 IOPS par vCore avec 16,000 IOPS au maximum	4,000 IOPS par vCore avec 327,680 IOPS au maximum	5 500 IOPS par vCore avec 544 000 IOPS SSD locaux maximum. L’architecture hyperscale est une architecture à plusieurs niveaux avec une mise en cache sur 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 entre stockage localement redondant (LRS), redondant interzone (ZRS) et géoredondant (GRS) Rétention de 1 à 35 jours (7 jours par défaut), avec jusqu’à 10 ans de rétention à long terme disponible	Choix entre stockage localement redondant (LRS), redondant interzone (ZRS) et géoredondant (GRS) Rétention de 1 à 35 jours (7 jours par défaut), avec jusqu’à 10 ans de rétention à long terme disponible	Choix entre stockage localement redondant (LRS), redondant interzone (ZRS) et 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 seul réplica, aucun réplica de mise à l’échelle horizontale en lecture. Haute disponibilité redondante interzone	Trois réplicas, un seul réplica de mise à l’échelle horizontale en lecture. Haute disponibilité redondante interzone	Plusieurs réplicas, jusqu’à 4 réplicas de mise à l’échelle horizontale en lecture. Haute disponibilité 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 vCores pour chaque réplica, stockage de données alloué et stockage de sauvegarde sont facturés. Les IOPS ne sont pas facturées.
Modèles de remise¹	Réservations Azure Azure Hybrid Benefit² Abonnements Entreprise et offre Dev/Test - Paiement à l'utilisation	Réservations Azure Azure Hybrid Benefit² Abonnements Entreprise et offre Dev/Test - Paiement à l'utilisation	Étant donné que Hyperscale n'a pas de frais de licence logicielle SQL¹, Azure Hybrid Benefit n'est pas disponible pour les nouvelles bases de données Hyperscale².
Tables en mémoire	Non	Oui	Non

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

² À compter de décembre 2023, Azure Hybrid Benefit n'est pas disponible pour les nouvelles bases de données Hyperscale ou dans les abonnements de développement/test. Les bases de données uniques Hyperscale existantes avec le calcul approvisionné peuvent continuer à utiliser des Azure Hybrid Benefit pour économiser sur les coûts de calcul jusqu’en décembre 2026. Pour plus d’informations, consultez ce blog sur la tarification Hyperscale.

³ Actuellement, les options vCore 160 et 192 sont une fonctionnalité en préversion.

Ressources de calcul

Le tableau suivant compare les ressources de calcul dans différentes configurations matérielles et niveaux de calcul pour Azure SQL Database Hyperscale. Pour une base de données Azure SQL non Hyperscale, consultez le modèle de vente vCore - Azure SQL Database.

Configuration matérielle	UC	Mémoire
Série Standard (Gen5)	Calcul provisionné - 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), AMD EPYC™ 7763v (Milan), AMD EPYC 9004 (Gênes), Intel® Xeon®® Platinum 8573C (Emerald Rapids) - Approvisionnement dans la limite de 128 vCores (hyper-thread) Calcul sans serveur - 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), AMD EPYC™ 7763v (Milan), AMD EPYC 9004 (Gênes), Intel® Xeon®® Platinum 8573C (Emerald Rapids) – Effectuer un scale-up 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 selon la demande des charges de travail et peut atteindre 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 provisionné - 5,1 Go par vCore – Provisionnement jusqu’à 625 Go Calcul sans serveur - Mise à l’échelle automatique dans la limite de 24 Go par vCore - Mise à l’échelle automatique dans la limite de 240 Go
Série Premium	Calcul provisionné - Intel® Xeon Platinum 8370C (Ice Lake), AMD EPYC™ 7763v (Milan), AMD EPYC 9004 (Gênes), processeurs Intel® Xeon®® Platinum 8573C (Emerald Rapids) - Provisionnement dans la limite de 192 vCores (hyper-thread).	5,2 Go par vCore
Série Premium à mémoire optimisée	Calcul provisionné - Intel® Xeon Platinum 8370C (Ice Lake), AMD EPYC™ 7763v (Milan), AMD EPYC 9004 (Gênes), processeurs Intel® Xeon®® Platinum 8573C (Emerald Rapids) - Provisionnement dans la limite de 80 vCores (hyper-thread).	10,2 Go par vCore

* 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, Emerald Rapid ou AMD Milan, Gênes). Dans la vue de gestion dynamique sys.dm_user_db_resource_governance, génération matérielle pour les bases de données à l’aide de :

Les processeurs Intel® SP-8160 (Skylake) apparaissent comme Gen6
Intel® 8272CL (Cascade Lake) apparaît comme Gen7
Intel® Xeon® Platinum 8370C (Ice Lake) ou AMD EPYC™ 7763v (Milan) apparaissent comme Gen8
AMD EPYC™ 9004 (Gênes) apparaissent comme Gen9 ou Intel® Xeon® Platinum 8573C (Emerald Rapids) apparaissent comme Gen10

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

Créer et gérer des bases de données Hyperscale

Vous pouvez créer et gérer des bases de données Hyperscale à l’aide du portail Azure, de Transact-SQL, de PowerShell et du Azure CLI. Pour plus d’informations, consultez Démarrage rapide : Créer une base de données Hyperscale.

Operation	Détails	En savoir plus
Créer une base de données Hyperscale	Les bases de données Hyperscale sont disponibles uniquement via le modèle d’achat basé sur les vCores.	Recherchez des exemples pour créer une base de données Hyperscale dans Quickstart : Créer une base de données Hyperscale dans Azure SQL Database.
convertir une base de données existante en Hyperscale	Vous pouvez convertir une base de données existante en Azure SQL Database niveau Hyperscale. La durée de conversion dépend de la taille des données.	Pour plus d’informations, consultez Convertir une base de données existante enHyperscale .
Inverser la migration d’une base de données Hyperscale vers le niveau de service Usage général	Si vous avez précédemment migré une Azure SQL Database existante vers Hyperscale, vous pouvez inverser la migration de la base de données vers le niveau de service Usage général dans les 45 jours suivant la migration d’origine vers Hyperscale. Si vous souhaitez migrer la base de données vers un autre niveau de service, tel que Critique pour l’entreprise, commencez par effectuer une migration inverse vers le niveau de service Usage général, puis modifiez le niveau de service.	Découvrez comment inverser la migration à partir d’Hyperscale, y compris les limitations de la migration inversée.

Limites

Ces limitations s’appliquent actuellement au niveau de service Hyperscale. L’équipe produit travaille activement à supprimer autant de ces limitations que possible.

Problème	Descriptif
La réduction est bloquée lorsque TDE est désactivé	Actuellement, Azure SQL Database Hyperscale ne prend pas en charge les opérations de réduction de base de données et de fichiers lorsque Transparent Data Encryption (TDE) est désactivé.
Restaurer la base de données à partir d’autres niveaux de service	Vous ne pouvez pas restaurer une base de données non Hyperscale en tant que base de données Hyperscale. Vous ne pouvez pas également restaurer une base de données Hyperscale en tant que base de données non Hyperscale. Pour les bases de données migrées vers Hyperscale à partir d’autres niveaux de service Azure SQL Database, les sauvegardes de pré-migration sont conservées pendant la durée de la période de rétention de sauvegarde de la base de données source, y compris les stratégies de rétention à long terme. Vous pouvez restaurer une sauvegarde antérieure à la migration pendant la période de rétention des sauvegardes de la base de données à l’aide de la ligne de commande. Vous pouvez restaurer ces sauvegardes à n’importe quel niveau de service non Hyperscale.
Migration de bases de données avec des objets OLTP en mémoire	Hyperscale prend en charge une partie des objets OLTP en mémoire, notamment les types de tables à mémoire optimisée, les variables de table et les modules compilés en mode natif. Toutefois, lorsqu’un des objets OLTP en mémoire est présent dans la base de données en cours de migration, la migration des niveaux de service Premium et Critique pour l’entreprise vers Hyperscale n’est pas prise en charge. Pour migrer une telle base de données vers Hyperscale, vous devez supprimer toutes les In-Memory objets OLTP et leurs dépendances. Une fois la base de données migrée, vous pouvez recréer ces objets. Les tables à mémoire optimisée durables et non durables ne sont actuellement pas prises en charge dans Hyperscale et doivent être changées en tables de disques.
Vérification de l’intégrité de la base de données	`DBCC CHECKDB`et `DBCC CHECKFILEGROUP` ne sont pas actuellement pris en charge pour les bases de données Azure SQL Database Hyperscale. Comme solution de contournement, utilisez `DBCC CHECKTABLE ('TableName') WITH TABLOCK`. Pour plus d’informations sur la gestion de l’intégrité des données dans Azure SQL Database, consultez Intégrité des données dans Azure SQL Database.
Travaux élastiques	L’utilisation d’une base de données Hyperscale comme base de données de travail n’est pas prise en charge. Toutefois, les travaux élastiques peuvent cibler des bases de données Hyperscale de la même façon que n’importe quelle autre base de données dans Azure SQL Database.
Synchronisation des données	L’utilisation d’une base de données Hyperscale en tant que base de données de hub ou de métadonnées de synchronisation n’est pas prise en charge. Toutefois, une base de données Hyperscale peut être une base de données membre dans une topologie Synchronisation des données.
Matériel de la série Premium pour le niveau de service Hyperscale	Le matériel de la série Premium et de la série Premium à mémoire optimisée ne prend pas actuellement en charge le niveau de calcul serverless. Le mode serverless est pris en charge seulement sur le matériel de la série Standard (Gen5).
Disponibilité régionale	Le matériel des séries Premium et Premium à mémoire optimisée du niveau de service Hyperscale est disponible dans un nombre limité de régions Azure. Pour obtenir une liste, consultez Disponibilité de la série Premium Hyperscale.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-06-23