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

Une base de données Hyperscale est une base de données dans Azure SQL Database qui est soutenue par l'technologie de stockage scale-out. 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, et ainsi de suite, fonctionnent comme dans n’importe quelle autre base de données dans Azure SQL Database.

Le niveau de service Hyperscale est disponible pour les bases de données uniques (approvisionnées et serverless) et pour les pools élastiques à l’aide du modèle d’achat vCore. 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, quelle que soit la taille de calcul.
• Calculez les 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 journal des transactions 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. Étant donné que le stockage est distant, le scale-up et le scale-down ne sont pas une opération de taille de données.

  La prise en charge de de calcul serverless fournit un scale-up et un scale-down et une facturation de calcul automatiques 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’isolation des transactions par défaut est READ COMMITTED avec l’option de base de données READ_COMMITTED_SNAPSHOT (RCSI) activée. Sur les réplicas secondaires, le niveau d’isolation est SNAPSHOT. 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 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 Mio/s est disponible en tant que fonctionnalité d’évaluation d’opt-in pour la mémoire optimisée de la série Premium et de la série Premium. Pour plus d’informations et pour vous inscrire à 150 Mio/s, consultez Blog : Améliorations de novembre 2024 hyperscale.

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. Chaque réplica nommé peut avoir jusqu’à 4 réplicas secondaires à haute disponibilité.

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. Si le réplica de calcul échoue ou est en maintenance, un nouveau réplica est créé automatiquement sans perte de données.

Toutefois, s’il n’existe que le réplica principal, il peut prendre une minute ou deux pour créer un réplica, par opposition aux secondes dans le cas où un réplica secondaire haute disponibilité est disponible. 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 minimal sur le basculement, vous devez provisionner au moins un réplica secondaire haute disponibilité pour vous assurer qu’un réplica de secours à chaud est disponible pour servir de cible de basculement.

La taille maximale d’une base de données Hyperscale unique est actuellement de 128 To, quelle que soit la taille de calcul. 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é. Toutefois, le taux de génération de journaux peut être réduit pour l’écriture dynamique continue de charges de travail. 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 Mio/s est disponible en tant que fonctionnalité d’évaluation d’opt-in pour la série Premium et la mémoire de la série Premium optimisée. Pour plus d’informations et pour vous inscrire à 150 Mio/s, consultez Blog : Améliorations de novembre 2024 hyperscale.

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.

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 ligne, de page et de columnstore .

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. 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 inverse est une opération de taille 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 prises en charge dans Hyperscale. Si certaines de ces fonctionnalités sont activées pour votre base de données, la migration vers Hyperscale peut être bloquée ou ces fonctionnalités arrêtent de fonctionner après la migration. 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 est capable de consommer 100 Mo/s de données nouvelles/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 réseau disponible, la vitesse de lecture source, le type de charge (en bloc ou ligne par ligne) et l’objectif de niveau de service de base de données cible. Le taux de génération de journaux de 150 Mio/s est disponible en tant que fonctionnalité d’évaluation d’opt-in pour la série Premium et la mémoire de la série Premium optimisée. Pour plus d’informations et pour vous inscrire à 150 Mio/s, consultez Blog : Améliorations de novembre 2024 hyperscale.

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.

Les modèles de récupération journalisés simples ou en bloc ne sont 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 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 cadence d’instantané, cela entraîne une base de données cohérente de manière transactionnelle à partir du point spécifié dans le temps pendant la période de rétention, sans aucune perte de données. 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. L’émission d’une restauration après une modification récente de redondance de stockage peut entraîner des temps de restauration plus longs, car la restauration peut être une opération de taille de données dans ce cas, et le temps de restauration peut être 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 ou géoredondant interzone est utilisé. Le stockage géoredondant est la valeur 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. géoréplication et les groupes de basculement peuvent être configurés 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 des données à l’aide de toutes les technologies de déplacement de données telles qu’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 mesure de 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.

Actuellement, les sauvegardes de niveau de service non Hyperscale (De base/Standard/Premium/Usage général/Critique pour l’entreprise) ne peuvent pas être géo-restaurées dans un niveau de service Hyperscale et vice versa. Pour convertir une base de données non Hyperscale en une base de données Hyperscale, modifiez le niveau de service après une restauration.

La limite de débit du journal des transactions est de 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 Mio/s est disponible en tant que fonctionnalité d’évaluation d’opt-in pour la série Premium et la mémoire de la série Premium optimisée. Pour plus d’informations et pour vous inscrire à 150 Mio/s, consultez Blog : Améliorations de novembre 2024 hyperscale.

Les IOPS et la latence d’E/S varient en fonction des modèles de charge de travail. Si les données accessibles sont mises en cache dans le stockage SSD local sur le réplica de calcul, vous verrez des performances d’E/S similaires à celles des 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.

Étant donné que le stockage est partagé et qu’il n’existe aucune réplication physique directe entre les réplicas de calcul principal et secondaire, le débit sur le réplica principal n’est pas directement affecté par l’ajout de réplicas secondaires. Toutefois, le taux de journalisation des charges de travail d’écriture continue et agressive peut être limité sur le serveur principal pour permettre à l’application de journaux sur les réplicas secondaires et les serveurs de pages de rattraper le retard. 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, les connexions peuvent être arrêtées par des erreurs temporaires très peu fréquentes, ce qui peut abandonner les requêtes de longue durée et annuler les 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 sont pas rootés dans les performances du stockage, les étapes courantes de diagnostic msSQL et de résolution des problèmes 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 base de données tempdb et cache SSD de calcul taille sur les nœuds de calcul augmentent automatiquement à mesure que le nombre de cœurs est augmenté. 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. réplicas nommés permettent de mettre à l’échelle chaque réplica nommé 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 tables précédés de # ou ##) sur chaque réplica secondaire pour stocker des données temporaires dans la base de données tempdb. 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. À un moment donné, la latence des données et l’état de la base de données peuvent être différents pour 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. Ajoutez des réplicas haute disponibilité pour le réplica primaire à 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. Toutefois, si vous avez créé un géo-réplica pour le réplica principal dans une autre région, vous pouvez créer des réplicas nommés pour le géoréplica.

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 un réplica nommé, pour une raison quelconque, n’est pas en mesure d’utiliser le journal des transactions suffisamment rapidement, il commence à demander au réplica principal de réduire son taux de génération de journal, afin qu’il puisse rattraper son retard. Bien que ce comportement n’ait pas d’impact sur la disponibilité du principal, il peut avoir un impact sur les performances des charges de travail d’écriture sur le serveur principal. Pour éviter cette situation, assurez-vous que vos réplicas nommés disposent d’une marge de travail suffisante pour traiter le journal des transactions sans délai. Par exemple, si le serveur principal traite de nombreuses modifications de données, il est recommandé d’avoir des réplicas nommés avec au moins la même taille de calcul que la taille de calcul primaire pour éviter de saturer le processeur sur les réplicas et forcer le réplica principal à ralentir.

Les réplicas nommés sont toujours 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é. Vous pouvez ajouter des réplicas haute disponibilité pour un réplica nommé dans le portail Azure, ou en utilisant le paramètre ha-replicas avec CLI AZ, ou le paramètre HighAvailabilityReplicaCount avec PowerShell, ou la propriété highAvailabilityReplicaCount avec API REST. Le nombre de réplicas haute disponibilité peut être défini pendant la création d’un réplica nommé et peut être modifié à tout moment après la création du réplica nommé. La tarification des réplicas haute disponibilité pour les réplicas nommés est le même que pour les réplicas principaux.

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 répliquée automatiquement sur tous les réplicas secondaires.

Pas lorsque vous interrogez sys.dm_database_replica_states sur le réplica principal. Toutefois, vous pouvez vous connecter à un réplica nommé pour déterminer son ID de réplica et d’autres détails à l’aide de l’exemple de requête suivant :

  SELECT replica_id,
         DB_NAME() AS named_replica_database_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,
         redo_queue_size / 1024.0 / 1024.0 AS redo_queue_size_gb,
         redo_rate,
         secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE is_local = 1
        AND
        replica_id = DATABASEPROPERTYEX(DB_NAME(), 'ReplicaID');

Contenu connexe

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