Vue d’ensemble des limites de ressources Azure SQL Managed Instance
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 générations de matériel.
Les générations du matériel ont différentes caractéristiques, qui sont décrites dans le tableau suivant :
| Caractéristique | 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) |
21 -80 vCores | 21 -128 vCores | 4-128 vCores |
| Mémoire maximale (rapport mémoire/vCore) | 5,1 Go par vCore - 408 Go maximum Ajoutez plus de vCores pour obtenir davantage de mémoire. |
7 Go par vCore jusqu’à 80 vCores - 560 Go maximum | 13,6 Go par vCore jusqu’à 64 vCores - 870,4 Go maximum |
| 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 maximal réservé pour l'instance2 |
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’à 16 To3 |
Usage général : jusqu’à 16 To Critique pour l’entreprise : jusqu’à 16 To |
1 Le déploiement d'une instance 2-vCore n'est possible qu'à l'intérieur d'un pool d'instances.
2Dépend du nombre de vCores.
3 Seules les principales régions peuvent fournir 16 To d’espace de stockage. Les régions plus petites limitent le stockage disponible à 5,5 To.
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.
Supports régionaux pour le matériel de la série Premium à mémoire optimisée et pour le matériel de la série Premium avec 16 To de stockage
La prise en charge du matériel de la série Premium avec un espace de stockage de 16 To a la même disponibilité que la prise en charge du 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 et du matériel de la série premium avec 16 To de stockage n’est actuellement disponible que dans ces régions spécifiques :
| Geography | Régions prenant en charge du matériel de la série Premium à mémoire optimisée et le matériel Premium avec un espace de stockage de 16 To |
|---|---|
| Europe | France Centre, Allemagne Centre-Ouest, Italie Nord, Europe Nord, Pologne Centre, Suède Centre, Suisse Nord, Royaume-Uni Sud, Europe Ouest |
| Moyen-Orient, Afrique | Qatar Centre |
| Amérique | Brésil Sud, Canada Centre, Canada Est, USA Centre, USA Est 2, USA Centre Nord, USA Centre Sud, USA Ouest, USA Centre-Ouest, USA Ouest 2 |
| Asie-Pacifique | Australie Est, Australie Sud-Est, Chine Nord 3, 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 |
| 6 vCores | - | 6,59 Go | 15,32 Go |
| 8 vCores | 6,28 Go | 8,79 Go | 22,06 Go |
| 10 vCores | - | 12,11 Go | 30,94 Go |
| 12 vCores | - | 15,43 Go | 39,82 Go |
| 16 vCores | 15,77 Go | 22,06 Go | 57,58 Go |
| 20 vCores | - | 28,70 Go | 75,34 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 |
| 48 vCores | - | 95,34 Go | 199,64 Go |
| 56 vCores | - | 117,58 Go | 244,13 Go |
| 64 vCores | 99,9 Go | 139,82 Go | 288,61 Go |
| 80 vCores | 131,68 Go | 184,30 Go | 288,61 Go |
| 96 vCores | N/A | 184,30 Go | 288,61 Go |
| 128 vCores | N/A | 184,30 Go | 288,61 Go |
Caractéristiques du niveau de service
SQL Managed Instance a deux niveaux de service : Usage général et Critique pour l’entreprise. Vous pouvez choisir d’utiliser le niveau de service Usage général nouvelle génération mis à niveau (aperçu) mis à niveau.
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 en lecture-écriture et les requêtes en lecture seule/analytique/rapport, vous obtenez deux fois les vCores et la mémoire pour le même prix. Le réplica secondaire peut différer de quelques secondes derrière l’instance principale. Il est donc conçu pour décharger les charges de travail de création de rapports/analytiques qui n’ont pas besoin d’un é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.
Nombre de vCores
| Génération de matériel | Usage général | Usage général nouvelle génération | Critique pour l’entreprise |
|---|---|---|---|
| Série Standard (Gen5) | 21 , 4, 8, 16, 24, 32, 40, 64, 80 | 4, 8, 16, 24, 32, 40, 64, 80 | 4, 8, 16, 24, 32, 40, 64, 80 |
| Série Premium | 21 , 4, 8, 16, 24, 32, 40, 64, 80 | 4, 6, 8, 10, 12, 16, 20, 24, 32, 40, 48, 56, 64, 80, 96, 128 | 4, 6, 8, 10, 12, 16, 20, 24, 32, 40, 48, 56, 64, 80, 96, 128 |
| Série Premium à mémoire optimisée | 4, 8, 16, 24, 32, 40, 64, 80 | 4, 6, 8, 10, 12, 16, 20, 24, 32, 40, 48, 56, 64, 80, 96, 128 | 4, 6, 8, 10, 12, 16, 20, 24, 32, 40, 48, 56, 64, 80, 96, 128 |
1 Le déploiement d'une instance 2-vCore n'est possible qu'à l'intérieur d'un pool d'instances.
Mémoire maximale
| Génération de matériel | Usage général | Usage général nouvelle génération | Critique pour l’entreprise |
|---|---|---|---|
| Série Standard (Gen5) | 20,4 Go - 408 Go 5,1 Go/vCore |
20,4 Go - 408 Go 5,1 Go/vCore |
20,4 Go - 408 Go 5,1 Go/vCore sur chaque réplica |
| Série Premium | 28 Go - 560 Go 7 Go/vCore |
28 Go - 560 Go 7 Go/vCore |
28 Go - 560 Go 7 Go/vCore jusqu’à 80 vCores1 sur chaque réplica |
| Série Premium à mémoire optimisée | 54,4 Go - 870,4 Go 13,6 Go/vCore |
54,4 Go - 870,4 Go 13,6 Go/vCore |
54,4 Go - 870,4 Go 13,6 Go/vCore jusqu’à 64 vCores1 sur chaque réplica |
1 Le ratio mémoire-à-vCore n’est disponible que jusqu’à 80 vCores pour le matériel de série Premium et 64 vCores pour la série Premium optimisée en mémoire. La mémoire maximale est limitée à 560 Go pour les vCores de la série Premium supérieures à 80 et 870,4 Go pour les vCores de la série Premium optimisées en mémoire supérieure à 64.
Taille de stockage maximale d’instance (réservée)
| Génération de matériel | Usage général | Usage général nouvelle génération | Critique pour l’entreprise |
|---|---|---|---|
| Série Standard (Gen5) | - 2 To pour 4 vCores - 8 To pour 8 vCores - 16 To pour les autres tailles |
- 2 To pour 4 vCores - 8 To pour 8 vCores - 16 To pour les autres tailles |
- 1 To pour 4, 8, 16 vCores - 2 To pour 24 vCores - 4 To pour 32, 40, 64, 80 vCores |
| Série Premium | - 2 To pour 4 vCores - 8 To pour 8 vCores - 16 To pour les autres tailles |
- 2 To pour 4, 6 vCores - 8 To pour 8, 10, 12 vCores - 16 To pour 16, 20, 24 vCores - 32 To pour 32, 40, 48, 56, 64, 80, 96, 128 vCores |
- 1 To pour 4, 6 vCores - 2 To pour 8, 10, 12 vCores - 4 To pour 16, 20 vCores - 5,5 To pour 24, 32, 40, 48, 56 vCores – 5,5 To ou 16 To (selon la région) pour 64, 80, 96, 128 vCores1 |
| Série Premium à mémoire optimisée | - 2 To pour 4 vCores - 8 To pour 8 vCores - 16 To pour les autres tailles |
- 2 To pour 4, 6 vCores - 8 To pour 8, 10, 12 vCores - 16 To pour 16, 20, 24 vCores - 32 To pour 32, 40, 48, 56, 64, 80, 96, 128 vCores |
- 1 To pour 4, 6 vCores - 2 To pour 8, 10, 12 vCores - 4 To pour 16, 20 vCores - 5,5 To pour 24 vCores - 5,5 To ou 8 To (selon la région) pour 32, 40 vCores2 - 12 To pourr 48, 56 vCores - 16 To pour 64, 80, 96, 128 vCores |
1 Seules les principales régions peuvent fournir 16 To de stockage pour le matériel de la série Premium pour ces nombres d’UC vCore. Les régions plus petites limitent le stockage disponible à 5,5 To.
2 Seules les principales régions peuvent fournir 8 To de stockage pour le matériel à mémoire optimisée de la série Premium pour ces nombres d’UC vCore. Les régions plus petites limitent le stockage disponible à 5,5 To.
Comparaison des fonctionnalités
| Caractéristique | Usage général | Usage général nouvelle génération | Critique pour l’entreprise |
|---|---|---|---|
| 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). | 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. |
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 | 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. | 500 bases de données utilisateur | 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 | 280 par instance, à moins que la taille de stockage de l’instance ou la limite d’espace d’allocation de mémoire du disque Azure Premium n’aient été atteintes. | 4 096 fichiers par base de données | 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). | 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. | Limitée à 2 To et à la taille de stockage d’instance actuellement disponible. |
| IOPS de données/journal (approximatives) | 500 - 7500 par fichier * Augmentez la taille de fichier pour obtenir davantage d’IOPS |
Stockage réservé * 3 – jusqu’à la limite de la machine virtuelle. 300 pour 32 Go, 64 Go et 96 Go de stockage réservé. La limite de VM dépend du nombre de vCores 6 400 IOPS pour une machine virtuelle avec 4 vCores – 80 000 IOPS pour une machine virtuelle avec 128 vCores |
16 000 à 320 000 (4 000 IOPS/vCore) Ajoutez plus de vCores pour obtenir de meilleures performances d’E/S. |
| Débit de données (approximatif) | 100 à 250 Mio/s par fichier * Augmenter la taille de fichier pour obtenir de meilleures performances d’E/S |
IOPS / 30 Mbps – jusqu’à la limite de la machine virtuelle. 75 Mbps pour 32 Go, 64 Go et 96 Go de stockage réservé. | Non limité. |
| 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) * Augmenter la taille de fichier pour obtenir de meilleures performances d’E/S |
4.5 Mio/s par vCore 192 Mio/s max. |
4.5 Mio/s par vCore 192 Mio/s max. |
| Latence des E/S de stockage (approximativement1) | 5 - 10 ms | 3-5 ms | 1 - 2 ms |
| OLTP en mémoire | Non pris en charge | Non pris en charge | Disponible, la taille dépend du nombre de vCores |
| Nombre maximal de sessions | 30000 | 30000 | 30000 |
| Nombre maximal de workers simultanés | 105 * nombre de vCores + 800 | 105 * nombre de vCores + 800 | 105 * nombre de vCores + 800 |
| Utiliser des réplicas en lecture seule pour décharger les charges de travail de requête en lecture seule | 0 | 0 | 1 (inclus dans le prix) |
| Isolation du calcul | Non pris en charge, car les instances à usage général peuvent partager du matériel physique avec d’autres instances | Non pris en charge en tant qu’instances à usage général de nouvelle génération peuvent partager du matériel physique avec d’autres instances |
série Standard (Gen5) : Prise en charge pour les configurations avec 64 vCores ou plus de la série Premium : pris en charge pour les configurations avec 64 vCores ou plus Série premium à mémoire optimisée : Prise en charge des configurations avec 64 vCores ou plus |
| Réplicas pour la disponibilité | Nœuds de secours pour la haute disponibilité | Nœuds de secours pour la haute disponibilité | Trois réplicas haute disponibilité, 1 est également un réplica de mise à l’échelle en lecture |
| Réplicas en lecture seule avec des groupes de basculement activés | Un réplica en lecture seule supplémentaire. Deux réplicas accessibles en lecture totale, qui incluent le réplica principal. | Un réplica en lecture seule supplémentaire. Deux réplicas accessibles en lecture totale, qui incluent le réplica principal. | Deux réplicas en lecture seule supplémentaires, trois réplicas en lecture seule totale. Quatre réplicas accessibles en lecture totale, qui incluent le réplica principal. |
| Tarification/facturation |
vCore, stockage réservé et stockage de sauvegarde sont facturés. Les IOPS ne sont pas facturées |
vCore, stockage réservé, stockage de sauvegarde et IOPS (au-delà du quota gratuit) sont facturés. |
vCore, stockage réservé et stockage de sauvegarde sont facturés. Les IOPS ne sont pas facturées. |
| Modèles de remise |
réservations Azure Azure Hybrid Benefit - Azure SQL Database & SQL Managed Instance (non disponible sur les abonnements de développement/test) Abonnements Entreprise et Dev/Test - Paiement à l’utilisation |
réservations Azure Azure Hybrid Benefit - Azure SQL Database & SQL Managed Instance (non disponible sur les abonnements de développement/test) Abonnements Entreprise et Dev/Test - Paiement à l’utilisation |
réservations Azure Azure Hybrid Benefit - Azure SQL Database & SQL Managed Instance (non disponible sur les abonnements de développement/test) Abonnements Entreprise et Dev/Test - Paiement à l’utilisation |
1 Il s’agit d’une plage moyenne. Bien que la grande majorité des durées de requête d’E/S tombent en haut de la plage, les valeurs hors norme qui dépassent la plage sont possibles.
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 fichier qui n’est pas explicitement limitée par l’instance managée SQL.
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. Certains E/S par seconde sont également utilisés pour les restaurations automatiques.
Vous pouvez créer un autre réplica lisible dans une région Azure différente à l’aide de groupes de basculement
Les noms de fichiers
tempdbne 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.
D’OPÉRATIONS D’E/S PAR SECONDE
Pour les niveaux de service Usage général nouvelle génération et Critique pour l’entreprise, le taux d’IOPS disponible est déterminé par le nombre de vCores :
- Niveau de service Usage général nouvelle génération : valeur fixe d’IOPS en fonction du nombre de vCores. Le prix du stockage inclut les IOPS minimales. Si vous dépassez le minimum, vous êtes facturé comme suit : 1 IOPS = prix de stockage (par région) divisé par trois. Par exemple, si 1 Go de stockage coûte 0,115, alors 1 IOPS = 0,115/3 = 0,038 par IOPS.
- Niveau de service Critique pour l’entreprise : utilise une formule (4 000 IOPS/vCore) pour déterminer les limites d’IOPS.
Le tableau suivant répertorie les IOPS maximales disponibles pour chaque niveau de service en fonction du nombre de vCores :
| Nombre de vCores | Usage général nouvelle génération | Critique pour l’entreprise |
|---|---|---|
| 4 | 6 400 | 16 000 |
| 6 | 9 600 | 24,000 |
| 8 | 12 800 | 32 000 |
| 10 | 16 000 | 40 000 |
| 12 | 19 200 | 48 000 |
| 16 | 25 600 | 64 000 |
| 20 | 32 000 | 80 000 |
| 24 | 38 400 | 96 000 |
| 32 | 51 200 | 128 000 |
| 40 | 64 000 | 160 000 |
| 48 | 76 800 | 192 000 |
| 56 | 80 000 | 224 000 |
| 64 | 80 000 | 256 000 |
| 80 | 80 000 | 320 000 |
| 96 | 80 000 | 320 000 |
| 128 | 80 000 | 320 000 |
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 | 7500 |
| 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), il se peut donc que vous ne puissiez pas atteindre le débit maximal du fichier journal parce que vous atteignez la limite de débit de l’instance.
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,
tempdbutilise 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,
tempdbpartage le disque SSD local avec les données et les fichiers journaux, et le coût du stockagetempdbest 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
Dans les deux niveaux de service, vous êtes facturé pour 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 de l’espace inutilisé. Pour plus d’informations, consultez DBCC SHRINKFILE.
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 1 à 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 choisie détermine la quantité de stockage utilisée pour les sauvegardes de conservation à long terme. Pour plus d’informations, consultez rétention à long terme - Azure SQL Database et Azure SQL Managed 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 :
- Contrat Entreprise (EA)
- Paiement à l’utilisation
- Fournisseur de services cloud (CSP)
- Enterprise Dev/Test
- Dev/Test - Paiement à l’utilisation
- Abonnements avec crédit Azure mensuel pour les abonnés Visual Studio
- Version d'évaluation gratuite
- Azure for Students
- Azure dans Open
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é tant qu’elle se trouve dans la limite d’unité vCore.
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 1 |
|---|---|---|
| CSP | 16 (30 dans certaines régions2) | 960 (1440 dans certaines régions2) |
| EA | 16 (30 dans certaines régions2) | 960 (1440 dans certaines régions2) |
| 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 |
1 Lors de la planification des déploiements, prenez en compte que le niveau de service Critique pour l’entreprise (BC) nécessite quatre (4) fois plus de capacité 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.
2 Limites de sous-réseau et vCore plus volumineux sont disponibles 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 votre 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 Augmentations de quota de demandes pour Azure SQL Database et SQL Managed Instance.