Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:
Azure SQL Managed Instance
Dieser Artikel bietet einen Überblick über die technischen Eigenschaften und Ressourcenbeschränkungen der Azure SQL Managed Instance. Es gibt außerdem Informationen darüber, wie man eine Erhöhung dieser Grenzen beantragen kann.
Hinweis
Für Unterschiede bei unterstützten Funktionen und T-SQL-Anweisungen siehe Funktionsunterschiede und Unterstützung für T-SQL-Anweisungen. Für allgemeine Unterschiede zwischen Service-Stufen für Azure SQL-Datenbank und SQL Managed Instance lesen Sie die General Purpose und Business Critical Service Tiers.
Hardwarekonfigurationseigenschaften
Inhalt dieses Abschnitts:
- Regionale Unterstützung für speicheroptimierte Premium-Serien-Hardware und Premium-Serien-Hardware mit 16-TB-Speicher
- In-Memory OLTP verfügbarer Speicherplatz
SQL Managed Instance umfasst Merkmale und Ressourcenlimits, die von der zugrunde liegende Infrastruktur und Architektur abhängen. Du kannst SQL Managed Instance auf mehreren Hardwaregenerationen bereitstellen.
Hardwaregenerationen weisen unterschiedliche Merkmale auf, wie in der folgenden Tabelle beschrieben:
| Merkmal | Standard-Serie (Gen5) | Premium-Serie | Arbeitsspeicheroptimierte Premium-Serie |
|---|---|---|---|
| CPU | Intel® E5-2673 v4-Prozessoren (Broadwell) mit 2,3 GHz, Intel® SP-8160-Prozessoren (Skylake) und Intel® 8272CL-Prozessoren (Cascade Lake) mit 2,5 GHz | Intel® 8370C-Prozessoren (Ice Lake) mit 2,8 GHz | Intel® 8370C-Prozessoren (Ice Lake) mit 2,8 GHz |
|
Anzahl von virtuellen Kernen virtueller Kern = 1 LP (Hyperthread) |
21 -80 virtuelle Kerne | 21 -128 virtuelle Kerne | 4 bis 128 virtuelle Kerne |
| Max. Arbeitsspeicherbelegung (Verhältnis Arbeitsspeicher/virtueller Kern) | 5,1 GB pro virtuellem Kern – maximal 408 GB Fügen Sie weitere virtuelle Kerne hinzu, um mehr Arbeitsspeicher zu erhalten. |
7 GB pro virtuellem Kern bis zu 80 virtuelle Kerne – maximal 560 GB | 13,6 GB pro virtuellem Kern bis zu 64 virtuelle Kerne – maximal 870,4 GB |
| Max. In-Memory-OLTP-Speicher | Grenzwert für Instanzen: 0,8–1,65 GB pro virtuellem Kern | Instanzlimit: 1,1–2,3 GB pro virtuellem Kern | Instanzlimit: 2,2–4,5 GB pro virtuellem Kern |
| Max. reservierter Instanzspeicher2 |
Allgemeiner Zweck: bis zu 32 TB4 Unternehmenskritisch: bis zu 4 TB |
Allgemeiner Zweck: bis zu 32 TB4 Unternehmenskritisch: bis zu 16 TB3 |
Allgemeiner Zweck: bis zu 32 TB4 Unternehmenskritisch: bis zu 16 TB |
1 Du kannst nur eine 2-vCore-Instanz innerhalb eines Instanzpools bereitstellen.
2 Abhängig von der Anzahl der virtuellen Kerne.
3 Die folgenden Regionen können 16 TB Speicher bereitstellen, während andere Regionen den verfügbaren Speicher auf 5,5 TB beschränken.
4 16 TB für klassischen Allgemeinen Zweck. Nur 32 TB für Next-Gen General Purpose Service Tier
Hinweis
Wenn Ihre Workload Speichergrößen erfordert, die größer als die verfügbaren Ressourcengrenzwerte für Azure SQL Managed Instance sind, sollten Sie die Hyperscale-Dienstebene von Azure SQL-Datenbank in Betracht ziehen.
Regionale Unterstützung für speicheroptimierte Premium-Serien-Hardware und Premium-Serien-Hardware mit 16-TB-Speicher
Die Unterstützung für die Hardware der Premium-Serie mit 16-TB-Speicher hat die gleiche Verfügbarkeit wie die Unterstützung für die speicheroptimierte Hardware der Premium-Serie. Weitere Informationen finden Sie unter Regionale Unterstützungen für speicheroptimierte Premium-Serien-Hardware und Premium-Serien-Hardware mit 16-TB-Speicher.
Verfügbarer Speicherplatz für In-Memory-OLTP
Die Menge des In-Memory-OLTP-Speichers im Business Critical-Service-Tier hängt von der Anzahl der vCores und der Hardwarekonfiguration ab. Die folgende Tabelle listet die Speichergrenzen auf, die Sie für In-Memory-OLTP-Objekte verwenden können.
| V-Kerne | Standard-Serie (Gen5) | Premium-Serie | Arbeitsspeicheroptimierte Premium-Serie |
|---|---|---|---|
| 4 virtuelle Kerne | 3,14 GB | 4,39 GB | 8,79 GB |
| 6 virtuelle Kerne | - | 6,59 GB | 15,32 GB |
| 8 virtuelle Kerne | 6,28 GB | 8,79 GB | 22,06 GB |
| 10 virtuelle Kerne | - | 12,11 GB | 30,94 GB |
| 12 virtuelle Kerne | - | 15,43 GB | 39,82 GB |
| 16 virtuelle Kerne | 15,77 GB | 22,06 GB | 57,58 GB |
| 20 virtuelle Kerne | - | 28,70 GB | 75,34 GB |
| 24 virtuelle Kerne | 25,25 GB | 35,34 GB | 93,09 GB |
| 32 virtuelle Kerne | 37,94 GB | 53,09 GB | 128,61 GB |
| 40 virtuelle Kerne | 52,23 GB | 73,09 GB | 164,13 GB |
| 48 virtuelle Kerne | - | 95,34 GB | 199,64 GB |
| 56 virtuelle Kerne | - | 117,58 GB | 244,13 GB |
| 64 virtuelle Kerne | 99,9 GB | 139,82 GB | 288,61 GB |
| 80 virtuelle Kerne | 131,68 GB | 184,30 GB | 288,61 GB |
| 96 virtuelle Kerne | N/V | 184,30 GB | 288,61 GB |
| 128 virtuelle Kerne | N/V | 184,30 GB | 288,61 GB |
Merkmale der Dienstebene
SQL Managed Instance umfasst zwei Dienstebenen: Universell und Unternehmenskritisch. Sie können die aktualisierte Dienstebene der nächsten Generation verwenden.
Wichtig
Das Business Critical-Service-Tier stellt eine zusätzliche integrierte Kopie der SQL Managed Instance (sekundäre Replik) bereit, die für schreibgeschützte Workloads verwendet wird. Wenn man Lese-Schreib-Abfragen von Nur-Lese-, Analyse- oder Berichtsanfragen trennt, erhält man doppelt so viele vCores und Speicher zum gleichen Preis. Die sekundäre Replik kann ein paar Sekunden hinter der primären Instanz zurückbleiben, daher ist sie darauf ausgelegt, Berichte und Analyse-Workloads zu entlasten, die nicht den exakt aktuellen Datenzustand benötigen. In der folgenden Tabelle sind Read-Only-Abfragen die Abfragen, die auf der sekundären Replik ausgeführt werden.
Inhalt dieses Abschnitts:
- Anzahl von virtuellen Kernen
- Maximaler Arbeitsspeicher
- Maximale Instanzspeichergröße
- Vergleich der Merkmale der Dienstebene
- IOPS und Durchsatz
- Daten- und Protokollspeicher
- Sicherungen und Speicher
- Überlegungen zu zusätzlichen Merkmalen
Anzahl der virtuellen Kerne
| Hardwaregenerierung | Allgemeiner Zweck | Universell der nächsten Generation | Unternehmenskritisch |
|---|---|---|---|
| Standard-Serie (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-Serie | 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 |
| Arbeitsspeicheroptimierte Premium-Serie | 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 Die Bereitstellung einer Instance mit 2 virtuellen Kernen ist nur innerhalb eines Instance-Pools möglich.
Max. Arbeitsspeicherbelegung
| Hardwaregenerierung | Allgemeiner Zweck | Universell der nächsten Generation | Unternehmenskritisch |
|---|---|---|---|
| Standard-Serie (Gen5) | 20,4 GB - 408 GB 5,1 GB/virtueller Kern |
20,4 GB - 408 GB 5,1 GB/virtueller Kern |
20,4 GB - 408 GB 5,1 GB/virtueller Kern für jedes Replikat |
| Premium-Serie | 28 GB – 560 GB 7 GB/virtueller Kern |
28 GB – 560 GB 7 GB/virtueller Kern |
28 GB – 560 GB 7 GB/virtueller Kern bis zu 80 virtuelle Kerne1 auf jedem Replikat |
| Arbeitsspeicheroptimierte Premium-Serie | 54,4 GB - 870,4 GB 13,6 GB/virtueller Kern |
54,4 GB - 870,4 GB 13,6 GB/virtueller Kern |
54,4 GB - 870,4 GB 13,6 GB/virtueller Kern bis zu 64 virtuelle Kerne1 auf jedem Replikat |
1 Das Speicher-zu-vCore-Verhältnis von bis zu 80 virtuelle Kerne ist nur für Premium-Serie-Hardware verfügbar, und 64 virtuelle Kerne für die speicheroptimierte Premium-Serie. Der maximale Speicher ist auf 560 GB für virtuelle Kerne der Premium-Serie über 80 und 870,4 GB für virtuelle Kerne der speicheroptimierte Premium-Serie über 64 begrenzt.
Maximale Instanzspeichergröße (reserviert)
Die folgende Tabelle enthält die maximale Speichergröße basierend auf der Anzahl der vCores für jede Hardwaregenerierung und Dienstebene:
| Hardwaregenerierung | Allgemeiner Zweck1 | Universell der nächsten Generation | Geschäftskritisch2 |
|---|---|---|---|
| Standard-Serie (Gen5) | – 2 TB für 4 virtuelle Kerne – 8 TB für 8 virtuelle Kerne – 16 TB für andere Größen |
– 2 TB für 4 virtuelle Kerne – 8 TB für 8 virtuelle Kerne - 16 TB für 16, 24 vCores - 32 TB für 32, 40, 64, 80 vCores |
– 1 TB für 4, 8, 16 virtuelle Kerne - 2 TB für 24 vCores - 4 TB für 32, 40, 64, 80 virtuelle Kerne |
| Premium-Serie | – 2 TB für 4 virtuelle Kerne – 8 TB für 8 virtuelle Kerne – 16 TB für andere Größen |
– 2 TB für 4, 6 virtuelle Kerne – 8 TB für 8, 10, 12 virtuelle Kerne – 16 TB für 16, 20, 24 virtuelle Kerne – 32 TB für 32, 40, 48, 56, 64, 80, 96, 128 virtuelle Kerne |
- 1 TB für 4, 6 vCores - 2 TB für 8, 10, 12 vCores – 4 TB für 16, 20 virtuelle Kerne - 5,5 TB für 24, 32, 40, 48, 56 virtuelle Kerne - 5,5 TB oder 16 TB (je nach Region) für 64, 80, 96, 128 vCores3 |
| Arbeitsspeicheroptimierte Premium-Serie | – 2 TB für 4 virtuelle Kerne – 8 TB für 8 virtuelle Kerne – 16 TB für andere Größen |
– 2 TB für 4, 6 virtuelle Kerne – 8 TB für 8, 10, 12 virtuelle Kerne – 16 TB für 16, 20, 24 virtuelle Kerne – 32 TB für 32, 40, 48, 56, 64, 80, 96, 128 virtuelle Kerne |
- 1 TB für 4, 6 vCores - 2 TB für 8, 10, 12 vCores – 4 TB für 16, 20 virtuelle Kerne – 5,5 TB für 24 virtuelle Kerne - 5,5 TB oder 8 TB (je nach Region) für 32, 40 vCores4 - 12 TB für 48, 56 virtuelle Kerne - 16 TB für 64, 80, 96, 128 virtuelle Kerne |
1 In der Dienstebene tempdb für allgemeine Zwecke verwendet der lokale SSD-Speicher.
2 Teilt in der Business Critical-Dienstebene tempdb den lokalen SSD-Speicher mit Daten und Protokolldateien. Die Größe tempdb kann bis zur derzeit verfügbaren Speichergröße der Instanz vergrößert werden.
3 Nur die hauptregionen können 16 TB Speicherplatz für die Premium-Hardware für diese CPU-vCore-Nummern bereitstellen. Kleinere Regionen beschränken den verfügbaren Speicher auf 5,5 TB.
4 Nur die hauptregionen können 8 TB Speicher für die für die Premium-Serie optimierte Hardware für diese CPU-vCore-Nummern bereitstellen. Kleinere Regionen beschränken den verfügbaren Speicher auf 5,5 TB.
Vergleich der Merkmale der Dienstebene
| Merkmal | Allgemeiner Zweck | Universell der nächsten Generation | Unternehmenskritisch |
|---|---|---|---|
| Max. Datenbankgröße | Bis zur derzeit verfügbaren Instanzgröße (abhängig von der Anzahl der virtuellen Kerne). | Bis zur derzeit verfügbaren Instanzgröße (abhängig von der Anzahl der virtuellen Kerne). | Bis zur derzeit verfügbaren Instanzgröße (abhängig von der Anzahl der virtuellen Kerne). |
Max. tempdb Datenbankgröße |
Begrenzt auf 24 GB/V-Kern (96 – 1.920 GB) und die derzeit verfügbare Instanzspeichergröße. Fügen Sie weitere virtuelle Kerne hinzu, um mehr platz für tempdb zu erhalten.Die Größe der Protokolldatei ist auf 120 GB begrenzt. |
Begrenzt auf 24 GB/V-Kern (96 – 1.920 GB) und die derzeit verfügbare Instanzspeichergröße. Fügen Sie weitere virtuelle Kerne hinzu, um mehr platz für tempdb zu erhalten.Die Größe der Protokolldatei ist auf 120 GB begrenzt. |
Bis zur aktuell verfügbaren Instanzspeichergröße. |
Max. Anzahl der tempdb-Dateien |
128 | 128 | 128 |
| Max. Anzahl von Datenbanken pro Instanz | 100 Benutzerdatenbanken (es sei denn, der Grenzwert für die Instanzspeichergröße wurde erreicht). | 500 Benutzerdatenbanken | 100 Benutzerdatenbanken (es sei denn, der Grenzwert für die Instanzspeichergröße wurde erreicht). |
| Max. Anzahl von Datenbankdateien | 280 pro Instanz, außer wenn die Instanzspeichergröße oder der Grenzwert für Azure Premium Disk-Speicherbelegungsplatz erreicht wurde. | 4.096 Dateien pro Datenbank | 32.767 Dateien pro Datenbank, außer wenn der Grenzwert für die Instanzspeichergröße erreicht wurde. |
| Maximale Größe der Datendatei | Die maximale Größe jeder Datendatei beträgt 8 TB. Verwenden Sie bei Datenbanken über 8 TB mindestens zwei Datendateien. | Bis zur derzeit verfügbaren Instanzgröße (abhängig von der Anzahl der virtuellen Kerne). | Bis zur derzeit verfügbaren Instanzgröße (abhängig von der Anzahl der virtuellen Kerne). |
| Maximale Protokolldateigröße | Begrenzt auf 2 TB und die derzeit verfügbare Instanzspeichergröße. | Begrenzt auf 2 TB und die derzeit verfügbare Instanzspeichergröße. | Begrenzt auf 2 TB und die derzeit verfügbare Instanzspeichergröße. |
| Daten-/Protokoll-IOPS (ungefähr) | 500 bis 7.500 pro Datei * Erhöhen Sie die Dateigröße, um den IOPS-Wert zu erhöhen |
Reservierter Speicher * 3 – bis zum VM-Grenzwert. 300 bei 32 GB, 64 GB und 96 GB reserviertem Speicher. Der VM-Grenzwert hängt von der Anzahl der virtuellen Kerne ab 6400 IOPS bei einem virtuellen Computer mit 4 virtuellen Kernen – 80.000 IOPS bei einem virtuellen Computer mit 128 virtuellen Kernen |
16.000 – 320.000 (4.000 IOPS/virtueller Kern) Fügen Sie weitere virtuelle Kerne hinzu, um die E/A-Leistung zu verbessern. |
| Datendurchsatz (ungefähr) | 100–250 MiB/s pro Datei * Erhöhen Sie die Dateigröße, um die E/A-Leistung zu verbessern |
IOPS / 30 MBit/s – bis zum VM-Grenzwert. 75 MBit/s bei 32 GB, 64 GB und 96 GB reserviertem Speicher. | Nicht begrenzt. |
| Grenzwert für den Protokollschreibdurchsatz (pro Instanz) | 4,5 MiB/Sek. pro virtuellem Kern Max. 120 MiB/s pro Instanz 22–65 MiB/s pro Datenbank (abhängig von der Größe der Protokolldatei) * Erhöhen Sie die Dateigröße, um die E/A-Leistung zu verbessern |
Standardreihen: 4,5 MiB/Sek. pro virtuellem Kern Maximal 120 MiB/s Premium-Serie und speicheroptimierte Premium-Serie: 4,5 MiB/Sek. pro virtuellem Kern Max. 192 MiB/s |
Standardreihen: 16 MiB/s pro vCore Maximal 160 MiB/s Premium-Serie und speicheroptimierte Premium-Serie: 16 MiB/s pro vCore Max. 192 MiB/s |
| Speicher-E/A-Latenz (ungefähre1) | 5 – 10 ms | 3-5 ms | 1 – 2 ms |
| In-Memory-OLTP | Nicht unterstützt | Nicht unterstützt | Verfügbar, Größe hängt von der Anzahl der V-Kerne ab |
| Max. Sitzungen | 30.000 | 30.000 | 30.000 |
| maximale Anzahl gleichzeitiger Worker | 105 * Anzahl der virtuellen Kerne + 800 | 105 * Anzahl der virtuellen Kerne + 800 | 105 * Anzahl der virtuellen Kerne + 800 |
| Verwenden von schreibgeschützten Replikaten zum Auslagern schreibgeschützter Abfrageworkloads | 0 | 0 | 1 (im Preis inbegriffen) |
| Computeisolation | Nicht unterstützt, da allgemeine Instanzen physische Hardware für andere Instanzen freigeben können | Nicht unterstützt, da General Purpose-Instanzen der nächsten Generation physische Hardware für andere Instanzen freigeben können |
Standardserie (Gen5): Unterstützt für Konfigurationen mit 64 oder mehr vCores Premium-Serie: Unterstützt für Konfigurationen mit 64 oder mehr vCores Arbeitsspeicheroptimierte Premium-Serie: unterstützt für Konfigurationen mit 64 oder mehr virtuellen Kernen |
| Replikate zur Verfügbarkeit | Standbyknoten für hohe Verfügbarkeit | Standbyknoten für hohe Verfügbarkeit | Vier Replikate mit hoher Verfügbarkeit, 1 ist auch ein Leseskalierungs-Replikat |
| Schreibgeschützte Replikate mit aktivierten Failovergruppen | Ein zusätzliches schreibgeschütztes Replikat. Insgesamt zwei Lesereplikate, darunter das primäre Replikat. | Ein zusätzliches schreibgeschütztes Replikat. Insgesamt zwei Lesereplikate, darunter das primäre Replikat. | Zwei zusätzliche schreibgeschützte Replikate, insgesamt drei schreibgeschützte Replikate. Insgesamt vier Lesereplikate, darunter das primäre Replikat. |
| Preise/Abrechnung |
Virtueller Kern, reservierter Speicher und Sicherungsspeicher werden in Rechnung gestellt. IOPS werden nicht belastet. |
Virtuelle Kerne, reservierter Speicher, Sicherungsspeicher und IOPS (über das kostenlose Kontingent hinaus) werden in Rechnung gestellt. |
Virtueller Kern, reservierter Speicher und Sicherungsspeicher werden in Rechnung gestellt. IOPS werden nicht belastet. |
| Rabattmodelle |
Azure-Reservierungen Azure-Hybridvorteil – Azure SQL-Datenbank & SQL Managed Instance (nicht für Dev/Testabonnements verfügbar) Enterprise- und Dev/Test Pay-As-You-Go-Subscriptions |
Azure-Reservierungen Azure-Hybridvorteil – Azure SQL-Datenbank & SQL Managed Instance (nicht für Dev/Testabonnements verfügbar) Enterprise- und Dev/Test Pay-As-You-Go-Subscriptions |
Azure-Reservierungen Azure-Hybridvorteil – Azure SQL-Datenbank & SQL Managed Instance (nicht für Dev/Testabonnements verfügbar) Enterprise- und Dev/Test Pay-As-You-Go-Subscriptions |
1 Dies ist ein durchschnittlicher Bereich. Obwohl die überwiegende Mehrheit der E/A-Anforderungsdauer unter den Oberen des Bereichs fällt, sind Ausreißer möglich, die den Bereich überschreiten.
IOPS und Durchsatz
IOPS und Durchsatz sind Merkmale des E/A-Dateisystems.
IOPS und Durchsatz unterscheiden sich je nach Dienstebene auf folgende Weise:
- In der Business Critical-Dienstebene ist der Durchsatz unbegrenzt.
- In der Dienstebene für allgemeine Zwecke hängt der Durchsatz von der Dateigröße ab.
- In der Dienstebene der nächsten Generation wird der Durchsatz proportional skaliert, wobei die Anzahl der der Instanz zugeordneten IOPS entspricht.
In den folgenden Abschnitten werden die E/A-Merkmale nach Dienstebene ausführlicher beschrieben.
IOPS und Durchsatz in der Dienstebene für allgemeine Zwecke
Auf der Dienstebene „Universell“ erhält jede Datenbankdatei in Abhängigkeit von der Dateigröße dedizierte Mengen an IOPS und Durchsatz. Größere Dateien erhalten mehr IOPS und einen höheren Durchsatz.
In der folgenden Tabelle sind die E/A-Merkmale von Datenbankdateien auf der Dienstebene " Allgemein" aufgeführt:
| Dateigröße | >=0 und <=129 GiB | >129 und <=513 GiB | >513 und <=1025 GiB | >1025 und <=2049 GiB | >2049 und <=4097 GiB | >4097 GiB und <=8 TiB |
|---|---|---|---|---|---|---|
| IOPS pro Datei | 500 | 2300 | 5.000 | 7.500 | 7.500 | 7.500 |
| Durchsatz pro Datei | 100 MiB/s | 150 MiB/s | 200 MiB/s | 250 MiB/s | 250 MiB/s | 250 MiB/s |
Wenn Sie für bestimmte Datenbankdateien eine hohe E/A-Latenz bemerken oder feststellen, dass der Grenzwert für IOPS/Durchsatz erreicht wird, können Sie die Leistung möglicherweise durch Vergrößern der Dateigröße verbessern.
Es gibt auch eine Beschränkung auf Instanzebene für den maximalen Protokollschreibdurchsatz (die Werte finden Sie der obigen Tabelle, z. B. 22 MiB/s), sodass Sie den maximalen Dateidurchsatz für die Protokolldatei möglicherweise nicht erreichen, da der Grenzwert für den Durchsatz auf Instanzebene erreicht wurde.
IOPS und Durchsatz in der Dienstebene der nächsten Generation
Die Dienstebene der nächsten Generation für allgemeine Zwecke weist die folgenden IOPS-Merkmale auf:
- Mindestens garantierte IOPS: Jede Instanz wird unabhängig vom reservierten Speicher mindestens 300 IOPS garantiert.
- IOPS skaliert mit reservierten Speicher: Für alle 1 GB reservierten Speicher erhalten Sie 3 integrierte IOPS. Wenn Sie beispielsweise über 1024 GB reservierten Speicher verfügen, erhalten Sie 3072 IOPS zugewiesen.
- Zusätzliche IOPS: Sie können die Menge der IOPS über dem integrierten Wert bis zur Obergrenze erhöhen.
- Maximale IOPS-Obergrenze pro vCore-Anzahl: Jede vCore-Konfiguration hat einen maximalen IOPS-Grenzwert, wie die maximale IOPS pro vCore-Tabelle angezeigt wird.
Die Dienstebene der nächsten Generation für allgemeine Zwecke weist die folgenden Durchsatzmerkmale auf:
- Minimal garantierter Durchsatz: Jede Instanz wird unabhängig von der Anzahl der vCores mindestens 75 MB/s des Durchsatzes garantiert.
-
Durchsatzskalierung mit IOPS: Der Durchsatz skaliert proportional mit der Anzahl der IOPS, die der Instanz zugeordnet sind, mithilfe der Formel
throughput (MB/s) = IOPS / 30. Beispielsweise erhält eine Instanz, die 3.000 IOPS zugeordnet ist, 100 MB/s Durchsatz. - Maximale Durchsatzgrenze pro vCore-Anzahl: Jede vCore-Konfiguration weist eine maximale Durchsatzgrenze auf, wie der maximale Durchsatz pro vCore-Tabelle zeigt. Sobald die erforderlichen IOPS bereitgestellt werden, um diese Obergrenze zu erreichen, erhöht das Zuordnen zusätzlicher IOPS die IOPS-Kapazität, erhöht aber den Durchsatz nicht weiter. Beispielsweise erreicht eine 4 vCore-Instanz (max. 6.400 IOPS) ihre Durchsatzgrenze von 145 MB/s bei 4.350 IOPS. Die Skalierung von IOPS von 4.350 auf 6.400 bietet mehr IOPS für die Instanz, aber der Durchsatz bleibt bei 145 MB/s begrenzt. Um den maximalen Durchsatz zu erhöhen, fügen Sie weitere vCores hinzu.
In der folgenden Tabelle sind die maximalen IOPS und der Durchsatz pro Anzahl von vCores aufgeführt, die einer Instanz auf der Dienstebene der nächsten Generation zugeordnet sind:
| Anzahl von virtuellen Kernen | Max. IOPS | Max. Durchsatz (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-Preise im Allgemeinen Zweck der nächsten Generation
Berücksichtigen Sie bei der Verwendung der zusätzlichen IOPS Folgendes:
- Zusätzliche IOPS wird pro IOPS/Monat berechnet.
- Rechnungsfähige IOPS wird mit der folgenden Formel berechnet:
Billable IOPS = Total IOPS - default IOPS
Wenn Sie beispielsweise über eine Pay-as-you-go 4 vCore-Instanz mit 6400 IOPS verfügen, wird Folgendes berechnet:
- 4 virtuelle Kerne
- SQL-Lizenz für 4 vCores
- 1024 GB reservierter Speicher
- 3328 von abrechnenden IOPS
(6400 - (1024*3) = 3328 IOPS).
IOPS und Durchsatz auf der Business Critical-Dienstebene
In der Dienstebene "Geschäftskritischer Dienst" werden verfügbare IOPS durch die Anzahl der vCores mit der Formel 4000 IOPS/vCorebestimmt. Da die Business Critical-Dienstebene lokale Speicher für Daten- und Protokolldateien verwendet, ist der Durchsatz unbegrenzt.
In der folgenden Tabelle sind die maximalen IOPS aufgeführt, die auf der Business Critical-Dienstebene basierend auf der Anzahl der vCores verfügbar sind:
| Anzahl der virtuellen Kerne | Unternehmenskritisch |
|---|---|
| 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 |
Daten- und Protokollspeicher
Die folgenden Faktoren beeinflussen die Speichermenge, die für Daten und Logdateien verwendet wird. Diese Faktoren gelten sowohl für die General Purpose als auch Business Critical.
- In der Dienstebene „Universell“ wird für
tempdblokaler SSD-Speicher verwendet, und diese Speicherkosten sind im V-Kern-Preis enthalten. - In der Business Critical-Service-Stufe
tempdbwird der lokale SSD-Speicher mit Daten und Logdateien geteilt, und dietempdbSpeicherkosten sind im vCore-Preis enthalten. Sie können bis zur derzeit verfügbaren Instanzspeichergröße anpassentempdb. - Sie müssen die maximale Speichergröße für eine SQL Managed Instance in Vielfachen von 32 GB angeben.
Wichtig
In beiden Service-Stufen zahlst du für die maximale Speichergröße, die für eine SQL Managed Instance konfiguriert ist.
Zum Überwachen der insgesamt verbrauchten Instanzspeichergröße für SQL Managed Instance verwenden Sie die Metrikstorage_space_used_mb. Um die aktuelle zugewiesene und verwendete Speichergröße einzelner Daten und Protokolldateien in einer Datenbank mithilfe von T-SQL zu überwachen, verwenden Sie die sys.database_files Ansicht und die FILEPROPERTY(... , 'SpaceUsed')- Funktion.
Tipp
Unter bestimmten Umständen müssen Sie möglicherweise eine Datenbank verkleinern, um nicht genutzten Speicherplatz freizufordern. Weitere Informationen finden Sie unter DBCC SHRINKFILE.
Sicherungen und Speicher
Der Speicher für Datenbanksicherungen wird zugeordnet, um die Funktionen Zeitpunktwiederherstellung (Point in Time Restore, PITR) und Langzeitaufbewahrung (Long Term Retention, LTR) von SQL Managed Instance zu unterstützen. Dieser Speicher ist vom Daten- und Protokolldateispeicher getrennt und wird separat abgerechnet.
PITR: In den Dienstebenen „Universell“ und „Unternehmenskritisch“ werden einzelne Datenbanksicherungen automatisch in den georedundanten Speicher mit Lesezugriff (Read-Access Geo-Redundant Storage, RA-GRS) kopiert. Die Speichergröße wird dynamisch erhöht, wenn neue Sicherungen erstellt werden. Der Speicher wird für vollständige, differenzielle und Transaktionsprotokollsicherungen verwendet. Der Speicherverbrauch richtet sich nach der Änderungsrate der Datenbank und nach dem für Sicherungen konfigurierten Aufbewahrungszeitraum. Sie können für jede Datenbank einen separaten Aufbewahrungszeitraum zwischen 1 und 35 Tagen für SQL Managed Instance konfigurieren. Eine Sicherungsspeichermenge, die der konfigurierten maximalen Datengröße entspricht, wird ohne Zusatzkosten bereitgestellt.
LTR: Sie haben auch die Möglichkeit, die Langzeitaufbewahrung von vollständigen Sicherungen für bis zu 10 Jahre zu konfigurieren. Wenn Sie eine LTR-Richtlinie einrichten, werden diese Sicherungen automatisch im RA-GRS-Speicher gespeichert. Sie können jedoch steuern, wie häufig die Sicherungen kopiert werden. Um verschiedene Compliance-Anforderungen zu erfüllen, können Sie unterschiedliche Aufbewahrungsperioden für wöchentliche, monatliche und jährliche Backups auswählen. Die Menge an Speicher, die für LTR-Sicherungen verwendet wird, richtet sich nach der ausgewählten Konfiguration. Weitere Informationen finden Sie unter langfristige Aufbewahrung – Azure SQL-Datenbank und azure SQL Managed Instance.
Überlegungen zu zusätzlichen Merkmalen
Die derzeit verfügbare Instanzspeichergröße ist die Differenz zwischen der reservierten Instanzgröße und dem belegten Speicherplatz.
Sowohl die Daten- als auch die Protokolldateigröße in den Benutzer- und Systemdatenbanken sind in der Instanzspeichergröße enthalten, die mit dem Grenzwert für die maximale Speichergröße verglichen wird. Ermitteln Sie mithilfe der Systemansicht sys.master_files den von Datenbanken verwendeten Gesamtspeicherplatz. Fehlerprotokolle werden nicht persistent gespeichert und sind nicht in der Größe enthalten. Sicherungen sind nicht in der Speichergröße enthalten.
Durchsatz und IOPS in der Ebene Universell hängen auch von der Dateigröße ab und werden nicht explizit durch SQL Managed Instance eingeschränkt.
Der maximale Instanz-IOPS hängt vom Dateilayout und der Workload-Verteilung ab. Wenn Sie z. B. 7 × 1 TB-Dateien mit jeweils maximal 5.000 IOPS und sieben kleine Dateien (kleiner als 128 GB) mit jeweils 500 IOPS erstellen, können Sie 38.500 IOPS pro Instanz (7 × 5.000 + 7 × 500) erzielen, sofern Ihre Workload alle Dateien verwenden kann. Einige IOPS werden auch für autobackups verwendet.
Sie können mithilfe von Gruppen für ein automatisches Failover ein weiteres lesbares Replikat in einer anderen Azure-Region erstellen
Die Namen von
tempdb-Dateien dürfen nicht mehr als 16 Zeichen aufweisen.
Weitere Informationen finden Sie im Artikel zu den Ressourcenlimits in SQL Managed Instance-Pools.
Flexibler Speicher
Standardmäßig ist die Menge des Arbeitsspeichers, der azure SQL Managed Instance zugeordnet ist, ein statischer Wert, der von der ausgewählten Anzahl von vCores bestimmt wird. Mit dem flexiblen Speicherfeature können Sie die Menge des Arbeitsspeichers ändern, der Ihrer sql-verwalteten Instanz zugeordnet ist, ohne die Anzahl der vCores zu ändern. Dieses Feature ist nützlich für Workloads, die mehr Arbeitsspeicher als die Standardzuordnung für eine bestimmte Anzahl von vCores erfordern.
Das flexible Speicherfeature ist in den folgenden Dienstebenen und Bereitstellungskonfigurationen auf Premium-Hardware verfügbar:
- Next-Gen General Purpose: lokal redundante und zonenredundante Instanzen. Flexibler Speicher ist allgemein verfügbar (GA) für lokal redundante Instanzen und befindet sich derzeit in der Vorschau für zonenredundante Instanzen. Zonenredundante Next-Gen-Allgemeine Instanzen benötigen Azure Elastic SAN zone-redundant Storage (ZRS), das in einigen Multi-Zonen-Regionen, die Zonenredundanz für SQL Managed Instance unterstützen, nicht verfügbar ist. Für die Elastic SAN ZRS-Verfügbarkeit siehe Create and deploy an Azure Elastic SAN.
- Unternehmenskritisch: lokal redundante und zonenredundante Instanzen. Flexibler Speicher ist im Allgemeinen verfügbar (GA) für die Business Critical-Service-Schicht.
Sie können die zugewiesene Speichermenge für Ihre SQL-verwaltete Instanz jederzeit für neue und bestehende Instanzen ändern, indem Sie das Azure-Portal oder die REST-API verwenden. Die Änderung der Speicherzuweisung gilt für alle Datenbanken in der Instanz und führt als letzten Operationsschritt ein Failover der Instanz durch. Überprüfen Sie die Dauer des Verwaltungsvorgangs , um die geschätzte Zeit für den Abschluss des Vorgangs zu ermitteln.
Verwenden Sie den Bereich Compute + Storage im Azure-Portal, um die Speicherzuweisung oder den properties.memorySizeInGB Wert des verwaltete Instanz - Create or Update REST API-Aufrufs ab der Vorschauversion 2024-08-01 zu ändern. Spezifizieren Sie die Speicherzuweisung in Gigabyte (GB).
Beim Zuordnen des Arbeitsspeichers können Sie zwischen einem Minimal- und Maximalwert wählen und auch das Verhältnis von Arbeitsspeicher zu vCores bestimmen. Die Mindest- und Maximalwerte hängen von der Anzahl der vCores ab, die du für die Instanz auswählst. Das Verhältnis zwischen Arbeitsspeicher und vCore ist ein Prozentsatz des Gesamtspeichers, der der Instanz zugeordnet ist.
In der folgenden Tabelle sind die Minimal- und Maximalspeicherwerte für die flexible Speicherfunktion aufgeführt:
| V-Kerne | Min. RAM (GB) | Maximaler RAM (GB) | Unterstützte API-RAM-Werte | Min-Verhältnis | Max. Verhältnis | Unterstützte Verhältnisse |
|---|---|---|---|---|---|---|
| 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 |
Preisgestaltung
Wenn Sie die Funktion des flexiblen Speichers nutzen, berücksichtigen Sie folgende Details:
- Du zahlst für zusätzlichen Speicher pro GB pro Stunde.
- Der abrechenbare Speicher verwendet diese Formel:
Billable memory = Total memory - default memory.
Wenn du zum Beispiel eine Pay-as-you-go-4-vCore-Instanz mit 40 GB Speicher verwendest, zahlst du für:
- 4 virtuelle Kerne
- SQL-Lizenz für 4 vCores
- 12 GB Rechnungsspeicher (40 GB - (4*7) = 12 GB).
Unterstützte Regionen
Du kannst SQL Managed Instance nur in unterstützten Regionen erstellen. Um eine SQL Managed Instance in einer Region zu erstellen, die derzeit nicht unterstützt wird, senden Sie eine Supportanfrage über das Azure-Portal.
Unterstützte Subscriptiontypen
SQL Managed Instance unterstützt derzeit die Bereitstellung nur bei den folgenden Abonnementtypen:
- Unternehmensvereinbarung (EA)
- Nutzungsbasierte Bezahlung
- Clouddienstanbieter (CSP)
- Enterprise Entwicklung/Test
- Dev/Test Pay-As-You-Go
- Subscriptions mit monatlicher Azure-Gutschrift für Visual Studio-Abonnenten
- Kostenlose Testversion
- Azure for Students
- Azure in Open
- Azure-Plan
Regionale Ressourcenbeschränkungen
Hinweis
Um die neuesten Informationen zur regionalen Verfügbarkeit von Subscriptios zu erhalten, verwenden Sie zunächst die Option Region auswählen.
Unterstützte Subscriptiontypen können eine begrenzte Anzahl von Ressourcen pro Region umfassen. Die SQL Managed Instance hat je nach Abonnementtyp eine Standardbegrenzung pro Azure-Region (die Sie auf Abruf durch das Erstellen einer speziellen Supportanfrage im Azure-Portal erhöhen können):
- vCore-Einheitenbegrenzung: Die maximale Anzahl von vCore-Einheiten pro Hardwaregeneration, die Sie über alle Instanzen in einer einzigen Region einsetzen können. Ein virtueller Kern „Universell“ verwendet eine einzige virtuelle Kerneinheit, und ein virtueller Kern „Unternehmenskritisch“ verwendet vier virtuelle Kerneinheiten. Die Gesamtzahl der Instanzen ist nicht begrenzt, solange sie sich innerhalb des vCore-Einheitenlimits befindet.
Hinweis
Diese Limits sind Standardeinstellungen und keine technischen Einschränkungen. Sie können die Limits auf Abruf erhöhen, indem Sie eine spezielle Support-Anfrage im Azure-Portal erstellen, falls Sie mehr Instanzen in der aktuellen Region benötigen. Alternativ können Sie auch neue Instanzen von SQL Managed Instance in einer anderen Azure-Region erstellen, ohne Supportanfragen zu senden.
In der folgenden Tabelle werden die standardmäßigen regionalen Grenzwerte für unterstützte Subscriptiontypen angezeigt (die Standardgrenzwerte können über eine Supportanfrage erweitert werden):
| Subscriptiontyp | Standardgrenzwert für vCore-Einheiten 1 |
|---|---|
| CSP | 960 (1440 in einigen Regionen2) |
| EA | 960 (1440 in einigen Regionen2) |
| Entwicklung/Test für Unternehmen | 320 |
| Nutzungsbasierte Bezahlung | 320 |
| Dev/Test Pay-As-You-Go | 320 |
| Azure Pass | 64 |
| BizSpark | 64 |
| BizSpark Plus | 64 |
| Microsoft Azure Sponsoring | 64 |
| Microsoft-Partnernetzwerk | 64 |
| Visual Studio Enterprise (MPN) | 64 |
| Visual Studio Enterprise | 32 |
| Visual Studio Enterprise (BizSpark) | 32 |
| Visual Studio Professional | 32 |
| MSDN-Plattformen | 32 |
1 Bei der Planung von Deployments sollte berücksichtigt werden, dass die Business Critical (BC) Service-Stufe viermal (4-fach-fach mehr vCore-Kapazität erfordert als die General Purpose (GP) Service-Schicht. Beispiel: 1 virtueller Kern „Universell“ = 1 V-Kern-Einheit, und 1 virtueller Kern „Unternehmenskritisch“ = 4 virtuelle Kerne. Um Ihre Verbrauchsanalyse anhand der Standardlimits zu vereinfachen, fassen Sie die vCore-Einheiten pro Hardware-Generation über alle Instanzen in der Region hinweg, in der die SQL Managed Instance eingesetzt wird, zusammen und vergleichen Sie die Ergebnisse mit den vCore-Einheitenlimits für Ihren Abonnementtyp. Die maximale Anzahl von vCore-Einheiten gilt für jedes Abonnement pro Hardwaregeneration in einer Region.
2 größere vCore-Limits sind in folgenden Regionen verfügbar: Australien Ost, Ost der USA, Ost US 2, Nordeuropa, Südzentral der USA, Südostasien, UK Süd, Westeuropa, West US 2.
Wichtig
Wenn dein vCore-Limit 0 ist, bedeutet das, dass das Standard-Regionallimit für deinen Abonnementtyp nicht gesetzt ist. Sie können auch eine Quotenerhöhungsanfrage nutzen, um in einer bestimmten Region Abonnementzugang zu erhalten, nach demselben Verfahren – also die erforderlichen vCore-Werte anzugeben.
Standard-regionale vCore-Limits können bei regionalen Kapazitätsbeschränkungen reduziert oder ausgesetzt werden.
Überprüfen Sie die vCore-Quotenbegrenzung und -nutzung mit PowerShell
Verwenden Sie die Subscription Usages – Holen Sie sich die REST-API, um das aktuelle vCore-Quotenlimit und den aktuellen Verbrauch für die Azure SQL Managed Instance in einem Abonnement und einer Region abzurufen. Abfragen Sie jede Hardwaregeneration einzeln, indem Sie ihren Nutzungsnamen angeben:
| Hardwaregenerierung | Verwendungsname |
|---|---|
| Standard-Serie (Gen5) | SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota |
| Premium-Serie | SubscriptionSQLManagedInstancePremiumSeriesVCoreQuota |
| Arbeitsspeicheroptimierte Premium-Serie | SubscriptionSQLManagedInstancePremiumSeriesMemoryOptimizedVCoreQuota |
Führen Sie das folgende Skript in einer PowerShell-Sitzung mit installiertem Az-Modul aus oder in Azure Cloud Shell mit PowerShell. Dein Konto benötigt die Erlaubnis, um die Nutzung des Abonnements zu lesen, wie zum Beispiel die Rolle Leser , die im Abonnementumfang zugewiesen ist.
Ersetzen Sie <subscription-id> sie durch Ihre Abonnement-ID, setzen $location Sie den Azure-Regionsnamen (zum Beispiel ), eastusund setzen $usageName Sie einen der Werte in der vorherigen Tabelle. Wenn du bereits über Cloud Shell angemeldet bist, lass das wegConnect-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
Beispielausgabe (Auszug; Werte sind illustrativ):
{
"name": "SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota",
"properties": {
"currentValue": 80,
"limit": 320,
"unit": "SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota"
}
}
In diesem Beispiel properties.currentValue ist der aktuelle Quotenverbrauch: 80 vCore-Einheiten.
properties.limit ist das aktuelle Quotenlimit: 320 vCore-Einheiten. Die verbleibende Quote beträgt limit - currentValue, also 240 vCore-Einheiten, für Standardserien-Hardware im angegebenen Abonnement und Region.
Wie bereits in diesem Abschnitt beschrieben, verbraucht jeder General Purpose vCore eine vCore-Einheit und jeder geschäftskritische vCore vier vCore-Einheiten. Wiederhole die Anfrage mit einer anderen $usageName oder $location überprüfe eine andere Hardware-Generation oder -region. Um das Limit zu erhöhen, siehe Quotenerhöhung anfordern.
Wichtig
Der zuvor verwendete VCoreQuota Verwendungsname, der eine einzige regionale Quote für alle Hardwaregenerationen darstellte, wird zugunsten hardware-generationsspezifischer Quoten eingestellt. Verwenden Sie die in der vorherigen Tabelle aufgeführten Nutzungsnamen, um das Quotenlimit und den Verbrauch für jede Hardwaregeneration abzurufen.
Anfordern einer Kontingenterhöhung
Wenn Sie mehr Instanzen in Ihren aktuellen Regionen benötigen, senden Sie eine Supportanfrage zur Erweiterung der Quote über das Azure-Portal. Weitere Informationen finden Sie unter Anforderungskontingenterhöhungen für Azure SQL-Datenbank und sql Managed Instance.
Hinweis
Ab August 2026 wurden die Quota-Anfragetypen von SQL Managed Instance geändert. Subnet-Quoten gelten nicht mehr, und vCore-Quoten sind nun pro Hardware-Generation begrenzt. Weitere Informationen finden Sie unter SQL Managed Instance Quota Request Types.