Questions fréquentes (FAQ) sur le niveau Hyperscale dans Azure SQL Database

Une base de données Hyperscale est une base de données SQL Database qui repose sur la technologie de stockage scale-out Hyperscale. Une base de données Hyperscale prend en charge jusqu’à 128 To de données, offre des performances et un débit élevés, ainsi qu’une mise à l’échelle rapide pour répondre aux exigences des charges de travail. La connectivité, le traitement des requêtes, les fonctionnalités du moteur de base de données, etc. fonctionnent de la même façon que pour n’importe quelle autre base de données Azure SQL Database.

Le niveau de service Hyperscale est disponible seulement pour les bases de données uniques avec le modèle d’achat vCore dans Azure SQL Database. Il n’est pas disponible dans le modèle d’achat DTU.

Les niveaux de service basés sur vCore sont différenciés en fonction de la disponibilité de la base de données et du type de stockage, des performances et de la taille maximale, comme décrit dans la comparaison des limites de ressources.

Le niveau de service Hyperscale est destiné à tous les clients qui recherchent des performances et une disponibilité élevées, des sauvegardes et des restaurations rapides, un stockage rapide et une scalabilité du calcul. Cela inclut les clients qui ont commencé à petite échelle et qui se développent, ceux qui exploitent de grandes bases de données critiques, ceux qui passent au cloud pour moderniser leurs applications, ainsi que les clients qui utilisent déjà d’autres niveaux de service dans la base de données Azure SQL. Avec Hyperscale, vous bénéficiez des avantages suivants :

• Taille de base de données pouvant passer de 10 Go à 128 To.
• Calcul des ressources vCore de 2 vCores jusqu’à 128 vCores
• Sauvegardes de base de données rapides, quelle que soit la taille des bases de données (les sauvegardes sont basées sur des captures instantanées de stockage).
• Restaurations de base de données rapides, quelle que soit la taille des bases de données (les restaurations sont effectuées à partir des captures instantanées de stockage).
• Débit de journalisation plus élevé, quelle que soit la taille de la base de données et le nombre de vCores.
• Échelle horizontale en lecture à l’aide d’un ou de plusieurs réplicas en lecture seule, utilisés pour décharger les charges de travail en lecture seule ou en tant que bases de données de serveurs de secours.
• Scale-up rapide des calculs, en durée constante, de façon à gagner en puissance pour faire face à des charges de travail importantes, puis à réduire cette puissance (scale-down), toujours en durée constante. Les opérations de mise à l’échelle prennent des minutes à un chiffre pour le calcul approvisionné et moins d’une seconde pour le calcul serverless, quelle que soit la taille de la base de données.
• Option de paiement pour ce que vous utilisez avec le calcul serverless, où le calcul est facturé en fonction de l’utilisation.

Le niveau de service Hyperscale est disponible dans toutes les régions où Azure SQL Database est disponible.

Oui. Pour plus d’informations et pour connaître les limites quant au nombre de bases de données par serveur, consultez Limites de ressources de SQL Database pour les bases de données uniques et mises en pool sur un serveur.

L’architecture Hyperscale fournit des performances et des débits élevés avec la prise en charge de bases de données de grande taille.

Hyperscale offre une scalabilité rapide en fonction de la demande de votre charge de travail.

• Scale-up/down

  Avec Hyperscale, vous pouvez augmenter la taille de calcul principale en termes de ressources, comme le processeur et la mémoire, puis mettre à l’échelle vers le bas, en durée constante. Comme le stockage est distant, le scale-up et le scale-down ne sont pas des opérations relatives à la taille des données.

  La prise en charge du calcul serverless offre un scale-up et un scale-down automatiques, et le calcul est facturé en fonction de l’utilisation.

• Scale-in/out

  Avec Hyperscale, vous pouvez utiliser trois types de réplicas secondaires pour répondre aux exigences d’échelle horizontale en lecture, de haute disponibilité et de géoréplication. notamment :

  • Jusqu’à quatre réplicas haute disponibilité ayant la même taille de calcul que le réplica principal. Ceux-ci servent de réplicas de serveur de secours permettant de basculer rapidement à partir du serveur principal. Vous pouvez également les utiliser pour déplacer les charges de travail de lecture à partir du réplica principal.
  • Jusqu’à 30 réplicas nommés ayant une taille de calcul identique ou différente de celle du réplica principal, pour répondre à divers scénarios d’échelle horizontale en lecture.
  • Un géoréplica situé dans une autre région Azure pour vous protéger en cas de pannes régionales et pour activer l’échelle lecture géographique.

Oui, vous le pouvez.

Non, votre modèle de programmation d’application reste identique à celui de n’importe quelle autre base de données MSSQL. Vous utilisez votre chaîne de connexion comme d’habitude et les autres méthodes normales pour interagir avec votre base de données Hyperscale. Une fois que votre application utilise la base de données Hyperscale, elle peut bénéficier de fonctionnalités telles que les réplicas secondaires.

Sur le réplica principal, le niveau d’isolement par défaut des transactions est RCSI (Read Committed Snapshot Isolation). Sur les réplicas secondaires avec échelle horizontale en lecture, le niveau d’isolation par défaut est Instantané. C’est la même chose que dans toutes les autres bases de données Azure SQL.

Avec la nouvelle tarification simplifiée en vigueur depuis le 15 décembre 2023, le prix du calcul a été réduit pour les bases de données Hyperscale nouvellement créées, toutes les bases de données Hyperscale serverless et tous les pools élastiques Hyperscale. Avec la nouvelle tarification simplifiée, il n’est pas nécessaire d’appliquer Azure Hybrid Benefit (AHB) pour obtenir des économies équivalentes. Azure Hybrid Benefit (AHB) ne peut être appliqué qu’à des bases de données uniques Hyperscale créées avant le 15 décembre 2023 avec un calcul provisionné. Pour ces bases de données plus anciennes, AHB ne peut être appliqué que jusqu’en décembre 2026, après quoi ces bases de données seront également facturées conformément aux nouveaux tarifs simplifiés. Pour plus d’informations, consultez le blog de tarification Hyperscale et Azure SQL Database Hyperscale : tarification plus faible et simplifiée !.

Hyperscale fonctionne bien avec tous les types de charges de travail, y compris les charges de travail OLTP, hybrides (HTAP) et analytiques (Data Mart).

Si vous exécutez actuellement des requêtes analytiques interactives avec SQL Server comme entrepôt de données, Hyperscale est une option intéressante, car vous pouvez héberger des entrepôts de données de taille petite et moyenne (par exemple de quelques To jusqu’à 128 To) à un coût inférieur, et vous pouvez migrer les charges de travail de votre entrepôt de données SQL Server vers Hyperscale avec des modifications minimales du code T-SQL.

Si vous exécutez de l’analytique des données à grande échelle avec des requêtes complexes et des taux d’ingestion supérieurs à 100 Mo/s, ou en utilisant Parallel Data Warehouse, Teradata ou d’autres entrepôts de données MPP (Massively Parallel Processing), tel qu’Azure Synapse Analytics , donc Microsoft Fabric peut être le meilleur choix.

Le taux d’ingestion ou de génération de journaux de 150 Mo/s est disponible en tant que fonctionnalité en préversion avec consentement. Pour découvrir plus d’informations et pour consentir à 150 Mo/s, consultez Blog : améliorations apportées à Hyperscale en novembre 2024.

Pas pour l'instant. Toutefois, vous pouvez appliquer un scale-down à votre calcul et au nombre de réplicas pour réduire les coûts en dehors des heures de pointe, ou utiliser serverless pour mettre automatiquement à l’échelle le calcul en fonction de l’utilisation.

Pour les charges de travail de lecture, vous pouvez créer un réplica nommé avec une taille de calcul supérieure (plus de cœurs et de mémoire) à celle du réplica principal. Pour plus d’informations sur les tailles de calcul disponibles, consultez Tailles de stockage et tailles de calcul Hyperscale.

Pour les charges de travail de lecture, cela peut être réalisé à l’aide de réplicas nommés.

Vous pouvez mettre à l’échelle le nombre de réplicas secondaires haute disponibilité (entre 0 et 4) à l’aide du portail Azure ou de l’API REST. En outre, vous pouvez créer jusqu’à 30 réplicas nommés pour de nombreux scénarios d’échelle horizontale en lecture.

Dans les bases de données Hyperscale, la résilience des données est fournie au niveau du stockage. Un seul réplica (le principal) est suffisant pour fournir la résilience. Quand le réplica de capacité de calcul est défaillant, un nouveau réplica est créé automatiquement sans perte de données.

Toutefois, si vous n’avez que le réplica principal, la création d’un réplica après le basculement peut prendre une minute ou deux, alors que cela ne prendrait que quelques secondes si vous disposiez d’un réplica secondaire haute disponibilité. Le nouveau réplica aura initialement des caches froids, ce qui peut entraîner une latence de stockage plus élevée et réduire les performances des requêtes immédiatement après le basculement.

Pour les applications stratégiques qui nécessitent une haute disponibilité avec un impact de basculement minimal, vous devez provisionner au moins 1 réplica secondaire haute disponibilité afin de garantir qu’un réplica de serveur de secours est disponible pour servir de cible de basculement.

La taille maximale d’une base de données Hyperscale unique est actuellement de 128 To. La taille maximale d’une base de données dans un pool élastique Hyperscale est actuellement de 100 To.

Dans Hyperscale, le journal des transactions est pratiquement infini, avec toutefois une restriction qui veut que la partie active ne peut pas dépasser 1 To. La partie active du journal peut croître en raison de transactions durables ou parce que la capture des changements de données ne correspond pas au taux de modification des données. Il est recommandé d’éviter les transactions inutilement longues et volumineuses pour rester en dessous de cette limite. En dehors de cette restriction, vous n’avez pas à vous soucier d’un espace insuffisant pour le journal sur un système dont le débit de journalisation est élevé. Cependant, le débit de génération du journal peut être limité pour les charges de travail en écriture agressives continues. La vitesse de génération de journal maximale soutenue est de 100 Mo/s.

Le taux de génération de journaux de 150 Mo/s est disponible en tant que fonctionnalité en préversion avec consentement. Pour découvrir plus d’informations et pour consentir à 150 Mo/s, consultez Blog : améliorations apportées à Hyperscale en novembre 2024.

Votre base de données tempdb se trouve sur un stockage SSD local et elle est dimensionnée proportionnellement à la taille de calcul (nombre de cœurs) que vous provisionnez. La taille de tempdb n’est pas configurable et elle est gérée pour vous. Pour déterminer tempdb la taille maximale de votre base de données, consultez tempdb.

La taille de votre base de données croît automatiquement au fil de l’insertion/ingestion de données.

10 Go. Une base de données Hyperscale est créée avec une taille de départ de 10 Go et augmente selon les besoins par blocs de 10 Go.

Chaque fichier de données croît de 10 Go. Plusieurs fichiers de données peuvent croître en même temps.

Dans Hyperscale, les fichiers de données sont stockés dans le stockage Azure standard. Les données sont entièrement mises en cache sur le stockage SSD local, sur les serveurs de pages qui sont distants des réplicas de calcul. En outre, les réplicas de calcul ont des caches de données sur un SSD local et en mémoire, afin de réduire la fréquence des extractions de données sur les serveurs de pages distants.

Non. Les fichiers de données sont ajoutés automatiquement au groupe de fichiers PRIMARY. Les raisons courantes de la création de groupes de fichiers supplémentaires ne s’appliquent pas à l’architecture de stockage Hyperscale, ou plus généralement à Azure SQL Database.

Non.

Oui, les opérations de réduction de base de données et de fichiers sont actuellement en préversion. Pour plus d’informations sur la préversion, consultez Réduction pour Azure SQL Database Hyperscale.

Oui, comme dans n’importe quelle autre base de données Azure SQL DB. Cela inclut la compression de lignes, de pages et de columnstores.

Oui. Les pages de données associées à une table donnée peuvent être stockées dans plusieurs fichiers de données, qui font tous partie du même groupe de fichiers. Le moteur de base de données MSSQL utilise une stratégie de remplissage proportionnel pour distribuer les données entre les fichiers de données.

Oui. Vous pouvez déplacer vos bases de données existantes d’Azure SQL Database vers Hyperscale. Pour les preuves de concept, nous vous recommandons d’effectuer une copie de votre base de données et de migrer la copie vers Hyperscale.

Le temps nécessaire pour déplacer une base de données existante vers Hyperscale comprend le temps de copie des données et celui de relecture des modifications apportées dans la base de données source lors de la copie des données. Le temps de copie des données est proportionnel à la taille des données. Le temps de relecture des modifications est plus court si le déplacement est effectué pendant une période de faible activité d’écriture.

Obtenez un exemple de code pour migrer des bases de données Azure SQL existantes vers Hyperscale dans le portail Azure, Azure CLI, PowerShell et Transact-SQL dans l’article Migrer une base de données existante vers Hyperscale.

La migration inversée vers le niveau de service Usage général permet aux clients qui ont récemment migré une base de données existante dans Azure SQL Database vers le niveau de service Hyperscale de faire marche arrière si Hyperscale ne répond pas à leurs besoins. Même si la migration inversée est lancée par un changement de niveau de service, il s’agit essentiellement d’un opération de taille de données entre différentes architectures. Comme pour la migration vers Hyperscale, la migration inverse est plus rapide si elle est effectuée pendant une période de faible activité d'écriture. Découvrez les limitations de la migration inversée.

Si vous avez précédemment migré une instance existante d’Azure SQL Database vers le niveau de service Hyperscale, vous pouvez inverser la migration vers le niveau de service Usage général dans les 45 jours qui suivent 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, effectuez d’abord une migration inversée vers le niveau de service usage général, puis modifiez le niveau de service. La migration inversée est une taille d’opération de données.

Les bases de données créées dans le niveau de service Hyperscale ne peuvent pas être déplacées vers d’autres niveaux de service.

Découvrez comment inverser la migration à partir d’Hyperscale, y compris les limitations de la migration inversée et les stratégies de sauvegarde impactées.

Oui. Certaines fonctionnalités d’Azure SQL Database ne sont pas encore prises en charge dans Hyperscale. Si certaines de ces fonctionnalités sont activées pour votre base de données, la migration vers Hyperscale pourrait être bloquée ou ces fonctionnalités peuvent cesser de fonctionner après la migration. Nous espérons que ces limites ne seront pas définitives. Pour plus d’informations, consultez Limites connues.

Oui. Vous pouvez utiliser de nombreuses technologies existantes pour effectuer une migration vers Hyperscale, notamment la réplication transactionnelle, et toute autre technologie de déplacement de données (copie en bloc, Azure Data Factory, Azure Databricks, SSIS). Voir aussi l’Azure Database Migration Service, qui prend en charge de nombreux scénarios de migration.

Le temps d’arrêt pour la migration vers Hyperscale est le même que quand vous migrez vos bases de données vers d’autres niveaux de service dans Azure SQL Database. Vous pouvez utiliser la réplication transactionnelle afin de réduire le temps d’arrêt dû à la migration pour les bases de données dont la taille ne dépasse pas quelques téraoctets. Pour les bases de données très volumineuses (plus de 10 To), vous pouvez implémenter le processus de migration avec ADF, Spark ou d’autres technologies de déplacement des données en bloc.

Hyperscale peut consommer 100 Mo/s de données nouvelles ou modifiées, mais le temps nécessaire pour déplacer des données dans des bases de données dans Azure SQL Database est également affecté par le débit du réseau disponible, la vitesse de lecture de la source et l’objectif de niveau de service de la base de données cible. Le taux de génération de journaux de 150 Mo/s est disponible en tant que fonctionnalité en préversion avec consentement. Pour découvrir plus d’informations et pour consentir à 150 Mo/s, consultez Blog : améliorations apportées à Hyperscale en novembre 2024.

Vous pouvez faire en sorte qu’une application cliente lise des données depuis Stockage Azure et charger des données dans une base de données Hyperscale (tout comme vous pouvez le faire avec n’importe quelle autre base de données dans Azure SQL Database). Actuellement, PolyBase n’est pas pris en charge dans Azure SQL Database. Comme alternative pour fournir une charge rapide, vous pouvez utiliser Azure Data Factory ou utiliser un travail Spark dans Azure Databricks avec le connecteur Spark pour SQL. Le connecteur Spark pour SQL prend en charge l’insertion en bloc.

Il est également possible de lire en bloc des données à partir du magasin d’objets blob Azure à l’aide de BULK INSERT ou OPENROWSET : Exemples d’accès en bloc à des données dans Stockage Blob Azure.

Le modèle de récupération simple ou de journalisation en bloc n’est pas pris en charge dans Hyperscale. Le modèle de récupération complète est nécessaire pour fournir une haute disponibilité et la récupération jusqu`à une date et heure. Cependant, l’architecture de journalisation Hyperscale fournit un meilleur débit d’ingestion en comparaison avec d’autres niveaux de services Azure SQL Database.

Non. Hyperscale est une architecture à multitraitement symétrique (SMP) et n’est pas une architecture MMP (Massively Parallel Processing) ou une architecture multimaître. Vous pouvez créer plusieurs réplicas seulement pour effectuer un scale-out des charges de travail en lecture seule.

Oui. Azure Database Migration Service prend en charge de nombreux scénarios de migration.

Voir SLA pour Azure SQL Database. Nous vous recommandons d’ajouter des réplicas secondaires haute disponibilité pour les charges de travail critiques. Cela permet un basculement plus rapide et réduit l’impact potentiel sur les performances immédiatement après le basculement.

Oui.

Oui, la fonctionnalité Hyperscale prend en charge la configuration redondante interzone. Vous devez utiliser au moins un réplica secondaire haute disponibilité et le stockage redondant interzone ou géo-redondant interzone afin d’activer la configuration redondante interzone pour Hyperscale.

Oui. Pour plus d’informations, consultez Pools élastiques Hyperscale et Blog : Les pools élastiques Hyperscale sont désormais en disponibilité générale.

Il n’existe pas de sauvegardes complètes, différentielles et de fichier journal traditionnelles pour les bases de données Hyperscale. En revanche, vous pouvez effectuer des captures instantanées régulières du stockage de fichiers de données, avec une cadence de capture différente pour chaque fichier. Le journal des transactions généré est conservé en l’état pendant la période de conservation configurée. Au moment de la restauration, les enregistrements de journal des transactions appropriés sont appliqués aux instantanés de stockage restaurés. Quelle que soit la fréquence de capture, cela aboutit à une base de données cohérente d’un point de vue transactionnel, sans perte de données, à compter du moment spécifié dans la période de conservation. En effet, la sauvegarde de base de données dans Hyperscale est continue.

Oui.

Le RPO de la restauration à un instant dans le passé est de 0 min. La plupart des opérations de restauration se terminent en 60 minutes, quelle que soit la taille de la base de données. La durée de restauration peut être plus longue pour des bases de données plus volumineuses et si la base de données a fait l’objet d’une activité d’écriture importante avant et jusqu’au point de restauration dans le temps. La modification de la redondance du stockage lors d'une restauration peut entraîner des temps de restauration plus longs, car la restauration porte sur le dimensionnement des données et le temps sera donc proportionnel à la taille de la base de données.

Non. Les sauvegardes sont gérées par le sous-système de stockage et utilisent des captures instantanées de stockage. Elles n’affectent pas les charges de travail utilisateur.

Oui. La géorestauration est entièrement prise en charge si le stockage géoredondant est utilisé. Il s’agit du comportement par défaut pour les nouvelles bases de données. Contrairement à la limite de restauration dans le temps, la géorestauration nécessite une opération à l’échelle des données. Les fichiers de données étant copiés en parallèle, la durée de cette opération dépend principalement de la taille du fichier le plus volumineux dans la base de données, plutôt que de la taille totale de celle-ci. La durée de la géorestauration est beaucoup plus courte si la base de données est restaurée dans la région Azure associée à la région de la base de données source.

Oui. La géoréplication peut être configurée pour les bases de données Hyperscale.

Non. Le format de stockage pour les bases de données Hyperscale est différent de celui des versions publiées de SQL Server. En outre, vous ne contrôlez pas les sauvegardes et vous n’y avez pas accès. Pour extraire vos données d’une base de données Hyperscale, vous pouvez extraire les données à l’aide des technologies de déplacement des données, c’est-à-dire Azure Data Factory, Azure Databricks, SSIS, etc.

Oui. À compter du 4 mai 2022, les sauvegardes de toutes les nouvelles bases de données seront facturées en fonction du stockage de sauvegarde consommé et de la redondance de stockage sélectionnée, aux tarifs indiqués dans la page des tarifs Azure SQL Database. Pour les bases de données Hyperscale créées avant le 4 mai 2022, les sauvegardes seront facturées uniquement si la conservation des sauvegardes est définie sur une valeur supérieure à sept jours. Pour plus d’informations, consultez Sauvegardes et redondance de stockage Hyperscale.

Pour plus d’informations sur la façon de mesurer la taille du stockage de sauvegarde, consultez Sauvegardes automatisées.

Pour obtenir votre facture de stockage de sauvegarde, la taille du stockage de sauvegarde est calculée régulièrement, et multipliée par le taux de stockage de sauvegarde et le nombre d’heures depuis le dernier calcul. Pour estimer votre facture de sauvegarde pendant une période donnée, multipliez la taille du stockage de sauvegarde facturable pour chaque heure de la période par le tarif de stockage de sauvegarde, puis additionnez tous les montants horaires. Pour interroger par programmation les métriques Azure Monitor concernant plusieurs intervalles horaires, utilisez l’API REST Azure Monitor. La facturation des sauvegardes dans le niveau de calcul serverless est la même que dans le niveau de calcul provisionné.

Les coûts de sauvegarde sont plus élevés pour les charges de travail qui ajoutent, modifient ou suppriment de grands volumes de données dans la base de données. À l’inverse, les charges de travail qui sont principalement en lecture seule peuvent avoir des coûts de sauvegarde inférieurs.

Pour plus d’informations sur la façon de réduire les coûts de stockage de sauvegarde, consultez Sauvegardes automatisées.

Le débit limite du journal des transactions est défini sur 100 Mo/s pour toute taille de calcul Hyperscale. La capacité à atteindre ce taux dépend de plusieurs facteurs, notamment le type de charge de travail, la configuration et les performances du client, ainsi qu’une capacité de calcul suffisante sur le réplica de calcul principal pour produire les enregistrements du journal à ce rythme. Le taux de génération de journaux de 150 Mo/s est disponible en tant que fonctionnalité en préversion avec consentement. Pour découvrir plus d’informations et pour consentir à 150 Mo/s, consultez Blog : améliorations apportées à Hyperscale en novembre 2024.

Les IOPS et la latence d’E/S varient en fonction des modèles de charge de travail. Si les données en cours d’accès sont mises en cache dans RBPEX sur le réplica de calcul, vous verrez des performances d’e/s similaires comme dans les niveaux de service critique pour l’entreprise ou Premium.

Non. La capacité de calcul est découplée de la couche de stockage. Cela élimine l’impact sur les performances de la sauvegarde.

Comme le stockage est partagé et qu’aucune réplication physique directe n’est effectuée entre les réplicas de calcul principaux et secondaires, le débit sur le réplica principal n’est pas affecté directement par l’ajout de réplicas secondaires. Cependant, les charges de travail en écriture continue et agressive peuvent être limitées sur le réplica principal afin de laisser le temps au « log apply » sur les réplicas secondaires et les serveurs de pages. Cela a pour but d’éviter les performances de lecture médiocres sur les réplicas secondaires et un temps de récupération long après le basculement vers un réplica secondaire haute disponibilité.

Oui. Toutefois, comme dans d’autres bases de données Azure SQL DB, les connexions peuvent être arrêtées par des erreurs temporaires très peu fréquentes, qui peuvent entraîner l’abandon des requêtes de longue durée et la restauration des transactions. Des erreurs temporaires peuvent par exemple se produire lorsque le système déplace rapidement la base de données vers un autre nœud de calcul pour garantir la continuité de la disponibilité des ressources de calcul et de stockage, ou pour effectuer une maintenance planifiée. La plupart de ces événements de reconfiguration se terminent en moins de 10 secondes. Les applications qui se connectent à votre base de données doivent être conçues pour s’attendre à ces erreurs temporaires inhabituelles et les tolérer en implémentant une logique de nouvelle tentative. Vous pouvez éventuellement configurer une fenêtre de maintenance qui correspond à votre planification de charge de travail, afin d’éviter les erreurs temporaires dues à une maintenance planifiée.

Pour la plupart des problèmes de performances, en particulier ceux qui ne proviennent pas des performances de stockage, les étapes courantes de diagnostic et de résolution des problèmes SQL s’appliquent. Pour obtenir des diagnostics de stockage spécifiques à Hyperscale, consultez Diagnostics de résolution des problèmes de performances Hyperscale SQL.

La quantité maximale de mémoire qu’une base de données serverless peut définir en scale-up est de 3 Go/vCore multiplié par le nombre maximal de vCores configurés, contre plus de 5 Go/vCore multiplié par le même nombre de vCores dans le calcul provisionné. Pour plus d’informations, passez en revue les limites de ressources Hyperscale serverless.

Un scale-up ou un scale-down dans le niveau de calcul provisionné prend généralement 2 minutes, quelle que soit la taille des données. Dans le niveau de calcul serverless, où le calcul est automatiquement mis à l’échelle en fonction de la demande de charge de travail, le temps de mise à l’échelle est généralement inférieur à la seconde, mais peut parfois prendre autant de temps que lors de la mise à l’échelle du calcul provisionné.

Non. Une base de données reste en ligne pendant les opérations de scale-up ou de scale-down.

Le scale-up ou le scale-down d’un calcul provisionné entraînent la suppression des connexions quand un basculement se produit à la fin de l’opération de mise à l’échelle. Dans le calcul serverless, la mise à l’échelle automatique n’entraîne généralement pas la suppression d’une connexion, mais cela peut se produire occasionnellement. L’ajout ou la suppression de réplicas secondaires n’entraîne pas de suppressions de connexions sur le serveur principal.

La mise à l’échelle dans le calcul provisionné est effectuée par l’utilisateur final. La mise à l’échelle automatique dans le calcul serverless est effectuée par le service.

Oui. La taille de la base de données tempdb et du cache RBPEX sur les nœuds de calcul augmente automatiquement à mesure que le nombre de cœurs augmente. Pour plus d’informations, consultez Tailles de stockage et taille de calcul Hyperscale.

Non. Seul le réplica de calcul principal accepte les demandes de lecture/écriture. Les réplicas de calcul secondaires acceptent seulement les demandes en lecture seule.

Hyperscale prend en charge les géoréplicas, les réplicas nommés et les réplicas haute disponibilité (HA). Pour plus d’informations, consultez Réplicas secondaires Hyperscale.

Entre 0 et 4. Si vous souhaitez ajuster le nombre de réplicas, vous pouvez le faire au moyen du Portail Microsoft Azure ou de l’API REST.

Vous pouvez vous connecter à ces autres réplicas de calcul en lecture seule en définissant la propriété ApplicationIntent de votre chaîne de connexion sur ReadOnly. Toutes les connexions marquées avec ReadOnly sont automatiquement routées vers l’un des réplicas secondaires haute disponibilité, si elles existent. Pour plus d’informations, consultez Utiliser des réplicas en lecture seule pour décharger des charges de travail de requêtes en lecture seule.

Vous pouvez exécuter la requête T-SQL suivante : SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Le résultat est READ_ONLY si vous êtes connecté à un réplica secondaire en lecture seule, et READ_WRITE si vous êtes connecté au réplica principal. Le contexte de base de données doit être défini sur le nom de votre base de données, et non sur celui de la base de données master.

Non. Vous pouvez uniquement vous connecter à des réplicas secondaires haute disponibilité en spécifiant ApplicationIntent=ReadOnly. En revanche, vous pouvez utiliser des points de terminaison dédiés pour les réplicas nommés.

Non. Une nouvelle connexion avec intention de lecture seule est redirigée vers un réplica secondaire haute disponibilité arbitraire.

Pas dans le niveau de calcul provisionné. Les réplicas secondaires haute disponibilité sont utilisés comme cibles de basculement à haute disponibilité. Ils doivent donc avoir la même configuration que le réplica principal pour fournir les performances attendues après le basculement. En serverless, le calcul est mis à l’échelle automatiquement pour chaque réplica haute disponibilité en fonction de sa propre demande de charge de travail. Chaque réplica secondaire haute disponibilité peut toujours effectuer une mise à l’échelle automatique sur le nombre maximal de cœurs configurés pour prendre en charge son rôle post-basculement. Les réplicas nommés offrent la possibilité de mettre à l’échelle chaque réplica indépendamment.

Non. Votre base de données tempdb est configurée en fonction de la taille de calcul provisionnée. Vos réplicas secondaires haute disponibilité sont de la même taille, y compris tempdb, que le calcul principal. Sur des réplicas nommés, tempdb est dimensionné en fonction de la taille de calcul du réplica, ce dernier peut donc être plus petit ou plus grand que tempdb sur le principal.

Non. Les réplicas de calcul de bases de données Hyperscale partage le stockage, ce qui signifie que tous les réplicas de calcul voient les mêmes tables, les mêmes index et autres objets de base de données. Si vous voulez des index supplémentaires optimisés pour les lectures sur les réplicas secondaires, vous devez d’abord les ajouter sur le réplica principal. Vous pouvez toujours créer des tables temporaires (noms de tableaux préfixés par # ou ##) sur chaque réplica secondaire pour stocker les données temporaires. Les tableaux temporaires sont en lecture-écriture.

La latence des données entre le moment où une transaction est validée sur le réplica principal et le moment où elle est lisible sur un réplica secondaire dépend de la vitesse de génération de journal actuelle, de la taille de la transaction, de la charge sur le réplica et d’autres facteurs. La latence des données standard pour les petites transactions est de l’ordre de dizaines de millisecondes, mais il n’y a pas de limite supérieure à la latence des données. Les données situées sur un réplica secondaire donné sont toujours cohérentes d’un point de vue transactionnel. Par conséquent, les transactions volumineuses prennent plus de temps à se propager. Toutefois, à un moment donné, la latence des données et l’état de la base de données peuvent varier sur les différents réplicas secondaires. Les charges de travail qui doivent lire les données validées immédiatement doivent s’exécuter sur le réplica principal.

Non, les réplicas nommés ne peuvent pas être utilisés comme cibles de réplication du réplica principal. Utilisez des réplicas à haute disponibilité à cet effet.

Étant donné que chaque réplica nommé peut avoir un objectif de niveau de service différent et donc être utilisé pour différents cas d’utilisation, il n’existe aucun moyen prédéfini de diriger le trafic en lecture seule envoyé au réplica principal vers le jeu de réplicas nommés. Par exemple, vous pouvez avoir huit réplicas nommés et diriger la charge de travail OLTP uniquement vers les réplicas nommés 1 à 4, tandis les charges de travail analytiques de Power BI utilisent les réplicas nommés 5 et 6, et la charge de travail de science des données les réplicas 7 et 8. Selon l’outil ou le langage de programmation que vous utilisez, les stratégies de distribution de ce type de charge de travail peuvent varier. Pour un exemple de création d’une solution de routage de charges de travail pour permettre le scale-out d’un back-end REST, examinez l’exemple de scale-out OLTP.

Non, comme les réplicas nommés utilisent les mêmes serveurs de pages du réplica principal, ils doivent être dans la même région.

Un réplica nommé ne peut pas avoir d’impact sur la disponibilité du réplica principal. Dans des circonstances normales, les réplicas nommés sont peu susceptibles d’avoir un impact sur les performances du réplica principal, mais cela peut se produire si des charges de travail intensives sont en cours d’exécution. Tout comme un réplica à haute disponibilité, un réplica nommé reste synchronisé avec le réplica principal par le biais du service de journal des transactions. Si, pour une raison ou une autre, un réplica nommé ne peut pas consommer les journaux des transactions assez rapidement, il commence à demander au réplica principal de ralentir (limiter) sa génération de journaux afin de pouvoir rattraper son retard. Bien que ce comportement n’ait pas d’impact sur la disponibilité du réplica principal, il peut avoir une incidence sur les performances des charges de travail en écriture sur le réplica principal. Pour éviter ce problème, assurez-vous que vos réplicas nommés disposent de suffisamment de ressources libres, principalement au niveau du processeur, pour pouvoir traiter le journal des transactions sans délai. Par exemple, si la base de données primaire traite de nombreuses modifications de données, il est recommandé d’avoir les réplicas nommés avec au moins le même objectif de niveau de service du réplica principal afin d’éviter de saturer le processeur sur les réplicas et de forcer le réplica principal à ralentir.

Les réplicas nommés restent quand même disponibles pour l’accès en lecture seule, comme d’habitude.

Par défaut, les réplicas nommés n’ont pas de réplica à haute disponibilité. Le basculement d’un réplica nommé nécessite d’abord la création d’un nouveau réplica, ce qui prend généralement de 1 à 2 minutes. Toutefois, les réplicas nommés peuvent également bénéficier d’une disponibilité supérieure et de basculements plus rapides avec des réplicas haute disponibilité. Pour ajouter des réplicas haute disponibilité à un réplica nommé, vous pouvez utiliser le paramètre ha-replicas avec l’interface CLI AZ ou le paramètre HighAvailabilityReplicaCount avec PowerShell, ou via la propriété highAvailabilityReplicaCount avec l’API REST. Le nombre de réplicas à haute disponibilité peut être défini lors de la création d’un réplica nommé et peut être modifié, uniquement via AZ CLI, PowerShell ou l’API REST, à tout moment après la création du réplica nommé. Le prix des réplicas à haute disponibilité pour les réplicas nommés est le même que celui des réplicas à haute disponibilité pour les bases de données hyperscale standard.

Oui. La clé principale de colonne est stockée dans la base de données utilisateur et peut être validée en exécutant la requête SELECT * FROM sys.column_master_keys. Les réplicas nommés et les réplicas secondaires à haute disponibilité lisent les données à partir des mêmes serveurs de pages/couche de stockage que la base de données Hyperscale principale. Les deux types de réplicas sont synchronisés avec la base de données Hyperscale principale via le service de journal. Une modification de clé est considérée comme une transaction et est automatiquement répliquée vers le réplica nommé et le réplica secondaire à haute disponibilité.

La fonction DATABASEPROPERTYEX(), lorsqu’elle est exécutée dans le contexte d’un réplica nommé, peut mapper le replica_id à son réplica nommé correspondant. Toutefois, il n’est actuellement pas possible de lier le replica_id au réplica nommé respectif pour chaque enregistrement dans la vue de gestion dynamique sys.dm_database_replica_states lorsqu’il est interrogé à partir du réplica principal. L’exemple de requête suivant peut être exécuté dans le contexte d’un réplica nommé pour identifier le nom du réplica, l’ID du réplica et les détails de synchronisation.

  SELECT replica_id, DB_NAME() AS 'Database/Replica name', 
  synchronization_state_desc, log_send_queue_size/1024.0/1024.0 AS log_send_queue_size_gb,
  last_sent_time, last_received_time, last_commit_time, secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE replica_id = DATABASEPROPERTYEX(DB_NAME(),'REPLICAID');

Contenu connexe

Pour plus d’informations sur le niveau de service Hyperscale, consultez Niveau de service Hyperscale.