Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
gäller för:
Azure SQL Managed Instance
Denna artikel ger en översikt över de tekniska egenskaperna och resursbegränsningarna för Azure SQL Managed Instance. Den ger också information om hur man begär en höjning av dessa gränser.
Not
För skillnader i stödda funktioner och T-SQL-satser, se Funktionsskillnader och stöd för T-SQL-satser. För allmänna skillnader mellan servicenivåer för Azure SQL Database och SQL Managed Instance, granska General Purpose och Business Critical service tiers.
Egenskaper för maskinvarukonfiguration
I detta avsnitt:
- Regionalt stöd för minnesoptimerad premiumseriehårdvara och för premiumseriehårdvara med 16 TB lagring
- Minnesinternt OLTP tillgängligt utrymme
SQL Managed Instance har egenskaper och resursgränser som är beroende av den underliggande infrastrukturen och arkitekturen. Du kan distribuera SQL Managed Instance på flera hårdvarugenerationer.
Maskinvarugenerationer har olika egenskaper, enligt beskrivningen i följande tabell:
| Drag | Standardserie (Gen5) | Premium-serien | Minnesoptimerad premiumserie |
|---|---|---|---|
| CPU- | Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake) och Intel® 8272CL (Cascade Lake) 2,5 GHz-processorer | Intel® 8370C (Ice Lake) 2,8 GHz-processorer | Intel® 8370C (Ice Lake) 2,8 GHz-processorer |
|
Antal virtuella kärnor vCore=1 LP (hypertråd) |
21 -80 virtuella kärnor | 21 -128 virtuella kärnor | 4–128 virtuella kärnor |
| Maximalt minne (förhållande mellan minne och virtuell kärna) | 5,1 GB per virtuell kärna – maximalt 408 GB Lägg till fler virtuella kärnor för att få mer minne. |
7 GB per virtuell kärna upp till 80 virtuella kärnor – maximalt 560 GB | 13,6 GB per virtuell kärna upp till 64 virtuella kärnor – maximalt 870,4 GB |
| Max In-Memory OLTP-minne | Instansgräns: 0,8–1,65 GB per virtuell kärna | Instansgräns: 1,1–2,3 GB per virtuell kärna | Instansgräns: 2,2–4,5 GB per virtuell kärna |
| Maximalt reserverat lagringsutrymme för instanser2 |
Generell användning: upp till 32 TB4 Affärskritisk: upp till 4 TB |
Generell användning: upp till 32 TB4 Affärskritisk: upp till 16 TB3 |
Generell användning: upp till 32 TB4 Affärskritisk: upp till 16 TB |
1 Du kan bara distribuera en 2-vCore-instans inom en instanspool.
2 beroende av antalet virtuella kärnor.
3Följande regioner kan ge 16 TB lagringsutrymme, medan andra regioner begränsar tillgängligt lagringsutrymme till 5,5 TB.
4 16 TB för klassisk generell användning. 32 TB endast för Next-gen General Purpose service-tier
Not
Om din arbetsbelastning kräver lagringsstorlekar som är större än de tillgängliga resursgränserna för Azure SQL Managed Instance bör du överväga tjänstnivån Azure SQL Database Hyperskala.
Regionalt stöd för minnesoptimerad premiumseriehårdvara och för premiumseriehårdvara med 16 TB lagring
Stöd för premium-seriens maskinvara med 16 TB lagring har samma tillgänglighet som stöd för den minnesoptimerade premium-seriens maskinvara. För att lära dig mer, se Regionala stöd för minnesoptimerad premiumseriehårdvara och för premiumseriehårdvara med 16 TB lagring.
Minnesinternt OLTP tillgängligt utrymme
Mängden In-memory OLTP-utrymme i Business Critical-servicenivån beror på antalet vCores och hårdvarukonfigurationen. Följande tabell listar minnesbegränsningarna som du kan använda för In-memory OLTP-objekt.
| virtuella kärnor | Standardserie (Gen5) | Premium-serien | Minnesoptimerad premiumserie |
|---|---|---|---|
| 4 virtuella kärnor | 3,14 GB | 4,39 GB | 8,79 GB |
| 6 virtuella kärnor | - | 6,59 GB | 15,32 GB |
| 8 virtuella kärnor | 6,28 GB | 8,79 GB | 22,06 GB |
| 10 virtuella kärnor | - | 12,11 GB | 30,94 GB |
| 12 virtuella kärnor | - | 15,43 GB | 39,82 GB |
| 16 virtuella kärnor | 15,77 GB | 22,06 GB | 57,58 GB |
| 20 virtuella kärnor | - | 28,70 GB | 75,34 GB |
| 24 virtuella kärnor | 25,25 GB | 35,34 GB | 93,09 GB |
| 32 virtuella kärnor | 37,94 GB | 53,09 GB | 128,61 GB |
| 40 virtuella kärnor | 52,23 GB | 73,09 GB | 164,13 GB |
| 48 virtuella kärnor | - | 95,34 GB | 199,64 GB |
| 56 virtuella kärnor | - | 117,58 GB | 244,13 GB |
| 64 virtuella kärnor | 99,9 GB | 139,82 GB | 288,61 GB |
| 80 virtuella kärnor | 131,68 GB | 184,30 GB | 288,61 GB |
| 96 virtuella kärnor | Ej tillämpligt | 184,30 GB | 288,61 GB |
| 128 virtuella kärnor | Ej tillämpligt | 184,30 GB | 288,61 GB |
Egenskaper för tjänstnivå
SQL Managed Instance har två tjänstnivåer: Generell användning och Affärskritisk. Du kan välja att använda den uppgraderade tjänstnivån Nästa generations generell användning.
Viktig
Business Critical-tjänstenivån tillhandahåller en extra inbyggd kopia av SQL Managed Instance (sekundär replika) som används för skrivskyddade arbetsbelastningar. Om du separerar läs-skriv-frågor från skrivskyddade, analytiska eller rapporteringsfrågor får du dubbelt så många vCores och minne till samma pris. Den sekundära repliken kan halka några sekunder efter primärinstansen, så den är designad för att avlasta rapportering och analytiska arbetsbelastningar som inte behöver exakt aktuellt datatillstånd. I följande tabell är skrivskyddade frågor de frågor som körs på den sekundära repliken.
I detta avsnitt:
- Antal virtuella kärnor
- Maximalt minne
- Maximal lagringsstorlek för instanser
- Jämförelse av egenskaper på tjänstnivå
- IOPS och dataflöde
- Data- och logglagring
- Säkerhetskopior och lagring
- Ytterligare överväganden för egenskaper
Antal virtuella kärnor
| Maskinvarugenerering | Generell användning | Nästa generations allmänna syfte | Affärskritisk |
|---|---|---|---|
| Standard-serien (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 |
| Premium-serien | 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 |
| Minnesoptimerad premiumserie | 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 Att distribuera en 2-vCore-instans är bara möjligt i en instanspool.
Maximalt minne
| Maskinvarugenerering | Generell användning | Nästa generations allmänna syfte | Affärskritisk |
|---|---|---|---|
| Standard-serien (Gen5) | 20,4 GB – 408 GB 5,1 GB/virtuell kärna |
20,4 GB – 408 GB 5,1 GB/virtuell kärna |
20,4 GB – 408 GB 5,1 GB/virtuell kärna på varje replik |
| Premium-serien | 28 GB – 560 GB 7 GB/virtuell kärna |
28 GB – 560 GB 7 GB/virtuell kärna |
28 GB – 560 GB 7 GB/virtuell kärna upp till 80 virtuella kärnor1 på varje replik |
| Minnesoptimerad premiumserie | 54,4 GB – 870,4 GB 13,6 GB/virtuell kärna |
54,4 GB – 870,4 GB 13,6 GB/virtuell kärna |
54,4 GB – 870,4 GB 13,6 GB/virtuell kärna upp till 64 virtuella kärnor1 på varje replik |
1 Förhållandet mellan minne och virtuell kärna är endast tillgängligt upp till 80 virtuella kärnor för maskinvara i Premium-serien och 64 virtuella kärnor för minnesoptimerad premiumserie. Maximalt minne är begränsat till 560 GB för premiumserie-virtuella kärnor över 80 och 870,4 GB för minnesoptimerade virtuella kärnor i Premium-serien över 64.
Maximal lagringsstorlek för instanser (reserverad)
I följande tabell visas den maximala lagringsstorleken baserat på antalet virtuella kärnor för varje maskinvarugenerering och tjänstnivå:
| Maskinvarugenerering | Generell användning1 | Nästa generations allmänna syfte | Affärskritisk2 |
|---|---|---|---|
| Standard-serien (Gen5) | – 2 TB för 4 virtuella kärnor – 8 TB för 8 virtuella kärnor - 16 TB för andra storlekar |
– 2 TB för 4 virtuella kärnor – 8 TB för 8 virtuella kärnor - 16 TB för 16, 24 virtuella kärnor - 32 TB för 32, 40, 64, 80 virtuella kärnor |
- 1 TB för 4, 8, 16 virtuella kärnor – 2 TB för 24 virtuella kärnor - 4 TB för 32, 40, 64, 80 virtuella kärnor |
| Premium-serien | – 2 TB för 4 virtuella kärnor – 8 TB för 8 virtuella kärnor - 16 TB för andra storlekar |
– 2 TB för 4, 6 virtuella kärnor - 8 TB för 8, 10, 12 virtuella kärnor - 16 TB för 16, 20, 24 virtuella kärnor - 32 TB för 32, 40, 48, 56, 64, 80, 96, 128 virtuella kärnor |
– 1 TB för 4, 6 virtuella kärnor – 2 TB för 8, 10, 12 virtuella kärnor – 4 TB för 16, 20 virtuella kärnor - 5,5 TB för 24, 32, 40, 48, 56 virtuella kärnor – 5,5 TB eller 16 TB (beroende på region) för 64, 80, 96, 128 virtuella kärnor3 |
| Minnesoptimerad premiumserie | – 2 TB för 4 virtuella kärnor – 8 TB för 8 virtuella kärnor - 16 TB för andra storlekar |
– 2 TB för 4, 6 virtuella kärnor - 8 TB för 8, 10, 12 virtuella kärnor - 16 TB för 16, 20, 24 virtuella kärnor - 32 TB för 32, 40, 48, 56, 64, 80, 96, 128 virtuella kärnor |
– 1 TB för 4, 6 virtuella kärnor – 2 TB för 8, 10, 12 virtuella kärnor – 4 TB för 16, 20 virtuella kärnor – 5,5 TB för 24 virtuella kärnor – 5,5 TB eller 8 TB (beroende på region) för 32, 40 virtuella kärnor4 – 12 TB för 48, 56 virtuella kärnor - 16 TB för 64, 80, 96, 128 virtuella kärnor |
1 På tjänstnivån tempdb Generell användning använder du lokal SSD-lagring.
2 På tjänstnivån tempdb Affärskritisk delar du lokal SSD-lagring med data och loggfiler. Storleken på tempdb kan växa upp till den tillgängliga instanslagringsstorleken.
3 Endast de större regionerna kan tillhandahålla 16 TB lagringsutrymme för premiumseriens maskinvara för dessa cpu-nummer för virtuella kärnor. Mindre regioner begränsar tillgängligt lagringsutrymme till 5,5 TB.
4 Endast de större regionerna kan tillhandahålla 8 TB lagringsutrymme för den minnesoptimerade maskinvaran i Premium-serien för dessa cpu-virtuella kärnor. Mindre regioner begränsar tillgängligt lagringsutrymme till 5,5 TB.
Jämförelse av egenskaper på tjänstnivå
| Drag | Generell användning | Nästa generations allmänna syfte | Affärskritisk |
|---|---|---|---|
| Maximal databasstorlek | Upp till tillgänglig instansstorlek (beroende på antalet virtuella kärnor). | Upp till tillgänglig instansstorlek (beroende på antalet virtuella kärnor). | Upp till tillgänglig instansstorlek (beroende på antalet virtuella kärnor). |
Maximal tempdb databasstorlek |
Begränsad till 24 GB/virtuell kärna (96–1 920 GB) och för närvarande tillgänglig lagringsstorlek för instanser. Lägg till fler virtuella kärnor för att få mer tempdb utrymme.Loggfilens storlek är begränsad till 120 GB. |
Begränsad till 24 GB/virtuell kärna (96–1 920 GB) och för närvarande tillgänglig lagringsstorlek för instanser. Lägg till fler virtuella kärnor för att få mer tempdb utrymme.Loggfilens storlek är begränsad till 120 GB. |
Upp till tillgänglig lagringsstorlek för instanser. |
Maximalt antal tempdb filer |
128 | 128 | 128 |
| Maximalt antal databaser per instans | 100 användardatabaser, såvida inte instansens lagringsstorleksgräns har nåtts. | 500 användardatabaser | 100 användardatabaser, såvida inte instansens lagringsstorleksgräns har nåtts. |
| Maximalt antal databasfiler | 280 per instans, såvida inte instanslagringsstorleken eller Azure Premium Disk-lagringsallokeringsutrymme gränsen har nåtts. | 4 096 filer per databas | 32 767 filer per databas, såvida inte instansens lagringsstorleksgräns har nåtts. |
| Maximal datafilstorlek | Maximal storlek för varje datafil är 8 TB. Använd minst två datafiler för databaser som är större än 8 TB. | Upp till tillgänglig instansstorlek (beroende på antalet virtuella kärnor). | Upp till tillgänglig instansstorlek (beroende på antalet virtuella kärnor). |
| Maximal loggfilstorlek | Begränsad till 2 TB och för närvarande tillgänglig lagringsstorlek för instanser. | Begränsad till 2 TB och för närvarande tillgänglig lagringsstorlek för instanser. | Begränsad till 2 TB och för närvarande tillgänglig lagringsstorlek för instanser. |
| Data/logg-IOPS (ungefärlig) | 500–7 500 per fil * Öka filstorleken för att få fler IOPS- |
Reserverad lagring * 3 – upp till vm-gränsen. 300 vid 32 GB, 64 GB och 96 GB reserverat lagringsutrymme. VM-gränsen beror på antalet virtuella kärnor 6400 IOPS för en virtuell dator med 4 virtuella kärnor – 80 K IOPS för en virtuell dator med 128 virtuella kärnor |
16 K – 320 K (4 000 IOPS/virtuell kärna) Lägg till fler virtuella kärnor för att få bättre I/O-prestanda. |
| Dataflöde (ungefärligt) | 100–250 MiB/s per fil * Öka filstorleken för att få bättre I/O-prestanda |
IOPS/30 Mbit/s – upp till vm-gränsen. 75 Mbit/s om det finns 32 GB, 64 GB och 96 GB reserverat lagringsutrymme. | Inte begränsat. |
| Loggskrivningsgränsen för dataflöde (per instans) | 4,5 MiB/s per virtuell kärna Max 120 MiB/s per instans 22–65 MiB/s per databas (beroende på loggfilens storlek) * Öka filstorleken för att få bättre I/O-prestanda |
Standardserie: 4,5 MiB/s per virtuell kärna Max 120 MiB/s Premium-serien och minnesoptimerade premiumserier: 4,5 MiB/s per virtuell kärna Max 192 MiB/s |
Standardserie: 16 MiB/s per vCore Max 160 MiB/s Premium-serien och minnesoptimerade premiumserier: 16 MiB/s per vCore Max 192 MiB/s |
| Lagrings-I/O-svarstid (ungefärlig1) | 5–10 ms | 3–5 ms | 1–2 ms |
| Minnesintern OLTP | Stöds inte | Stöds inte | Tillgänglig, storlek beror på antalet virtuella kärnor |
| Maximalt antal sessioner | 30000 | 30000 | 30000 |
| Maximalt antal samtidiga arbetare | 105 * antal virtuella kärnor + 800 | 105 * antal virtuella kärnor + 800 | 105 * antal virtuella kärnor + 800 |
| Använd skrivskyddade repliker för att avlasta skrivskyddade frågearbetsbelastningar | 0 | 0 | 1 (ingår i priset) |
| Beräkningsisolering | Stöds inte eftersom instanser av generell användning kan dela fysisk maskinvara med andra instanser | Stöds inte eftersom instanser av nästa generations generell användning kan dela fysisk maskinvara med andra instanser |
Standard-serien (Gen5): Stöds för konfigurationer med 64 eller fler virtuella kärnor Premium-seriens: Stöds för konfigurationer med 64 eller fler virtuella kärnor Minnesoptimerad premiumserie: Stöds för konfigurationer med 64 eller fler virtuella kärnor |
| Repliker för tillgänglighet | Stå vid noder för hög tillgänglighet | Stå vid noder för hög tillgänglighet | Fyra repliker med hög tillgänglighet, 1 är också en skrivskalningsreplik |
| Skrivskyddade repliker med redundansgrupper aktiverade | Ytterligare en skrivskyddad replik. Två totalt läsbara repliker, som innehåller den primära repliken. | Ytterligare en skrivskyddad replik. Två totalt läsbara repliker, som innehåller den primära repliken. | Två ytterligare skrivskyddade repliker, tre totalt skrivskyddade repliker. Fyra totalt läsbara repliker, inklusive den primära repliken. |
| Priser/fakturering |
virtuella kärnor, reserverad lagring och lagring av säkerhetskopior debiteras. IOPS debiteras inte |
Virtuella kärnor, reserverad lagring, lagring av säkerhetskopior och IOPS (över den kostnadsfria kvoten) debiteras. |
virtuella kärnor, reserverad lagring och lagring av säkerhetskopior debiteras. IOPS debiteras inte. |
| Rabattmodeller |
Azure-reservationer Azure Hybrid-förmån – Azure SQL Database & SQL Managed Instance (inte tillgängligt för dev/test-prenumerationer) Enterprise-- och betala per användning Dev/Test-prenumerationer |
Azure-reservationer Azure Hybrid-förmån – Azure SQL Database & SQL Managed Instance (inte tillgängligt för dev/test-prenumerationer) Enterprise-- och betala per användning Dev/Test-prenumerationer |
Azure-reservationer Azure Hybrid-förmån – Azure SQL Database & SQL Managed Instance (inte tillgängligt för dev/test-prenumerationer) Enterprise-- och betala per användning Dev/Test-prenumerationer |
1 Det här är ett genomsnittligt intervall. Även om de allra flesta I/O-begärandevaraktigheterna hamnar överst i intervallet är avvikande värden som överskrider intervallet möjliga.
IOPS och dataflöde
IOPS och dataflöde är egenskaper för I/O-filsystemet.
IOPS och dataflöde skiljer sig åt beroende på tjänstnivå på följande sätt:
- På tjänstnivån Affärskritisk är dataflödet obegränsat.
- På tjänstnivån Generell användning beror dataflödet på filstorleken.
- På tjänstnivån Nästa generations generell användning skalar dataflödet proportionellt med antalet IOPS som allokerats till instansen.
I följande avsnitt beskrivs I/O-egenskaper efter tjänstnivå i detalj.
IOPS och dataflöde på tjänstnivån Generell användning
På tjänstnivån Generell användning får varje databasfil dedikerad IOPS och dataflöde som är beroende av filstorleken. Större filer får mer IOPS och dataflöde.
I följande tabell visas I/O-egenskaper för databasfiler på tjänstnivån Generell användning :
| Filstorlek | >=0 och <=129 GiB | >129 och <=513 GiB | >513 och <=1025 GiB | >1025 och <=2049 GiB | >2049 och <=4097 GiB | >4097 GiB och <=8 TiB |
|---|---|---|---|---|---|---|
| IOPS per fil | 500 | 2300 | 5 000 | 7 500 | 7 500 | 7 500 |
| dataflöde per fil | 100 MiB/s | 150 MiB/s | 200 MiB/s | 250 MiB/s | 250 MiB/s | 250 MiB/s |
Om du märker hög I/O-svarstid för en databasfil eller om du ser att IOPS/dataflödet når gränsen kan du förbättra prestandan genom att öka filstorleken.
Det finns också en gräns på instansnivå för det maximala loggskrivningsdataflödet (se föregående tabell för värden, till exempel 22 MiB/s), så du kanske inte kan nå maxfilen i loggfilen eftersom du når instansens dataflödesgräns.
IOPS och dataflöde på tjänstnivån Nästa generations generell användning
Tjänstnivån Nästa generations generell användning har följande IOPS-egenskaper:
- Minsta garanterade IOPS: Varje instans garanteras minst 300 IOPS, oavsett reserverad lagring.
- IOPS skalas med reserverad lagring: För varje 1 GB reserverad lagring får du 3 inbyggda IOPS. Om du till exempel har 1 024 GB reserverad lagring tilldelas du 3 072 IOPS.
- Extra IOPS: Du kan öka mängden IOPS över det inbyggda värdet upp till taket.
- Maximalt IOPS-tak per antal virtuella kärnor: Varje vCore-konfiguration har en maximal IOPS-gräns, vilket visas i tabellen maximalt antal IOPS per virtuell kärna.
Tjänstnivån Nästa generations generell användning har följande dataflödesegenskaper:
- Minsta garanterade dataflöde: Varje instans garanteras minst 75 MB/s dataflöde, oavsett antalet virtuella kärnor.
-
Dataflöde skalar med IOPS: Dataflödet skalas proportionellt med antalet IOPS som allokerats till instansen med hjälp av formeln
throughput (MB/s) = IOPS / 30. Till exempel får en instans som allokerats med 3 000 IOPS 100 MB/s dataflöde. - Maximalt dataflödestak per antal virtuella kärnor: Varje vCore-konfiguration har en maximal dataflödesgräns, vilket det maximala dataflödet per virtuell kärna visar. När den nödvändiga IOPS har etablerats för att nå det här taket ökar allokeringen av ytterligare IOPS IOPS-kapacitet men ökar inte dataflödet ytterligare. Till exempel når en instans med 4 virtuella kärnor (max 6 400 IOPS) dataflödesgränsen på 145 MB/s vid 4 350 IOPS. Skalning av IOPS från 4 350 till 6 400 ger mer IOPS till instansen, men dataflödet är fortfarande begränsat till 145 MB/s. Om du vill öka det maximala dataflödet lägger du till fler virtuella kärnor.
I följande tabell visas maximalt IOPS och dataflöde per antal virtuella kärnor som allokerats till en instans på tjänstnivån Nästa generations generell användning:
| Antal virtuella kärnor | Maximalt antal IOPS | Maximalt dataflöde (MB/s) |
|---|---|---|
| 4 | 6,400 | 145 |
| 6 | 9 600 | 217 |
| 8 | 12,800 | 290 |
| 10 | 16 000 | 367 |
| 12 | 19 200 | 445 |
| 16 | 25,600 | 600 |
| 20 | 32,000 | 665 |
| 24 | 38 400 | 730 |
| 32 | 51 200 | 865 |
| 40 | 64,000 | 1,152 |
| 48 | 76,800 | 1,152 |
| 56 - 128 | 80 000 | 1,200 |
IOPS-priser i nästa generations allmänna syfte
Tänk på följande när du använder ytterligare IOPS:
- Ytterligare IOPS debiteras per IOPS/månad
- Fakturerbar IOPS beräknas med följande formel:
Billable IOPS = Total IOPS - default IOPS.
Om du till exempel har en instans med betala per användning 4 virtuella kärnor med 6 400 IOPS debiteras du för:
- 4 virtuella kärnor
- SQL-licens för 4 virtuella kärnor
- 1 024 GB reserverat lagringsutrymme
- 3328 av fakturerbar IOPS
(6400 - (1024*3) = 3328 IOPS).
IOPS och dataflöde på tjänstnivån Affärskritisk
På tjänstnivån Affärskritisk styrs tillgänglig IOPS av antalet virtuella kärnor med hjälp av formeln 4000 IOPS/vCore. Eftersom tjänstnivån Affärskritisk använder lokal lagring för data och loggfiler är dataflödet obegränsat.
I följande tabell visas den högsta IOPS som är tillgänglig på tjänstnivån Affärskritisk baserat på antalet virtuella kärnor:
| Antal virtuella kärnor | Affärskritisk |
|---|---|
| 4 | 16 000 |
| 6 | 24,000 |
| 8 | 32,000 |
| 10 | 40,000 |
| 12 | 48,000 |
| 16 | 64,000 |
| 20 | 80 000 |
| 24 | 96,000 |
| 32 | 128,000 |
| 40 | 160 000 |
| 48 | 192,000 |
| 56 | 224,000 |
| 64 | 256,000 |
| 80 | 320,000 |
| 96 | 320,000 |
| 128 | 320,000 |
Data- och logglagring
Följande faktorer påverkar mängden lagring som används för data och loggfiler. Dessa faktorer gäller både för General Purpose- och Business Critical-nivåerna.
- På tjänstnivån Generell användning använder
tempdblokal SSD-lagring och den här lagringskostnaden ingår i priset för virtuell kärna. - I Business Critical-servicenivån
tempdbdelas lokal SSD-lagring med data och loggfiler, och lagringskostnadentempdbingår i vCore-priset. Du kan storleksanpassatempdbupp till den tillgängliga instanslagringsstorleken. - Du måste ange maximal lagringsstorlek för en SQL Managed Instance i multiplar av 32 GB.
Viktig
I båda servicenivåerna betalar du för maximal lagringsstorlek konfigurerad för en SQL Managed Instance.
Om du vill övervaka den totala förbrukade instanslagringsstorleken för SQL Managed Instance använder du måttet storage_space_used_mb. Om du vill övervaka den aktuella allokerade och använda lagringsstorleken för enskilda data och loggfiler i en databas med hjälp av T-SQL använder du sys.database_files-vyn och funktionen FILEPROPERTY(... , "SpaceUsed").
Dricks
Under vissa omständigheter kan du behöva krympa en databas för att frigöra outnyttjat utrymme. Mer information finns i DBCC SHRINKFILE.
Säkerhetskopior och lagring
Lagring för databassäkerhetskopior allokeras för att stödja återställning till tidpunkt (PITR) och långsiktig kvarhållning (LTR) funktioner i SQL Managed Instance. Den här lagringen är separat från data- och loggfillagring och faktureras separat.
PITR-: I nivåerna Generell användning och Affärskritisk kopieras enskilda databassäkerhetskopior till geo-redundant (RA-GRS) läsåtkomstlagring automatiskt. Lagringsstorleken ökar dynamiskt när nya säkerhetskopior skapas. Lagringen används av fullständiga säkerhetskopior, differentiella säkerhetskopieringar och transaktionsloggar. Lagringsförbrukningen beror på ändringshastigheten för databasen och den kvarhållningsperiod som konfigurerats för säkerhetskopior. Du kan konfigurera en separat kvarhållningsperiod för varje databas mellan 1 och 35 dagar för SQL Managed Instance. En lagringsmängd för säkerhetskopiering som är lika med den konfigurerade maximala datastorleken tillhandahålls utan extra kostnad.
LTR-: Du har också möjlighet att konfigurera långsiktig kvarhållning av fullständiga säkerhetskopior i upp till 10 år. Om du konfigurerar en LTR-princip lagras dessa säkerhetskopior i RA-GRS lagring automatiskt, men du kan styra hur ofta säkerhetskopiorna kopieras. För att uppfylla olika efterlevnadskrav kan du välja olika lagringsperioder för veckovisa, månatliga och årliga backuper. Den konfiguration du väljer avgör hur mycket lagringsutrymme som används för LTR-säkerhetskopieringar. Mer information finns i Långsiktig kvarhållning – Azure SQL Database och Azure SQL Managed Instance.
Ytterligare överväganden för egenskaper
För närvarande tillgänglig lagringsstorlek för instanser är skillnaden mellan reserverad instansstorlek och använt lagringsutrymme.
Både data- och loggfilstorleken i användar- och systemdatabaserna ingår i instanslagringsstorleken som jämförs med den maximala lagringsstorleksgränsen. Använd sys.master_files-systemvyn för att fastställa det totala använda utrymmet för databaser. Felloggar sparas inte och ingår inte i storleken. Säkerhetskopior ingår inte i lagringsstorleken.
Dataflöde och IOPS på nivån Generell användning beror också på filstorlekoch begränsas inte uttryckligen av SQL Managed Instance.
Maximalt antal instans-IOPS beror på fillayouten och distributionen av arbetsbelastningen. Om du till exempel skapar 7 x 1 TB filer med högst 5 K IOPS vardera och sju små filer (mindre än 128 GB) med 500 IOPS vardera, kan du få 38500 IOPS per instans (7x5000+7x500) om din arbetsbelastning kan använda alla filer. Vissa IOPS används också för automatiska återställningar.
Du kan skapa en annan läsbar replik i en annan Azure-region med hjälp av redundansgrupper
Namn på
tempdbfiler får inte innehålla fler än 16 tecken.
Mer information om resursgränser i SQL Managed Instance-pooler finns i den här artikeln.
Flexibelt minne
Som standard är mängden minne som allokeras till Azure SQL Managed Instance ett statiskt värde som bestäms av det valda antalet virtuella kärnor. Med funktionen för flexibelt minne kan du ändra mängden minne som allokeras till din SQL-hanterade instans utan att ändra antalet virtuella kärnor. Den här funktionen är användbar för arbetsbelastningar som kräver mer minne än standardallokeringen för ett visst antal virtuella kärnor.
Den flexibla minnesfunktionen är tillgänglig på följande tjänstnivåer och distributionskonfigurationer på Premium-seriens maskinvara:
- Nästa generations General Purpose: lokalt redundanta och zonredundanta instanser. Flexibelt minne finns generellt tillgängligt (GA) för lokalt redundanta instanser och är för närvarande i förhandsvisning för zonredundanta instanser. Zonredundanta Next-gen General Purpose-instanser kräver Azure Elastic SAN zone-redundant storage (ZRS), vilket inte finns tillgängligt i vissa multizonregioner som stödjer zonredundans för SQL Managed Instance. För tillgänglighet av Elastic SAN ZRS, se Create and deploy an Azure Elastic SAN.
- Affärskritisk: lokalt redundanta och zonredundanta instanser. Flexibelt minne finns generellt tillgängligt (GA) för Business Critical-servicenivån.
Du kan när som helst ändra mängden minne som tilldelas din SQL-hanterade instans för nya och befintliga instanser genom att använda Azure-portalen eller REST API:et. Minnesallokeringsändringen gäller för alla databaser i instansen och utför en failover av instansen som det sista operationssteget. Kontrollera varaktigheten för hanteringsåtgärder för att fastställa den uppskattade tiden för åtgärden att slutföras.
Använd Compute + storage-panelen i Azure-portalen för att ändra minnesallokeringen, eller properties.memorySizeInGB värdet på anropet Managed Instance - Create or Update REST API med start från förhandsversionen 2024-08-01. Ange minnesallokeringen i gigabyte (GB).
När du allokerar minne kan du välja mellan ett lägsta och högsta värde och även bestämma förhållandet mellan minne och virtuella kärnor. Minimi- och maxvärdena beror på antalet vCores du väljer för instansen. Förhållandet mellan minne och virtuell kärna är en procentandel av det totala minne som allokerats till instansen.
I följande tabell visas lägsta och högsta minnesvärden för funktionen för flexibelt minne:
| virtuella kärnor | Min RAM (GB) | Maximalt RAM-minne (GB) | API RAM-värden som stöds | Min-förhållande | Maximalt förhållande | Förhållanden som stöds |
|---|---|---|---|---|---|---|
| 4 | 28 | 48 | 28, 32, 40, 48 | 7 | 12 | 7, 8, 10, 12 |
| 6 | 42 | 72 | 42, 48, 60, 72 | 7 | 12 | 7, 8, 10, 12 |
| 8 | 56 | 96 | 56, 64, 80, 96 | 7 | 12 | 7, 8, 10, 12 |
| 10 | 70 | 120 | 70, 80, 100, 120 | 7 | 12 | 7, 8, 10, 12 |
| 12 | 84 | 144 | 84, 96, 120, 144 | 7 | 12 | 7, 8, 10, 12 |
| 16 | 112 | 192 | 112, 128, 160, 192 | 7 | 12 | 7, 8, 10, 12 |
| 20 | 140 | 240 | 140, 160, 200, 240 | 7 | 12 | 7, 8, 10, 12 |
| 24 | 168 | 288 | 168, 192, 240, 288 | 7 | 12 | 7, 8, 10, 12 |
| 32 | 224 | 384 | 224, 256, 320, 384 | 7 | 12 | 7, 8, 10, 12 |
| 40 | 280 | 480 | 280, 320, 400, 480 | 7 | 12 | 7, 8, 10, 12 |
| 48 | 336 | 480 | 336, 384, 480 | 7 | 10 | 7, 8, 10 |
| 56 | 392 | 448 | 392, 448 | 7 | 8 | 7, 8 |
| 64 | 448 | 448 | 448 | 7 | 7 | 8 |
| 80 | 560 | 560 | 560 | 7 | 7 | 8 |
| 96 | 560 | 560 | 560 | 5.83 | 5.83 | 5.83 |
| 128 | 560 | 560 | 560 | 4.38 | 4.38 | 4.38 |
Prissättning
När du använder funktionen för flexibelt minne, tänk på följande detaljer:
- Du betalar för extra minne per GB per timme.
- Debiterbart minne använder denna formel:
Billable memory = Total memory - default memory.
Till exempel, om du använder en pay-as-you-go-4 vCore-instans med 40 GB minne, betalar du för:
- 4 virtuella kärnor
- SQL-licens för 4 virtuella kärnor
- 12 GB fakturerbart minne (40 GB – (4*7) = 12 GB).
Regioner som stöds
Du kan skapa SQL Managed Instance endast i stödda regioner. För att skapa en SQL Managed Instance i en region som för närvarande inte stöds, skicka en supportförfrågan via Azure-portalen.
Prenumerationstyper som stöds
SQL Managed Instance stöder för närvarande distribution endast på följande prenumerationstyper:
- Enterprise-avtal (EA)
- Betala per användning
- CLOUD Service Provider (CSP)
- Utveckling/testning för företag
- Dev/Test
- -prenumerationer med månatlig Azure-kredit för Visual Studio-prenumeranter
- kostnadsfri utvärderingsversion
- Azure för studenter
- Azure i Open
- Azureplan
Regionala resursbegränsningar
Not
Om du vill ha den senaste informationen om regiontillgänglighet för prenumerationer kontrollerar du först väljer en region.
Prenumerationstyper som stöds kan innehålla ett begränsat antal resurser per region. SQL Managed Instance har en standardgräns per Azure-region (som du kan öka på begäran genom att skapa en särskild supportförfrågan i Azure-portalen) beroende på prenumerationstyp:
- vCore-enhetsgräns: Det maximala antalet vCore-enheter per hårdvarugeneration som du kan distribuera över alla instanser i en och samma region. En gp-virtuell kärna använder en enhet med virtuella kärnor och en virtuell BC-kärna tar fyra virtuella kärnor. Det totala antalet instanser är inte begränsat så länge det är inom enhetsgränsen för virtuell kärna.
Not
Dessa gränser är standardinställningar och inte tekniska begränsningar. Du kan öka gränserna på begäran genom att skapa en särskild supportförfrågan i Azure-portalen om du behöver fler instanser i den aktuella regionen. Alternativt kan du skapa nya instanser av SQL Managed Instance i en annan Azure-region utan att skicka supportbegäranden.
I följande tabell visas regionala standardgränser för prenumerationstyper som stöds (standardgränser kan utökas med en supportbegäran):
| Prenumerationstyp | Standardgräns för virtuella kärnor 1 |
|---|---|
| CSP | 960 (1440 i vissa regioner2) |
| EA | 960 (1440 i vissa regioner2) |
| Företagsutveckling/Test | 320 |
| Betala efter hand | 320 |
| Betala per användning Dev/Test | 320 |
| Azure-pass | 64 |
| BizSpark (på engelska) | 64 |
| BizSpark Plus | 64 |
| Microsoft Azure-sponsring | 64 |
| Microsofts partnernätverk | 64 |
| Visual Studio Enterprise (MPN) | 64 |
| Visual Studio Enterprise | 32 |
| Visual Studio Enterprise (BizSpark) | 32 |
| Visual Studio Professional | 32 |
| MSDN-plattformar | 32 |
1 Vid planering av utplaceringar, beakta att Business Critical (BC) servicetier kräver fyra (4) gånger mer vCore-kapacitet än General Purpose (GP) servicenivån. Till exempel: 1 GP vCore = 1 vCore-enhet och 1 BC vCore = 4 virtuella kärnor. För att förenkla din konsumtionsanalys mot standardgränserna, sammanfatta vCore-enheterna per hårdvarugenerering över alla instanser i regionen där SQL Managed Instance är implementerad och jämför resultaten med vCore-enhetsgränserna för din prenumerationstyp. Maxgränsen för antalet vCore-enheter gäller för varje prenumeration per hårdvarugeneration i en region.
2 större vCore-gränser finns tillgängliga i följande regioner: Australien Öst, Östra USA, Östra USA 2, Nordeuropa, Sydcentrala USA, Sydostasien, Storbritannien Syd, Västeuropa, Västra USA 2.
Viktig
Om din vCore-gräns är 0 betyder det att den standardregionala gränsen för din prenumerationstyp inte är satt. Du kan också använda kvotökningsbegäran för att få prenumerationsåtkomst i en specifik region enligt samma procedur – att ange nödvändiga vCore-värden.
Standardgränser för regional vCore kan sänkas eller pausas vid regionala kapacitetsbegränsningar.
Kontrollera vCore-kvotgräns och användning med PowerShell
Använd prenumerationsanvändningarna – Hämta REST API för att hämta den aktuella vCore-kvotgränsen och konsumtionen för Azure SQL Managed Instance i en prenumeration och region. Fråga varje hårdvarugeneration separat genom att ange dess användningsnamn:
| Maskinvarugenerering | Användningsnamn |
|---|---|
| Standardserie (Gen5) | SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota |
| Premium-serien | SubscriptionSQLManagedInstancePremiumSeriesVCoreQuota |
| Minnesoptimerad premiumserie | SubscriptionSQLManagedInstancePremiumSeriesMemoryOptimizedVCoreQuota |
Kör följande skript i en PowerShell-session med Az-modulen installerad, eller i Azure Cloud Shell med PowerShell. Ditt konto behöver tillstånd för att läsa prenumerationsanvändning, såsom Läsarrollen som tilldelats vid prenumerationsomfattningen.
Byt ut <subscription-id> med ditt prenumerations-ID, ställ $location in till Azure-regionnamnet (till exempel eastus), och ställ $usageName in till ett av värdena i föregående tabell. Om du redan är inloggad via Cloud Shell, utelämnaConnect-AzAccount.
$subscriptionId = "<subscription-id>"
$location = "eastus"
$usageName = "SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota"
Connect-AzAccount -ErrorAction Stop | Out-Null
Set-AzContext -SubscriptionId $subscriptionId -ErrorAction Stop | Out-Null
$path = "/subscriptions/$subscriptionId/providers/Microsoft.Sql/locations/$location/usages/${usageName}?api-version=2025-01-01"
$response = Invoke-AzRestMethod -Method GET -Path $path -ErrorAction Stop
if ($response.StatusCode -ne 200) {
throw "Unable to retrieve quota usage. HTTP $($response.StatusCode): $($response.Content)"
}
$response.Content | ConvertFrom-Json -ErrorAction Stop | ConvertTo-Json -Depth 10
Exempelutdata (utdrag; värden är illustrativa):
{
"name": "SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota",
"properties": {
"currentValue": 80,
"limit": 320,
"unit": "SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota"
}
}
I detta exempel är den aktuella kvotförbrukningen: properties.currentValue80 vCore-enheter.
properties.limit är den nuvarande kvotgränsen: 320 vCore-enheter. Den återstående kvoten är limit - currentValue, eller 240 vCore-enheter, för standardseriehårdvara i den angivna prenumerationen och regionen.
Som beskrivits tidigare i detta avsnitt förbrukar varje General Purpose vCore en vCore-enhet, och varje Business Critical vCore förbrukar fyra vCore-enheter. Upprepa förfrågan med en annan $usageName eller $location för att kontrollera en annan hårdvarugeneration eller region. För att höja gränsen, se Begär en kvotökning.
Viktig
Det tidigare använda VCoreQuota användningsnamnet, som representerade en enda regional kvot delad mellan alla hårdvarugenerationer, föråldras till förmån för hårdvarugenerationsspecifika kvoter. Använd användningsnamnen som anges i föregående tabell för att hämta kvotgränsen och förbrukningen för varje hårdvarugeneration.
Begära en kvotökning
Om du behöver fler instanser i dina nuvarande regioner, skicka en supportförfrågan för att utöka kvoten genom att använda Azure-portalen. Mer information finns i Begärandekvotökningar för Azure SQL Database och SQL Managed Instance.
Not
Från och med augusti 2026 ändrades SQL Managed Instance-kvotförfrågningstyperna. Subnätkvoter gäller inte längre, och vCore-kvoter är nu begränsade per hårdvarugeneration. För mer information, se SQL Managed Instance kvotbegäransökningstyper.