Vue d’ensemble des limites de ressources Azure SQL Managed Instance

  • Article
  • 21 minutes de lecture

S’applique à : Azure SQL Managed Instance

Cet article fournit une vue d’ensemble des caractéristiques techniques et des limites des ressources pour Azure SQL Managed Instance, ainsi que des informations sur la façon de demander une augmentation de ces limites.

Notes

Pour connaître les différences entre les fonctionnalités prises en charge et les instructions T-SQL, consultez Différences de fonctionnalités et Prise en charge des instructions T-SQL. Pour les différences générales entre les niveaux de service pour Azure SQL Database et SQL Managed Instance, consultez les niveaux de service Usage général et Critique pour l’entreprise.

Caractéristiques de la configuration matérielle

SQL Managed Instance a des caractéristiques et des limites de ressources qui dépendent de l’infrastructure et de l’architecture sous-jacentes. SQL Managed Instance peut être déployé sur plusieurs configurations matérielles.

Notes

Le matériel Gen5 a été renommé en série standard (Gen5).

Pour plus d’informations sur le matériel précédemment disponible, consultez Matériel précédemment disponible plus loin dans cet article.

Les configurations matérielles ont différentes caractéristiques, qui sont décrites dans le tableau suivant :

Série Standard (Gen5) Série Premium Série Premium à mémoire optimisée
UC Processeurs Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake) et Intel® 8272CL (Cascade Lake) 2,5 GHz Processeurs Intel® 8370C (Ice Lake) 2,8 GHz Processeurs Intel® 8370C (Ice Lake) 2,8 GHz
Nombre de vCore
vCore = 1 LP (hyperthread)		 4-80 vCores 4-80 vCores 4-64 vCores
Mémoire maximale (rapport mémoire/vCore) 5,1 Go par vCore
Ajoutez plus de vCores pour obtenir davantage de mémoire.		 7 Go par vCore 13,6 Go par vCore
Mémoire OLTP maximale en mémoire Limite de l’instance : 0,8 à 1,65 Go par vCore Limite de l’instance : 1,1 à 2,3 Go par vCore Limite de l’instance : 2,2 à 4,5 Go par vCore
Stockage réservé d’instance maximal Usage général : jusqu’à 16 To
Critique pour l’entreprise : jusqu’à 4 To		 Usage général : jusqu’à 16 To
Critique pour l’entreprise : jusqu’à 5,5 To		 Usage général : jusqu’à 16 To
Critique pour l’entreprise : jusqu’à 16 To

* Dépend du nombre de vCores.

Notes

Si votre charge de travail nécessite des tailles de stockage supérieures aux limites de ressources disponibles pour Azure SQL Managed Instance, envisagez le niveau de service Hyperscale d’Azure SQL Database.

Support régional pour le matériel de la série Premium à mémoire optimisée

La prise en charge du matériel de la série Premium à mémoire optimisée est actuellement disponible seulement dans ces régions spécifiques :

Geography Régions prenant en charge du matériel de la série Premium à mémoire optimisée
Europe, Moyen-Orient, Afrique France Centre, Allemagne Centre-Ouest, Europe Nord, Suède Centre, Royaume-Uni Sud, Europe Ouest
Amérique Brésil Sud, Canada Centre, USA Centre, USA Est, USA Est 2, USA Centre Nord, USA Centre Sud, USA Ouest, USA Ouest 2, USA Ouest 3
Asie-Pacifique Australie Est, Australie Sud-Est, Inde Centre, Asie Est, Japon Est, Asie Sud-Est

Espace disponible OLTP en mémoire

La quantité d’espace OLTP en mémoire dans le niveau de service Critique pour l’entreprise dépend du nombre de vCores et de la configuration matérielle. Le tableau suivant liste les limites de mémoire utilisable pour des objets OLTP en mémoire.

vCores Série Standard (Gen5) Série Premium Série Premium à mémoire optimisée
4 vCores 3,14 Go 4,39 Go 8,79 Go
8 vCores 6,28 Go 8,79 Go 22,06 Go
16 vCores 15,77 Go 22,06 Go 57,58 Go
24 vCores 25,25 Go 35,34 Go 93,09 Go
32 vCores 37,94 Go 53,09 Go 128,61 Go
40 vCores 52,23 Go 73,09 Go 164,13 Go
64 vCores 99,9 Go 139,82 Go 288,61 Go
80 vCores 131,68 Go 184,30 Go N/A

Caractéristiques du niveau de service

SQL Managed Instance a deux niveaux de service : Usage général et Critique pour l’entreprise.

Important

Le niveau de service Critique pour l’entreprise fournit une copie intégrée supplémentaire de l’instance managée SQL (réplica secondaire) qui peut être utilisée pour les charges de travail en lecture seule. Si vous pouvez séparer les requêtes de lecture-écriture des requêtes en lecture seule/analytique/de création de rapports, vous obtenez deux fois plus de vCores et de mémoire pour le même prix. Le réplica secondaire peut présenter un décalage de quelques secondes par rapport à l’instance principale. Il est donc conçu pour déplacer les charges de travail de création de rapports/analytiques qui n’ont pas besoin de l’état actuel exact des données. Dans le tableau suivant, les requêtes en lecture seule sont les requêtes exécutées sur le réplica secondaire.

Fonctionnalité Usage général Critique pour l’entreprise
Nombre de vCores* 4, 8, 16, 24, 32, 40, 64, 80 Série Standard (Gen5) : 4, 8, 16, 24, 32, 40, 64, 80
Série Premium : 4, 8, 16, 24, 32, 40, 64, 80
Série Premium à mémoire optimisée : 4, 8, 16, 24, 32, 40, 64
*Le même nombre de vCores est dédié aux requêtes en lecture seule.
Mémoire maximale Série Standard (Gen5) : 20,4 Go à 625 Go (5,1 Go/vCore)
Série Premium : 28 Go à 560 Go (7 Go/vCore)
Série Premium à mémoire optimisée : 54,4 Go à 870,4 Go (13,6 Go/vCore)		 Série Standard (Gen5) : 20,4 Go à 625 Go (5,1 Go/vCore) sur chaque réplica
Série Premium : 28 Go à 560 Go (7 Go/vCore) sur chaque réplica
Série Premium à mémoire optimisée : 54,4 Go à 870,4 Go (13,6 Go/vCore) sur chaque réplica
Taille de stockage maximale d’instance (réservée) - 2 To pour 4 vCores
- 8 To pour 8 vCores
- 16 To pour les autres tailles
 Série Standard (Gen5) :
- 1 To pour 4, 8, 16 vCores
- 2 To pour 24 vCores
- 4 To pour 32, 40, 64, 80 vCores
Série Premium :
- 1 To pour 4, 8 vCores
- 2 To pour 16, 24 vCores
- 4 To pour 32 vCores
- 5,5 To pour 40, 64, 80 vCores
Série Premium à mémoire optimisée :
- 1 To pour 4, 8 vCores
- 2 To pour 16, 24 vCores
- 4 To pour 32 vCores
- 5,5 To pour 40 vCores
- 16 To pour 64 vCores
Taille de base de données maximale Jusqu’à la taille d’instance actuellement disponible (en fonction du nombre de vCores). Jusqu’à la taille d’instance actuellement disponible (en fonction du nombre de vCores).
Taille maximale de la base de données tempdb Limitée à 24 Go/vCore (96-1920 Go) et à la taille de stockage d’instance actuellement disponible.
Ajoutez plus de vCores pour obtenir davantage d’espace tempdb.
La taille du fichier journal est limitée à 120 Go.		 Jusqu’à la taille de stockage d’instance actuellement disponible.
Nombre maximal de fichiers tempdb 128 128
Nombre maximal de bases de données par instance 100 bases de données utilisateur, sauf si la limite de taille de stockage d’instance a été atteinte. 100 bases de données utilisateur, sauf si la limite de taille de stockage d’instance a été atteinte.
Nombre maximal de fichiers de base de données par instance Jusqu’à 280, sauf si la limite de taille de stockage d’instance ou d’espace d’allocation de stockage sur disque Premium Azure a été atteinte. 32 767 fichiers par base de données, sauf si la limite de taille de stockage d’instance a été atteinte.
Taille maximale du fichier de données La taille maximale de chaque fichier de données est de 8 To. Utilisez au moins deux fichiers de données pour les bases de données de plus de 8 To. Jusqu’à la taille d’instance actuellement disponible (en fonction du nombre de vCores).
Taille maximale du fichier journal Limitée à 2 To et à la taille de stockage d’instance actuellement disponible. Limitée à 2 To et à la taille de stockage d’instance actuellement disponible.
IOPS de données/journal (approximatives) 500 - 7500 par fichier
**		 16 000 à 320 000 (4 000 IOPS/vCore)
Ajoutez plus de vCores pour obtenir de meilleures performances d’E/S.
Limite du débit d’écriture du journal (par instance) 4.5 Mio/s par vCore
120 Mio/s max. par instance
22 à 65 Mio/s par base de données (selon la taille du fichier journal)
**		 4.5 Mio/s par vCore
96 Mio/s max.
Débit de données (approximatif) 100 à 250 Mio/s par fichier
**		 Non limité.
Latence d’E/S de stockage (approximative) 5 - 10 ms 1 - 2 ms
OLTP en mémoire Non pris en charge Disponible, la taille dépend du nombre de vCores
Nombre maximal de sessions 30000 30000
Nombre maximal de workers simultanés 105 * nombre de vCores + 800 105 * nombre de vCores + 800
Réplicas en lecture seule 0 1 (inclus dans le prix)
Isolation du calcul Non pris en charge, car des instances Usage général peuvent partager du matériel physique avec d’autres instances Série Standard (Gen5) :
Pris en charge pour 40, 64, 80 vCores
Série Premium : pris en charge pour 64, 80 vCores
Série Premium à mémoire optimisée : pris en charge pour 64 vCores

Quelques considérations supplémentaires :

  • La taille de stockage d’instance actuellement disponible est la différence entre la taille d’instance réservée et l’espace de stockage utilisé.
  • Les tailles des données et des fichiers journaux dans les bases de données utilisateur et système sont comprises dans la taille de stockage d’instance qui est comparée à la limite de taille de stockage maximale. Utilisez la vue système sys.master_files pour déterminer l’espace total utilisé par les bases de données. Les journaux d’activité d’erreurs ne sont ni conservés ni compris dans la taille. Les sauvegardes ne sont pas comprises dans la taille de stockage.
  • Le débit et les IOPS dans le niveau Usage général dépendent également de la taille de page qui n’est pas explicitement limitée par l’instance managée SQL. Vous pouvez créer un autre réplica lisible dans une région Azure différente à l’aide de groupes de basculement automatique.
  • Le nombre maximal d’IOPS d’instance dépend de la disposition des fichiers et de la distribution de la charge de travail. Par exemple, si vous créez sept fichiers de 1 To avec un maximum de 5 000 IOPS et sept petits fichiers (moins de 128 Go) avec 500 IOPS chacun, vous pouvez obtenir 38500 IOPS par instance (7x5000+7x500) si votre charge de travail peut utiliser tous les fichiers. Notez que certaines IOPS sont également utilisées pour les sauvegardes automatiques.
  • Les noms de fichiers tempdb ne peuvent pas comporter plus de 16 caractères.

Vous trouverez plus d’informations sur les limites des ressources dans les pools SQL Managed Instance dans cet article.

Stockage des données et des journaux

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

  • Au niveau de service Usage général, tempdb utilise un disque SSD local et le coût de ce stockage est inclus dans le prix du modèle vCore.
  • Au niveau de service Critique pour l'entreprise, tempdb partage le disque SSD local avec les données et les fichiers journaux, et le coût du stockage tempdb est inclus dans le prix du modèle vCore.
  • La taille de stockage maximale d'une instance de SQL Managed Instance doit être spécifiée en multiples de 32 Go.

Important

Pour les deux niveaux de service, vous êtes facturé en fonction de la taille de stockage maximale configurée pour une instance managée.

Pour surveiller la taille totale de stockage d’instance consommée pour SQL Managed Instance, utilisez la métriquestorage_space_used_mb. Pour surveiller la taille de stockage actuellement allouée et utilisée par les données individuelles et les fichiers journaux dans une base de données à l'aide de T-SQL, utilisez la vue sys.database_files et la fonction FILEPROPERTY(... , 'SpaceUsed').

Conseil

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

Sauvegardes et stockage

Du stockage est alloué pour les sauvegardes de base de données afin de prendre en charge les fonctionnalités de récupération jusqu’à une date et heure (PITR) et de conservation à long terme (LTR) de SQL Managed Instance. Ce stockage, distinct du stockage des données et des fichiers journaux, est facturé séparément.

  • Récupération jusqu'à une date et heure (PITR) : aux niveaux Usage général et Critique pour l'entreprise, les sauvegardes de bases de données individuelles sont automatiquement copiées vers le stockage géographiquement redondant avec accès en lecture (RA-GRS). La taille de stockage augmente dynamiquement avec chaque nouvelle création de sauvegarde. Le service est utilisé par les sauvegardes complètes, les sauvegardes différentielles et les sauvegardes de fichiers journaux. La consommation du stockage dépend du taux de change de la base de données et de la période de rétention configurée pour les sauvegardes. Vous pouvez configurer une période de rétention distincte pour chaque base de données : de 0 à 35 pour SQL Managed Instance. Une quantité de stockage de sauvegarde égale à la taille maximale des données configurées est fournie sans frais supplémentaires.
  • Conservation à long terme (LTR) : vous pouvez également configurer la conservation à long terme des sauvegardes complètes pendant 10 ans maximum. Si vous configurez une stratégie de conservation à long terme, ces sauvegardes sont stockées automatiquement dans le stockage RA-GRS. Toutefois, vous pouvez contrôler la fréquence à laquelle les sauvegardes sont copiées. Pour répondre aux différentes exigences de conformité, vous pouvez sélectionner plusieurs périodes de conservation pour les sauvegardes hebdomadaires, mensuelles ou annuelles. La configuration que vous choisissez détermine la quantité de stockage utilisée pour les sauvegardes de conservation à long terme. Pour plus d’informations, consultez Conservation des sauvegardes à long terme.

Caractéristiques d’E/S de fichier avec le niveau Usage général

Avec le niveau de service Usage général, chaque fichier de base de données reçoit des IOPS et un débit dédiés qui dépendent de la taille du fichier. Les fichiers plus volumineux reçoivent plus d’IOPS et de débit. Les caractéristiques d’E/S des fichiers de base de données sont indiquées dans le tableau suivant :

Taille du fichier >=0 et <=129 Gio >129 et <=513 Gio >513 et <=1025 Gio >1025 et <=2049 Gio >2049 et <=4097 Gio >4097 Gio et <=8 Tio
IOPS par fichier 500 2300 5 000 7500 7500 12 500
Débit par fichier 100 Mio/s 150 Mio/s 200 Mio/s 250 Mio/s 250 Mio/s 250 Mio/s

Si vous constatez une latence élevée des E/S sur un fichier de base de données, ou si vous constatez que les IOPS ou le débit atteignent la limite, vous pouvez améliorer les performances en augmentant la taille de fichier.

Il existe également une limite au niveau de l’instance pour le débit maximal d’écriture dans le journal (voir le tableau précédent pour les valeurs, par exemple., 22 Mio/s) ; ainsi, vous ne pourrez peut-être pas atteindre le débit de fichier maximal dans le fichier journal, car vous atteignez la limite de débit de l’instance.

Régions prises en charge

SQL Managed Instance peut être créé uniquement dans des régions prises en charge. Si vous voulez créer une instance managée SQL dans une région qui n’est actuellement pas prise en charge, vous pouvez envoyer une demande de support par le biais du portail Microsoft Azure.

Types d’abonnements pris en charge

SQL Managed Instance prend actuellement en charge le déploiement uniquement sur les types d’abonnements suivants :

Limitations des ressources régionales

Notes

Pour obtenir les dernières informations sur la disponibilité des régions pour les abonnements, veuillez d’abord sélectionner une région.

Les types d’abonnements pris en charge peuvent contenir un nombre limité de ressources par région. SQL Managed Instance a deux limites par défaut par région Azure (qui peuvent être augmentées à la demande en créant une demande spéciale de support dans le portail Azure) en fonction du type d’abonnement :

  • Limite de sous-réseaux : nombre maximal de sous-réseaux sur lesquels des instances managées SQL sont déployées dans une seule et même région.
  • Limite d’unités de vCore : nombre maximal d’unités de vCores qui peuvent être déployées parmi toutes les instances dans une seule région. Un vCore GP utilise une unité de vCore et un vCore BC prend quatre unités de vCore. Le nombre total d’instances n’est pas limité du moment qu’il se trouve dans la limite du nombre d’unités de vCores.

Notes

Ces limites sont des paramètres par défaut : il ne s’agit pas de limitations techniques. Ces limites peuvent être augmentées en créant une demande de support spéciale dans le portail Microsoft Azure si vous avez besoin de plus d’instances dans la région actuelle. Vous pouvez aussi créer des instances managées SQL dans une autre région Azure sans envoyer de demandes de support.

Le tableau suivant montre les limites régionales par défaut pour les types d’abonnement pris en charge (les limites par défaut peuvent être étendues à l’aide d’une demande de support) :

Type d’abonnement Limite par défaut pour les sous-réseaux SQL Managed Instance Limite par défaut pour les unités vCore*
CSP 16 (30 dans certaines régions**) 960 (1 440 dans certaines régions**)
EA 16 (30 dans certaines régions**) 960 (1 440 dans certaines régions**)
Enterprise Dev/Test 6 320
Paiement à l’utilisation 6 320
Pay-As-You-Go Dev/Test 6 320
Pass Azure 3 64
BizSpark 3 64
BizSpark Plus 3 64
Microsoft Azure Sponsorship 3 64
Microsoft Partner Network 3 64
Visual Studio Enterprise (MPN) 3 64
Visual Studio Enterprise 3 32
Visual Studio Enterprise (BizSpark) 3 32
Visual Studio Professional 3 32
Plateformes MSDN 3 32

* Lors de la planification de déploiements, prenez en considération le fait que le niveau de service Critique pour l’entreprise (BC) requiert quatre (4) fois plus de capacité de vCore que le niveau de service Usage général (GP). Exemple : 1 vCore GP = 1 unité vCore et 1 vCore BC = 4 vCore. Pour simplifier votre analyse de la consommation par rapport aux limites par défaut, récapitulez les unités vCore de tous les sous-réseaux de la région où SQL Managed Instance est déployé et comparez les résultats avec les limites d’unités d’instance pour votre type d’abonnement. La limite Nombre maximal d’unités de vCore s’applique à chaque abonnement dans une région. Il n’y a pas de limite par sous-réseau individuel sauf que la somme de tous les vCores déployés sur plusieurs sous-réseaux doit être inférieure ou égale à nombre maximum d’unités vCore.

** Des limites de sous-réseau et de vCore plus importantes s’appliquent dans les régions suivantes : Australie Est, USA Est, USA Est 2, Europe Nord, USA Centre Sud, Asie Sud-Est, Royaume-Uni Sud, Europe Ouest, USA Ouest 2.

Important

Si la limite de vCore et de sous-réseau est 0, cela signifie que la limite régionale par défaut pour votre type d’abonnement n’est pas définie. Vous pouvez également utiliser la demande d’augmentation de quota pour obtenir l’accès à l’abonnement dans une région spécifique en suivant la même procédure, en fournissant les valeurs de vCore et de sous-réseau requises.

Demander une augmentation de quota

Si vous avez besoin de davantage d’instances dans vos régions actuelles, vous pouvez envoyer une demande de support pour étendre le quota par le biais du portail Azure. Pour plus d’informations, consultez Demander des augmentations de quota pour Azure SQL Database.

Matériel précédemment disponible

Cette section contient des détails sur le matériel précédemment disponible. Songez à déplacer votre instance de SQL Managed Instance vers le matériel de la série Standard (Gen5) pour profiter d’une plus grande scalabilité en termes de vCore et de stockage, de performances réseau accélérées, d’un niveau de performance d’E/S optimal et d’une latence minimale.

Important

Comme annoncé le 18 décembre 2019, le matériel Gen4 est en cours de mise hors service et n’est pas disponible pour les nouveaux déploiements. Les clients utilisant le matériel Gen4 pour une base de données Azure SQL, des pools élastiques ou une instance gérée SQL doivent migrer vers du matériel actuellement disponible, comme la série standard (Gen5), avant le 31 mars 2023.

D’ici au 31 mars 2023, les instances SQL Gen4 gérées existantes seront migrées automatiquement vers du matériel équivalent ou supérieur. Si elles sont mises à niveau automatiquement, les instances gérées peuvent être mises à niveau vers du matériel de série Premium, ce qui entraîne une augmentation des prix conformément à la tarification.

Les temps d’arrêt occasionnés par la migration automatique seront minimes et similaires aux temps d’arrêt pendant les opérations de mise à l’échelle au sein du niveau de service sélectionné. Pour éviter des interruptions non planifiées de charges de travail, effectuez une migration de manière proactive au moment de votre choix avant le 31 mars 2023. Pour plus d’informations sur la mise hors service du matériel Gen4 et la migration vers du matériel actuel, consultez notre billet de blog sur la mise hors service de Gen4.

Caractéristiques du matériel

Gen4
Matériel Processeurs Intel® E5-2673 v3 (Haswell) 2,4 GHz, disque SSD attaché, vCore = 1 PP (cœur physique)
Nombre de vCore 8, 16, 24 vCores
Mémoire maximale (ratio mémoire/cœur) 7 Go par vCore
Ajoutez plus de vCores pour obtenir davantage de mémoire.
Mémoire OLTP maximale en mémoire Limite de l’instance : 1 à 1,5 Go par vCore
Stockage réservé d’instances maximal Usage général : 8 To
Critique pour l’entreprise : 1 To

Espace disponible OLTP en mémoire

Important

Comme annoncé le 18 décembre 2019, le matériel Gen4 est en cours de mise hors service et n’est pas disponible pour les nouveaux déploiements. Les clients utilisant le matériel Gen4 pour une base de données Azure SQL, des pools élastiques ou une instance gérée SQL doivent migrer vers du matériel actuellement disponible, comme la série standard (Gen5), avant le 31 mars 2023.

D’ici au 31 mars 2023, les instances SQL Gen4 gérées existantes seront migrées automatiquement vers du matériel équivalent ou supérieur. Si elles sont mises à niveau automatiquement, les instances gérées peuvent être mises à niveau vers du matériel de série Premium, ce qui entraîne une augmentation des prix conformément à la tarification.

Les temps d’arrêt occasionnés par la migration automatique seront minimes et similaires aux temps d’arrêt pendant les opérations de mise à l’échelle au sein du niveau de service sélectionné. Pour éviter des interruptions non planifiées de charges de travail, effectuez une migration de manière proactive au moment de votre choix avant le 31 mars 2023. Pour plus d’informations sur la mise hors service du matériel Gen4 et la migration vers du matériel actuel, consultez notre billet de blog sur la mise hors service de Gen4.

La quantité d’espace OLTP en mémoire dans le niveau de service Critique pour l’entreprise dépend du nombre de vCores et de la configuration matérielle. Le tableau suivant liste les limites de mémoire utilisable pour des objets OLTP en mémoire.

Espace OLTP en mémoire Gen4
8 vCores 8 Go
16 vCores 20 Go
24 vCores 36 Go

Caractéristiques du niveau de service

Important

Comme annoncé le 18 décembre 2019, le matériel Gen4 est en cours de mise hors service et n’est pas disponible pour les nouveaux déploiements. Les clients utilisant le matériel Gen4 pour une base de données Azure SQL, des pools élastiques ou une instance gérée SQL doivent migrer vers du matériel actuellement disponible, comme la série standard (Gen5), avant le 31 mars 2023.

D’ici au 31 mars 2023, les instances SQL Gen4 gérées existantes seront migrées automatiquement vers du matériel équivalent ou supérieur. Si elles sont mises à niveau automatiquement, les instances gérées peuvent être mises à niveau vers du matériel de série Premium, ce qui entraîne une augmentation des prix conformément à la tarification.

Les temps d’arrêt occasionnés par la migration automatique seront minimes et similaires aux temps d’arrêt pendant les opérations de mise à l’échelle au sein du niveau de service sélectionné. Pour éviter des interruptions non planifiées de charges de travail, effectuez une migration de manière proactive au moment de votre choix avant le 31 mars 2023. Pour plus d’informations sur la mise hors service du matériel Gen4 et la migration vers du matériel actuel, consultez notre billet de blog sur la mise hors service de Gen4.

Fonctionnalité Usage général Critique pour l’entreprise
Nombre de vCores* 8, 16, 24 8, 16, 24
*Le même nombre de vCores est dédié aux requêtes en lecture seule.
Mémoire maximale 56-168 Go (7 Go/vCore)
Ajoutez plus de vCores pour obtenir davantage de mémoire.		 56-168 Go (7 Go/vCore)
+ 20,4 Go-408 Go (5,1 Go/vCore) supplémentaires pour les requêtes en lecture seule.
Ajoutez plus de vCores pour obtenir davantage de mémoire.
Taille de stockage maximale d’instance (réservée) 8 To 1 To
Taille de base de données maximale Jusqu’à la taille d’instance actuellement disponible (maximum 2-8 To en fonction du nombre de vCores). Jusqu’à la taille d’instance actuellement disponible (maximum 1-4 To en fonction du nombre de vCores).
Taille maximale de la base de données tempdb Limitée à 24 Go/vCore (96-1920 Go) et à la taille de stockage d’instance actuellement disponible.
Ajoutez plus de vCores pour obtenir davantage d’espace tempdb.
La taille du fichier journal est limitée à 120 Go.		 Jusqu’à la taille de stockage d’instance actuellement disponible.
Nombre maximal de bases de données par instance 100 bases de données utilisateur, sauf si la limite de taille de stockage d’instance a été atteinte. 100 bases de données utilisateur, sauf si la limite de taille de stockage d’instance a été atteinte.
Nombre maximal de fichiers de base de données par instance Jusqu’à 280, sauf si la taille de stockage d’instance ou la limite d’espace d’allocation de stockage sur disque Premium Azure ont été atteintes. 32 767 fichiers par base de données, sauf si la limite de taille de stockage d’instance a été atteinte.
Taille maximale du fichier de données Limitée à la taille de stockage d’instance actuellement disponible (maximum 2-8 To) et à l’espace d’allocation de stockage sur disque Premium Azure. Utilisez au moins deux fichiers de données pour les bases de données de plus de 8 To. Limitée à la taille de stockage d’instances actuellement disponible (jusqu’à 1-4 To).
Taille maximale du fichier journal Limitée à 2 To et à la taille de stockage d’instance actuellement disponible. Limitée à 2 To et à la taille de stockage d’instance actuellement disponible.
IOPS de données/journal (approximatives) Jusqu’à 30-40 K IOPS par instance*, 500-7500 par fichier
*Augmentez la taille de fichier pour obtenir davantage d’IOPS		 16 000 à 320 000 (4 000 IOPS/vCore)
Ajoutez plus de vCores pour obtenir de meilleures performances d’E/S.
Limite du débit d’écriture du journal (par instance) 3 Mio/s par vCore
120 Mio/s max. par instance
22 à 65 Mio/s par base de données
**		 4 Mio/s par vCore
96 Mo/s max.
Débit de données (approximatif) 100 à 250 Mio/s par fichier
**		 Non limité.
Latence d’E/S de stockage (approximative) 5 - 10 ms 1 - 2 ms
OLTP en mémoire Non pris en charge Disponible, la taille dépend du nombre de vCores
Nombre maximal de sessions 30000 30000
Nombre maximal de workers simultanés 210 * nombre de vCores + 800 210 * nombre de vCores + 800
Réplicas en lecture seule 0 1 (inclus dans le prix)
Isolation du calcul non pris en charge non pris en charge

Étapes suivantes