Limites de ressources pour les pools élastiques suivant le modèle d’achat vCore

S’applique à :Azure SQL Database

Cet article détaille les limites de ressources des pools élastiques Azure SQL Database et des bases de données mises en pool suivant le modèle d’achat vCore.

• Pour connaître les limites de ressources vCore de base de données unique, consultez les limites des ressources vCore - Limites de ressources Azure SQL Database et vCore - pools élastiques.
• Pour plus d’informations sur les différents modèles d’achat, consultez Comparer les modèles d’achat vCore et DTU d’Azure SQL Database.

Propriétés de base de données pour les bases de données mises en pool

Pour chaque pool élastique, vous pouvez éventuellement spécifier le nombre minimal et maximal de vCores par base de données pour modifier les modèles de consommation de ressources dans le pool. Vous pouvez également définir le stockage maximal par base de données, par exemple pour empêcher une base de données unique de consommer tout stockage de pool.

• Les valeurs minimales et maximales spécifiées s’appliquent à toutes les bases de données du pool. La personnalisation des nombres minimaux et maximaux de vCores pour des bases de données individuelles dans le pool n’est pas prise en charge.
• Le stockage maximal par base de données peut être configuré indépendamment pour chaque base de données.

La table suivante décrit les propriétés de base de données pour les bases de données mises en pool.

Même si les propriétés par base de données sont exprimées en vCores, elles régissent également la consommation d’autres types de ressources, comme les E/S de données, les E/S de journal, la mémoire du pool de mémoires tampons et les threads de travail. Lorsque vous ajustez les valeurs min et max de vCores par base de données, les réservations et les limites de tous les types de ressources sont ajustées proportionnellement.

Les valeurs minimales et maximales de vCores par base de données s’appliquent à la consommation de ressources par les charges de travail utilisateur, mais pas à la consommation de ressources par les processus internes. Par exemple, pour une base de données dont le nombre maximal de vCores par base de données est fixé à la moitié du nombre de vCores du pool, la charge de travail utilisateur ne peut pas consommer plus de la moitié de la mémoire du pool de mémoires tampons. Toutefois, cette base de données peut toujours tirer parti des pages du pool de mémoires tampons qui ont été chargées par des processus internes. Pour plus d’informations, consultez Consommation de ressources par les charges de travail utilisateur et les processus internes.

Les limites de ressources des bases de données individuelles dans les pools élastiques sont généralement identiques à celles des bases de données uniques situées hors des pools qui ont la même taille de calcul (objectif de service). Par exemple, le nombre maximal de workers simultanés pour une GP_S_Gen5_10 base de données est de 750 workers. Ainsi, le nombre maximal de workers simultanés pour une base de données dans un GP_Gen5_10 pool est également de 750 workers. Notez que le nombre total de travailleurs simultanés dans le GP_Gen5_10 pool est de 1050. Pour connaître le nombre maximal de Workers simultanés dans une base de données individuelle, consultez Limites de ressources des bases de données uniques.

Chaque réplica en lecture seule d’un pool élastique dispose de ses propres ressources, comme les vCores, la mémoire, les IOPS de données, tempdb, les Workers et les sessions. Chaque réplica en lecture seule est soumis aux limites de ressources du pool élastique détaillées plus loin dans cet article.

Vous pouvez définir le niveau de service, la taille de calcul (objectif de service) et la quantité de stockage via :

• Transact-SQL via ALTER DATABASE
• portail Azure
• PowerShell
• Azure CLI
• REST API

Si tous les vCore d’un pool élastique sont occupés, chaque base de données du pool reçoit une quantité égale de ressources de calcul pour traiter les requêtes. Azure SQL Database assure un partage équitable des ressources entre les bases de données en garantissant des tranches de temps de calcul égales. Le partage équitable des ressources du pool élastique s’ajoute à n’importe quelle quantité de ressources garantie pour chaque base de données lorsque le nombre minimal de vCore par base de données est défini sur une valeur différente de zéro.

Pour le même nombre de vCores, les ressources fournies à un pool élastique peuvent dépasser les ressources fournies à une base de données unique en dehors d’un pool élastique. Cela signifie qu’il est possible que l’utilisation de l’UC, des E/S de données et de l’écriture de journal d’un pool élastique soit inférieure à la somme de l’utilisation de l’UC, des E/S de données et de l’écriture de journal dans les bases de données du pool, en fonction des modèles de charges de travail. Par exemple, dans un cas extrême avec une seule base de données dans un pool élastique où l’utilisation d’E/S de données de base de données est de 100 %, il est possible que l’utilisation d’E/S de données de pool soit de 50 % pour certains modèles de charges de travail. Cela peut se produire, même si le nombre maximal de vCores par base de données reste à la valeur maximale prise en charge pour la taille de pool donnée.

Usage général - Calcul provisionné - Série standard (Gen5)

Usage général - série standard (Gen5) (partie 1 sur 3)

Les tailles de calcul (objectifs de niveau de service ou SLO) pour les pools élastiques de série standard à usage général obéissent à la convention d’affectation de noms GP_Gen5_ suivie du nombre maximal de vCores.

Le tableau suivant couvre ces SLO : GP_Gen5_2, GP_Gen5_4, GP_Gen5_6, GP_Gen5_8, et GP_Gen5_10 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Pour les valeurs de tailles de données maximales documentées. La réduction de la taille maximale des données réduit proportionnellement la taille maximale du journal.

³ La valeur maximale pour les tailles d’E/S est comprise entre 8 Ko et 64 Ko. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données.

⁴ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise Gen5 et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est de 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est de 50, puisque le nombre maximal de Workers est de 100 sur Gen5. Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁵ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

⁶ nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

Usage général - série standard (Gen5) (partie 2 sur 3)

Les tailles de calcul (objectifs de niveau de service ou SLO) pour les pools élastiques de série standard à usage général obéissent à la convention d’affectation de noms GP_Gen5_ suivie du nombre maximal de vCores.

Le tableau suivant couvre ces SLO : GP_Gen5_12, GP_Gen5_14, GP_Gen5_16, GP_Gen5_18, et GP_Gen5_20 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Pour les valeurs de tailles de données maximales documentées. La réduction de la taille maximale des données réduit proportionnellement la taille maximale du journal.

³ La valeur maximale pour les tailles d’E/S est comprise entre 8 Ko et 64 Ko. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données.

⁴ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁵ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

⁶ nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

Usage général - série standard (Gen5) (partie 3 sur 3)

Les tailles de calcul (objectifs de niveau de service ou SLO) pour les pools élastiques de série standard à usage général obéissent à la convention d’affectation de noms GP_Gen5_ suivie du nombre maximal de vCores.

Le tableau suivant couvre ces SLO : GP_Gen5_24, GP_Gen5_32, GP_Gen5_40, GP_Gen5_80, et GP_Gen5_128 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Pour les valeurs de tailles de données maximales documentées. La réduction de la taille maximale des données réduit proportionnellement la taille maximale du journal.

³ La valeur maximale pour les tailles d’E/S est comprise entre 8 Ko et 64 Ko. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données.

⁴ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁵ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

⁶ nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

Usage général - Calcul provisionné - Série Fsv2

Usage général – série Fsv2 (partie 1 sur 2)

Les tailles de calcul (objectifs de niveau de service ou SLO) pour les pools élastiques de série Fsv2 à usage général obéissent à la convention d’affectation de noms GP_Fsv2_ suivie du nombre de vCores.

Le tableau suivant couvre ces SLO : GP_Fsv2_8, GP_Fsv2_10, GP_Fsv2_12, GP_Fsv2_14, et GP_Fsv2_16 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Pour les valeurs de tailles de données maximales documentées. La réduction de la taille maximale des données réduit proportionnellement la taille maximale du journal.

³ La valeur maximale pour les tailles d’E/S est comprise entre 8 Ko et 64 Ko. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données.

⁴ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁵ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

⁶ nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

Usage général – série Fsv2 (partie 2 sur 2)

Les tailles de calcul (objectifs de niveau de service ou SLO) pour les pools élastiques de série Fsv2 à usage général obéissent à la convention d’affectation de noms GP_Fsv2_ suivie du nombre de vCores.

Le tableau suivant couvre ces SLO : GP_Fsv2_18, GP_Fsv2_20, GP_Fsv2_24, GP_Fsv2_32, GP_Fsv2_36 et GP_Fsv2_72 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Pour les valeurs de tailles de données maximales documentées. La réduction de la taille maximale des données réduit proportionnellement la taille maximale du journal.

³ La valeur maximale pour les tailles d’E/S est comprise entre 8 Ko et 64 Ko. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données.

⁴ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁵ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

⁶ nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

Usage général - Calcul provisionné - Série DC

Usage général – série de contexte de périphérique (partie 1 sur 2)

Les tailles de calcul (objectifs de niveau de service ou SLO) pour les pools élastiques de série de contexte de périphérique à usage général obéissent à la convention d’affectation de noms GP_DC_ suivie du nombre de vCores.

Le tableau suivant couvre ces SLO : GP_DC_2, GP_DC_4, GP_DC_6, GP_DC_8, GP_DC_10 et GP_DC_12 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Pour les valeurs de tailles de données maximales documentées. La réduction de la taille maximale des données réduit proportionnellement la taille maximale du journal.

³ La valeur maximale pour les tailles d’E/S est comprise entre 8 Ko et 64 Ko. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données.

⁴ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁵ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

⁶ Les offres vCore de la série matérielle DC comprises entre 10 et 40 sont actuellement en préversion.

⁷ nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

Usage général – série de contexte de périphérique (partie 2 sur 2)

Les tailles de calcul (objectifs de niveau de service ou SLO) pour les pools élastiques de série de contexte de périphérique à usage général obéissent à la convention d’affectation de noms GP_DC_ suivie du nombre de vCores.

Le tableau suivant couvre ces SLO : GP_DC_14, GP_DC_16, GP_DC_18, GP_DC_20, GP_DC_32 et GP_DC_40 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Pour les valeurs de tailles de données maximales documentées. La réduction de la taille maximale des données réduit proportionnellement la taille maximale du journal.

³ La valeur maximale pour les tailles d’E/S est comprise entre 8 Ko et 64 Ko. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données.

⁴ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁵ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

⁶ Les offres vCore de la série matérielle DC comprises entre 10 et 40 sont actuellement en préversion.

⁷ nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

Critique pour l’entreprise - calcul provisionné - série Standard (Gen5)

Critique pour l'entreprise - série standard (Gen5) (partie 1 sur 3)

Les tailles de calcul (objectifs de niveau de service ou SLO) dans les pools élastiques de série standard critiques pour l'entreprise obéissent à la convention d’affectation de noms BC_Gen5_ suivie du nombre de vCores.

Le tableau suivant couvre ces SLO : BC_Gen5_4, BC_Gen5_6, BC_Gen5_8, BC_Gen5_10, et BC_Gen5_12 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Pour les valeurs de tailles de données maximales documentées. La réduction de la taille maximale des données réduit proportionnellement la taille maximale du journal.

³ La valeur maximale pour les tailles d’E/S est comprise entre 8 Ko et 64 Ko. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données.

⁴ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁵ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

⁶ nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

Critique pour l'entreprise - série standard (Gen5) (partie 2 sur 3)

Les tailles de calcul (objectifs de niveau de service ou SLO) dans les pools élastiques de série standard critiques pour l'entreprise obéissent à la convention d’affectation de noms BC_Gen5_ suivie du nombre de vCores.

Le tableau suivant couvre ces SLO : BC_Gen5_14, BC_Gen5_16, BC_Gen5_18, BC_Gen5_20, et BC_Gen5_24 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Pour les valeurs de tailles de données maximales documentées. La réduction de la taille maximale des données réduit proportionnellement la taille maximale du journal.

³ La valeur maximale pour les tailles d’E/S est comprise entre 8 Ko et 64 Ko. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données.

⁴ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁵ nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

Critique pour l'entreprise - série standard (Gen5) (partie 3 sur 3)

Les tailles de calcul (objectifs de niveau de service ou SLO) dans les pools élastiques de série standard critiques pour l'entreprise obéissent à la convention d’affectation de noms BC_Gen5_ suivie du nombre de vCores.

Le tableau suivant couvre ces SLO : BC_Gen5_32, BC_Gen5_40, BC_Gen5_80, et BC_Gen5_128 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Pour les valeurs de tailles de données maximales documentées. La réduction de la taille maximale des données réduit proportionnellement la taille maximale du journal.

³ La valeur maximale pour les tailles d’E/S est comprise entre 8 Ko et 64 Ko. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données.

⁴ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁵ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

⁶ nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

Vital pour l’entreprise - calcul provisionné - série DC

Critique pour l'entreprise - série de contexte de périphérique (partie 1 sur 2)

Les tailles de calcul (objectifs de niveau de service ou SLO) dans les pools élastiques de série de contexte de périphérique critiques pour l'entreprise obéissent à la convention d’affectation de noms BC_DC_ suivie du nombre de vCores.

Le tableau suivant couvre ces SLO : BC_DC_2, BC_DC_4, BC_DC_6, BC_DC_8, BC_DC_10 et BC_DC_12 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Pour les valeurs de tailles de données maximales documentées. La réduction de la taille maximale des données réduit proportionnellement la taille maximale du journal.

³ La valeur maximale pour les tailles d’E/S est comprise entre 8 Ko et 64 Ko. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données.

⁴ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁵ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

⁶ Les offres vCore de la série matérielle DC comprises entre 10 et 40 sont actuellement en préversion.

⁷ nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

Critique pour l'entreprise - série de contexte de périphérique (partie 2 sur 2)

Les tailles de calcul (objectifs de niveau de service ou SLO) dans les pools élastiques de série de contexte de périphérique critiques pour l'entreprise obéissent à la convention d’affectation de noms BC_DC_ suivie du nombre de vCores.

Le tableau suivant couvre ces SLO : BC_DC_14, BC_DC_16, BC_DC_18, BC_DC_20, BC_DC_32 et BC_DC_40 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Pour les valeurs de tailles de données maximales documentées. La réduction de la taille maximale des données réduit proportionnellement la taille maximale du journal.

³ La valeur maximale pour les tailles d’E/S est comprise entre 8 Ko et 64 Ko. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données.

⁴ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁵ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

⁶ Les offres vCore de la série matérielle DC comprises entre 10 et 40 sont actuellement en préversion.

⁷ nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

Hyperscale - calcul provisionné - série Standard (Gen5)

Bien que les limites de ressources Hyperscale publiées pour les séries standard et premium soient les mêmes, la série premium offre une Analyse des performances plus rapide de l'UC comparé à la série standard et effectue un scale-up à 128 vCores, comparativement à 80 vCores pour la série standard. Les ressources utilisant la série premium sont garanties de fonctionner sur du matériel équipé d'UC plus récents. La série standard ne fournit pas cette garantie et, en fonction de la disponibilité, les ressources peuvent être placées sur du matériel plus ancien. Il n’existe aucune différence de prix entre les deux, mais série Premium est disponible dans certaines régions.

Hyperscale - série standard (Gen5) (partie 1 sur 2)

Les tailles de calcul (objectifs de niveau de service ou SLO) dans les pools élastiques de série standard hyperscale obéissent à la convention d’affectation de noms HS_Gen5_ suivie du nombre de vCores.

Le tableau suivant couvre ces SLO : HS_Gen5_4, HS_Gen5_6, HS_Gen5_8, HS_Gen5_10, HS_Gen5_12 et HS_Gen5_14 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Hyperscale est une architecture multiniveau avec des composants de calcul et de stockage distincts. Pour plus d’informations, consultez Niveau de service Hyperscale et Niveau de service Hyperscale.

³ Outre les E/S de disque SSD local, les charges de travail utilisent les E/S de serveur de pages distant. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données et E/S de données dans les statistiques d’utilisation des ressources. Les nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

⁴ La latence est de 1 à 2 ms pour les données du disque SSD de réplica de calcul local, qui met en cache la plupart des pages de données utilisées. Elle est plus élevée pour les données récupérées à partir des serveurs de pages.

⁵ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁶ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

Hyperscale - série standard (Gen5) (partie 2 sur 2)

Les tailles de calcul (objectifs de niveau de service ou SLO) dans les pools élastiques de série standard hyperscale obéissent à la convention d’affectation de noms HS_Gen5_ suivie du nombre de vCores.

Le tableau suivant couvre ces SLO : HS_Gen5_16, HS_Gen5_18, HS_Gen5_20, HS_Gen5_24, HS_Gen5_32, HS_Gen5_40 et HS_Gen5_80 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Hyperscale est une architecture multiniveau avec des composants de calcul et de stockage distincts. Pour plus d’informations, consultez Niveau de service Hyperscale et Niveau de service Hyperscale.

³ Outre les E/S de disque SSD local, les charges de travail utilisent les E/S de serveur de pages distant. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données et E/S de données dans les statistiques d’utilisation des ressources. Les nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

⁴ La latence est de 1 à 2 ms pour les données du disque SSD de réplica de calcul local, qui met en cache la plupart des pages de données utilisées. Elle est plus élevée pour les données récupérées à partir des serveurs de pages.

⁵ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁶ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

Série Premium Hyperscale

Série Premium Hyperscale (partie 1 sur 3)

Les tailles de calcul (objectifs de niveau de service ou SLO) pour les pools élastiques Hyperscale série premium suivent la convention d’affectation de noms HS_PRMS_ suivie par le nombre de vCore maximum.

Le tableau suivant couvre ces SLO : HS_PRMS_4, HS_PRMS_6, HS_PRMS_8, HS_PRMS_10, HS_PRMS_12 et HS_PRMS_14 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Hyperscale est une architecture multiniveau avec des composants de calcul et de stockage distincts. Pour plus d’informations, consultez Niveau de service Hyperscale et Niveau de service Hyperscale.

³ Outre les E/S de disque SSD local, les charges de travail utilisent les E/S de serveur de pages distant. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données et E/S de données dans les statistiques d’utilisation des ressources. Les nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

⁴ La latence est de 1 à 2 ms pour les données du disque SSD de réplica de calcul local, qui met en cache la plupart des pages de données utilisées. Elle est plus élevée pour les données récupérées à partir des serveurs de pages.

⁵ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁶ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

Série Premium Hyperscale (partie 2 sur 3)

Les tailles de calcul (objectifs de niveau de service ou SLO) pour les pools élastiques Hyperscale série premium suivent la convention d’affectation de noms HS_PRMS_ suivie par le nombre de vCore maximum.

Le tableau suivant couvre ces SLO : HS_PRMS_16, HS_PRMS_18, HS_PRMS_20, HS_PRMS_24, HS_PRMS_32 et HS_PRMS_40 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Hyperscale est une architecture multiniveau avec des composants de calcul et de stockage distincts. Pour plus d’informations, consultez Niveau de service Hyperscale et Niveau de service Hyperscale.

³ Outre les E/S de disque SSD local, les charges de travail utilisent les E/S de serveur de pages distant. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données et E/S de données dans les statistiques d’utilisation des ressources. Les nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

⁴ La latence est de 1 à 2 ms pour les données du disque SSD de réplica de calcul local, qui met en cache la plupart des pages de données utilisées. Elle est plus élevée pour les données récupérées à partir des serveurs de pages.

⁵ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁶ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

Série Premium Hyperscale (partie 3 sur 3)

Les tailles de calcul (objectifs de niveau de service ou SLO) pour les pools élastiques Hyperscale série premium suivent la convention d’affectation de noms HS_PRMS_ suivie par le nombre de vCore maximum.

La table suivante couvre ces SLO : HS_PRMS_64, HS_PRMS_80, HS_PRMS_128 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Hyperscale est une architecture multiniveau avec des composants de calcul et de stockage distincts. Pour plus d’informations, consultez Niveau de service Hyperscale et Niveau de service Hyperscale.

³ Outre les E/S de disque SSD local, les charges de travail utilisent les E/S de serveur de pages distant. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données et E/S de données dans les statistiques d’utilisation des ressources. Les nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

⁴ La latence est de 1 à 2 ms pour les données du disque SSD de réplica de calcul local, qui met en cache la plupart des pages de données utilisées. Elle est plus élevée pour les données récupérées à partir des serveurs de pages.

⁵ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁶ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

Série Premium Hyperscale à mémoire optimisée

Série Premium Hyperscale à mémoire optimisée (partie 1 sur 3)

Les tailles de calcul (objectifs de niveau de service ou SLO) pour les pools élastiques Hyperscale à mémoire optimisée série premium suivent la convention d’affectation de noms HS_MOPRMS_ suivie par le nombre de vCore maximum.

Le tableau suivant couvre ces SLO : HS_MOPRMS_4, HS_MOPRMS_6, HS_MOPRMS_8, HS_MOPRMS_10, HS_MOPRMS_12 et HS_MOPRMS_14 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Hyperscale est une architecture multiniveau avec des composants de calcul et de stockage distincts. Pour plus d’informations, consultez Niveau de service Hyperscale et Niveau de service Hyperscale.

³ Outre les E/S de disque SSD local, les charges de travail utilisent les E/S de serveur de pages distant. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez de gouvernance des E/S des données et les E/S de données dans les statistiques d’utilisation des ressources. Les nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

⁴ La latence est de 1 à 2 ms pour les données du disque SSD de réplica de calcul local, qui met en cache la plupart des pages de données utilisées. Elle est plus élevée pour les données récupérées à partir des serveurs de pages.

⁵ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁶ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

Série Premium Hyperscale à mémoire optimisée (partie 2 sur 3)

Les tailles de calcul (objectifs de niveau de service ou SLO) pour les pools élastiques Hyperscale à mémoire optimisée série premium suivent la convention d’affectation de noms HS_MOPRMS_ suivie par le nombre de vCore maximum.

Le tableau suivant couvre ces SLO : HS_MOPRMS_16, HS_MOPRMS_18, HS_MOPRMS_20, HS_MOPRMS_24, HS_MOPRMS_32 et HS_MOPRMS_40 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Hyperscale est une architecture multiniveau avec des composants de calcul et de stockage distincts. Pour plus d’informations, consultez Niveau de service Hyperscale et Niveau de service Hyperscale.

³ Outre les E/S de disque SSD local, les charges de travail utilisent les E/S de serveur de pages distant. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données et E/S de données dans les statistiques d’utilisation des ressources. Les nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

⁴ La latence est de 1 à 2 ms pour les données du disque SSD de réplica de calcul local, qui met en cache la plupart des pages de données utilisées. Elle est plus élevée pour les données récupérées à partir des serveurs de pages.

⁵ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁶ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

Série Premium Hyperscale à mémoire optimisée (partie 3 sur 3)

Les tailles de calcul (objectifs de niveau de service ou SLO) pour les pools élastiques Hyperscale à mémoire optimisée série premium suivent la convention d’affectation de noms HS_MOPRMS_ suivie par le nombre de vCore maximum.

La table suivante couvre ces SLO : HS_MOPRMS_64 et HS_MOPRMS_80 :

¹ Consultez Gestion des ressources dans les pools élastiques denses pour obtenir des informations supplémentaires.

² Hyperscale est une architecture multiniveau avec des composants de calcul et de stockage distincts. Pour plus d’informations, consultez Niveau de service Hyperscale et Niveau de service Hyperscale.

³ Outre les E/S de disque SSD local, les charges de travail utilisent les E/S de serveur de pages distant. Les IOPS réelles dépendent de la charge de travail. Pour plus d’informations, consultez Gouvernance des E/S de données et E/S de données dans les statistiques d’utilisation des ressources. Les nombres de latence sont approximatifs et représentatifs pour les charges de travail classiques à l’état stable, mais ne sont pas garantis.

⁴ La latence est de 1 à 2 ms pour les données du disque SSD de réplica de calcul local, qui met en cache la plupart des pages de données utilisées. Elle est plus élevée pour les données récupérées à partir des serveurs de pages.

⁵ Pour le nombre maximal de workers simultanés pour une base de données individuelle, consultez les limites de ressources pour les bases de données uniques à l’aide du modèle d’achat vCore. Par exemple, si le pool élastique utilise la série Standard (Gen5) et que le nombre maximal de vCores par base de données est défini sur 2, le nombre maximal de Workers simultanés est 200. Si le nombre maximal de vCores par base de données est défini sur 0,5, le nombre maximal de Workers simultanés est 50, puisque le nombre maximal de Workers est de 100 sur la série Standard (Gen5). Pour les autres paramètres de nombre maximal de vCores par base de données qui sont inférieurs ou égaux à 1 vCore, le nombre maximum de Workers simultanés est adapté en conséquence.

⁶ Pour plus d’informations sur ce qui compte comme une connexion externe, consultez Connexions externes.

Matériel précédemment disponible

Cette section contient des détails sur le matériel précédemment disponible.

• Le matériel Gen4 a été mis hors service et n’est plus disponible pour le provisionnement, le scale-up ni le scale-down. Migrez votre base de données vers un matériel d’une génération prise en charge pour bénéficier de plus grandes possibilités en matière de scalabilité des vCores et du stockage, de performances réseau accélérées, de meilleures performances d’E/S et d’une latence minimale. Pour plus d’informations, consultez La prise en charge a pris fin pour le matériel Gen4 sur Azure SQL Database.

Vous pouvez vous servir d’Azure Resource Graph Explorer pour identifier toutes les ressources Azure SQL Database qui utilisent actuellement du matériel Gen4, ou bien vérifier le matériel exploité par les ressources pour un serveur logique spécifique sur le Portail Azure.

Vous devez au minimum disposer d’autorisations read sur l’objet ou le groupe d’objets Azure pour voir les résultats dans l’Explorateur Azure Resource Graph.

Pour utiliser l’Explorateur Resource Graph afin d’identifier les ressources Azure SQL qui utilisent toujours du matériel Gen4, effectuez les étapes suivantes :

1. Accédez au portail Azure.

2. Recherchez Resource graph dans la zone de recherche, puis choisissez le service Explorateur Resource Graph dans les résultats de la recherche.

3. Dans la fenêtre de requête, tapez la requête suivante, puis sélectionnez Exécuter la requête :

   resources
   | where type contains ('microsoft.sql/servers')
   | where sku['family'] == "Gen4"
   

4. Le volet Résultats affiche toutes les ressources actuellement déployées dans Azure qui utilisent du matériel Gen4.

   

Pour vérifier le matériel utilisé par les ressources sur un serveur logique spécifique dans Azure, effectuez les étapes suivantes :

1. Accédez au portail Azure.
2. Recherchez SQL servers dans la zone de recherche, puis choisissez Serveurs SQL dans les résultats de la recherche pour ouvrir la page Serveurs SQL et afficher tous les serveurs du ou des abonnements choisis.
3. Sélectionnez le serveur souhaité pour ouvrir la page Vue d’ensemble du serveur.
4. Faites défiler la page jusqu’aux ressources disponibles, puis consultez la colonne Niveau tarifaire des ressources qui utilisent du matériel Gen4.

Pour migrer des ressources vers du matériel de série standard, consultez Modifier le matériel.

Contenu connexe

• Pour connaître les limites de ressources vCore d’une base de données unique, consultez l’article consacré aux limites de ressources pour les bases de données uniques suivant le modèle d’achat vCore
• Pour plus d’informations sur les limites générales d’Azure, consultez Abonnement Azure et limites, quotas et contraintes du service.
• Pour plus d'informations sur les limites de ressources sur un serveur SQL logique et au niveau de l’abonnement, consultez la vue d'ensemble des limites de ressources sur un serveur SQL logique.