Freigeben über

Übersicht über Ressourcenlimits für Azure SQL Managed Instance

  • Artikel

Gilt für: Azure SQL Managed Instance

Dieser Artikel bietet eine Übersicht über die technischen Eigenschaften und Ressourcenlimits für Azure SQL Managed Instance und erläutert, wie Sie eine Anforderung zur Erhöhung dieser Grenzwerte erstellen.

Hinweis

Unterschiede bei den unterstützten Funktionen und T-SQL-Anweisungen sind unter Funktionsunterschiede und Unterstützung von T-SQL-Anweisungen zu finden. Weitere Informationen zu den allgemeinen Unterschieden zwischen Dienstebenen für Azure SQL-Datenbank und SQL Managed Instance finden Sie unter den Dienstebenen Universell und Unternehmenskritisch.

Hardwarekonfigurationseigenschaften

SQL Managed Instance umfasst Merkmale und Ressourcenlimits, die von der zugrunde liegende Infrastruktur und Architektur abhängen. SQL Managed Instance kann auf mehreren Hardwaregenerationen bereitgestellt werden.

Hardwaregenerationen weisen unterschiedliche Merkmale auf, wie in der folgenden Tabelle beschrieben:

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 bis 80 virtuelle Kerne 21 bis 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 Universell: bis zu 16 TB
Unternehmenskritisch: bis zu 4 TB		 Universell: bis zu 16 TB
Unternehmenskritisch: bis zu 16 TB3		 Universell: bis zu 16 TB
Unternehmenskritisch: bis zu 16 TB

1 Die Bereitstellung einer Instance mit 2 virtuellen Kernen ist nur innerhalb eines Instance-Pools möglich.
2 Abhängig von der Anzahl der virtuellen Kerne.
3 Nur die Hauptregionen können 16 TB Speicherplatz bereitstellen. Kleinere Regionen beschränken den verfügbaren Speicher auf 5,5 TB.

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 für 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. Die speicheroptimierte Hardware der Premium-Serie und die Hardware der Premium-Serie mit 16-TB-Speicher werden derzeit nur in diesen bestimmten Regionen unterstützt:

Gebiet Regionen, die speicheroptimierte Hardware der Premium-Serien und Hardware der Premium-Serien mit 16-TB-Speicher unterstützen
Europa Frankreich, Mitte; Deutschland, Westen-Mitte; Italien, Norden; Europa, Norden; Polen, Mitte; Schweden, Mitte; Schweiz, Norden; Vereinigtes Königreich, Süden; Europa, Westen
Naher Osten/Afrika Katar, Mitte
Amerika Brasilien, Süden; Kanada, Mitte; Kanada, Osten; USA, Mitte; USA, Osten; USA, Osten 2; USA, Norden-Mitte; USA, Süden-Mitte; USA, Westen; USA, Westen-Mitte USA, Westen 2
Asien-Pazifik Australien, Osten; Australien, Südosten; China, Norden 3; Indien, Mitte; Asien, Osten; Japan, Osten; Asien, Südosten

Verfügbarer Speicherplatz für In-Memory-OLTP

Die Menge des für In-Memory-OLTP verfügbaren Speicherplatzes auf der Dienstebene Unternehmenskritisch hängt von der Anzahl der virtuellen Kerne und der Hardwarekonfiguration ab. In der folgenden Tabelle werden die Grenzwerte für den Arbeitsspeicher aufgelistet, der für In-Memory-OLTP-Objekte verwendet werden kann.

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 sich für das Upgrade auf die Dienstebene Universell der nächsten Generation (Vorschau) entscheiden.

Wichtig

Die Dienstebene „Unternehmenskritisch“ bietet eine integrierte zusätzliche Kopie der SQL Managed Instance-Instanz (sekundäres Replikat), die für eine schreibgeschützte Workload verwendet werden kann. Wenn Sie Abfragen mit Lese-/Schreibzugriff und Schreibschutz-/Analyse-/Berichtsabfragen voneinander trennen können, erhalten Sie das Doppelte an virtuellen Kernen und Speicher für denselben Preis. Das sekundäre Replikat kann gegenüber der primären Instanz einige Sekunden verzögert sein, daher ist es auf die Auslagerung von Berichts-/Analyse-Workloads ausgelegt, bei denen der aktuelle Datenstatus nicht erforderlich ist. In der folgenden Tabelle sind die Abfragen mit Schreibschutz aufgeführt, die auf dem sekundären Replikat ausgeführt werden.

Anzahl der virtuellen Kerne

Hardwaregeneration 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

Hardwaregeneration 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.

Max. Instanzspeichergröße (reserviert)

Hardwaregeneration Allgemeiner Zweck Universell der nächsten Generation Unternehmenskritisch
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 andere Größen		 – 1 TB für 4, 8, 16 virtuelle Kerne
- 2 TB für 24 virtuelle Kerne
- 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 virtuelle Kerne
– 2 TB für 8, 10, 12 virtuelle Kerne
– 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 virtuelle Kerne 1
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 virtuelle Kerne
– 2 TB für 8, 10, 12 virtuelle Kerne
– 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 virtuelle Kerne2
- 12 TB für 48, 56 virtuelle Kerne
- 16 TB für 64, 80, 96, 128 virtuelle Kerne

1 Nur in den Hauptregionen können 16 TB Speicher für die Hardware der Premium-Serie für diese Zahlen von CPU und virtuellen Kernen bereitgestellt werden. Kleinere Regionen beschränken den verfügbaren Speicher auf 5,5 TB.
2 Nur in den Hauptregionen können 8 TB Speicher für die Hardware der speicheroptimierten Premium-Serie für diese Zahlen von CPU und virtuellen Kernen bereitgestellt werden. Kleinere Regionen beschränken den verfügbaren Speicher auf 5,5 TB.

Funktionsvergleich

Feature 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		 4,5 MiB/Sek. pro virtuellem Kern
Max. 192 MiB/s		 4,5 MiB/Sek. pro virtuellem Kern
Max. 192 MiB/s
E/A-Speicherlatenz (ungefähr) 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
Schreibgeschützte Replikate 0 0 1 (im Preis inbegriffen)
Computeisolation Nicht unterstützt, da General Purpose Instanzen physische Hardware mit anderen Instanzen teilen können Nicht unterstützt, da Universell der nächsten Generation Instanzen physische Hardware mit anderen Instanzen teilen können Standard-Serie (Gen5):
Unterstützt für Konfigurationen mit 64 oder mehr virtuellen Kernen
Premium-Serie: Unterstützt für Konfigurationen mit 64 oder mehr virtuellen Kernen
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 in Rechnung gestellt.		 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 in Rechnung gestellt.
Rabattmodelle Reservierte Instanzen
Azure-Hybridvorteil (nicht verfügbar für Dev/Test-Subscriptions)
Enterprise- und Dev/Test Pay-As-You-Go-Subscriptions		 Reservierte Instanzen
Azure-Hybridvorteil (nicht verfügbar für Dev/Test-Subscriptions)
Enterprise- und Dev/Test Pay-As-You-Go-Subscriptions		 Reservierte Instanzen
Azure-Hybridvorteil (nicht verfügbar für Dev/Test-Subscriptions)
Enterprise- und Dev/Test Pay-As-You-Go-Subscriptions

Weitere Überlegungen:

  • 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. Beachten Sie, dass eine bestimmte IOPS-Menge auch für automatische Sicherungen verwendet wird.
  • 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.

IOPS

Für die Dienstebenen Universell der nächsten Generation und Unternehmenskritisch werden die verfügbaren IOPS durch die Anzahl der virtuellen Kerne bestimmt:

  • Dienstebene Universell der nächsten Generation: Fester Wert von IOPS basierend auf der Anzahl der virtuellen Kerne. Im Preis des Speichers sind die minimalen IOPS enthalten. Wenn Sie das Minimum übersteigen, wird Ihnen Folgendes berechnet: 1 IOPS = Speicherpreis (nach Region) dividiert durch drei. Wenn z. B. 1 GB Speicher 0,115 kostet, dann 1 IOPS = 0,115/3 = 0,038 pro IOPS.
  • Dienstebene Unternehmenskritisch: Die IOPS-Grenzwerte werden nach einer Formel (4000 IOPS/virtuellem Kern) bestimmt.

In der folgenden Tabelle sind die maximal verfügbaren IOPS für jede Dienstebene basierend auf der Anzahl der virtuellen Kerne aufgeführt:

Anzahl der virtuellen Kerne Universell der nächsten Generation Unternehmenskritisch
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

Datei-E/A-Merkmale in der Ebene „Universell“

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. Die E/A-Merkmale der Datenbankdateien sind in der folgenden Tabelle aufgeführt:

Dateigröße >= 0 und <= 129 GiB > 129 und <= 513 GiB > 513 und <= 1.025 GiB > 1.025 und <= 2.049 GiB > 2.049 und <= 4.097 GiB > 4.097 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.

Daten- und Protokollspeicher

Die folgenden Faktoren wirken sich darauf aus, wie viel Speicherplatz für Daten- und Protokolldateien verwendet wird. Dies gilt für die Dienstebenen „Universell“ und „Unternehmenskritisch“.

  • In der Dienstebene „Universell“ wird für tempdb lokaler SSD-Speicher verwendet, und diese Speicherkosten sind im V-Kern-Preis enthalten.
  • In der Dienstebene „Unternehmenskritisch“ wird für tempdb lokaler SSD-Speicher für Daten- und Protokolldateien gemeinsam genutzt, und tempdb-Speicherkosten sind im V-Kern-Preis enthalten.
  • Die maximale Speichergröße für eine Instanz von SQL Managed Instance muss als Vielfaches von 32 GB angegeben werden.

Wichtig

Bei beiden Dienstebenen wird Ihnen die maximale Speichergröße in Rechnung gestellt, die für eine verwaltete Instanz konfiguriert ist.

Zum Überwachen der insgesamt verbrauchten Instanzspeichergröße für SQL Managed Instance verwenden Sie die Metrik storage_space_used_mb. Wenn Sie die aktuell zugeordnete und verwendete Speichergröße einzelner Daten- und Protokolldateien in einer Datenbank mit T-SQL überwachen möchten, verwenden Sie die Ansicht sys.database_files und die Funktion FILEPROPERTY(... , 'SpaceUsed').

Tipp

Unter bestimmten Umständen müssen Sie ggf. eine Datenbank verkleinern, um ungenutzten Speicherplatz freizugeben. 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. Zur Einhaltung unterschiedlicher Konformitätsanforderungen können Sie verschiedene Aufbewahrungszeiträume für wöchentliche, monatliche und/oder jährliche Sicherungen 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 Langfristiges Aufbewahren von Sicherungen.

Unterstützte Regionen

SQL Managed Instance-Instanzen können nur in unterstützten Regionen erstellt werden. Wenn Sie eine SQL Managed Instance-Instanz in einer Region erstellen möchten, die aktuell nicht unterstützt wird, können Sie eine Supportanfrage über das Azure-Portal senden.

Unterstützte Subscriptiontypen

SQL Managed Instance unterstützt aktuell nur die Bereitstellung für folgende Subscriptiontypen:

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. SQL Managed Instance hat zwei Standardlimits pro Azure-Region (die bei Bedarf erhöht werden können, indem eine spezielle Supportanfrage im Azure-Portal erstellt wird), je nach Art des Abonnements:

  • Subnetzlimit: Die maximale Anzahl von Subnetzen, wenn Instanzen von SQL Managed Instance in einer einzelnen Region bereitgestellt werden.
  • Grenzwert für virtuelle Kerneinheiten: Die maximale Anzahl von virtuellen Kerneinheiten, die in einer einzelnen Region über alle Instanzen hinweg bereitgestellt werden können. Ein virtueller Kern „Universell“ verwendet eine einzige virtuelle Kerneinheit, und ein virtueller Kern „Unternehmenskritisch“ verwendet vier virtuelle Kerneinheiten. Die Gesamtanzahl der Instanzen ist nicht begrenzt, solange sie innerhalb des Limits der virtuellen Kerneinheiten liegt.

Hinweis

Diese Limits sind Standardeinstellungen und keine technischen Einschränkungen. Die Limits können bei Bedarf erhöht werden, indem Sie eine spezielle Supportanfrage 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 SQL Managed Instance-Subnetze Standardgrenzwert für vCore-Einheiten*
CSP 16 (30 in manchen Regionen**) 960 (1440 in manchen Regionen**)
EA 16 (30 in manchen Regionen**) 960 (1440 in manchen Regionen**)
Enterprise Dev/Test 6 320
Nutzungsbasierte Bezahlung 6 320
Pay-as-you-go Dev/Test 6 320
Azure Pass 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
MSDN Platforms 3 32

* Berücksichtigen Sie bei der Planung von Bereitstellungen, dass die Dienstebene „Unternehmenskritisch“ (Business Critical, BC) vier Mal mehr Kapazität virtueller Kerne erfordert als die Dienstebene „Universell“ (General Purpose, GP). Beispiel: 1 virtueller Kern „Universell“ = 1 V-Kern-Einheit, und 1 virtueller Kern „Unternehmenskritisch“ = 4 virtuelle Kerne. Um die Nutzungsanalyse hinsichtlich der Standardgrenzwerte zu vereinfachen, fassen Sie die vCore-Einheiten für alle Subnetze in der Region zusammen, in der SQL Managed Instance bereitgestellt wird. Vergleichen Sie die Ergebnisse anschließend mit den Grenzwerten für Instanzeinheiten Ihres Subscriptiontyps. Maximale Anzahl von vCore-Einheiten gilt für jedes Abonnement in einer Region. Es gibt keinen Grenzwert pro individuellem Subnetz, außer dass die Summe aller in mehreren Subnetzen bereitgestellten virtuellen Kerne niedriger oder gleich der maximalen Anzahl von virtuellen Kerneinheiten sein muss.

** Höhere Grenzwerte für Subnetze und virtuelle Kerne sind in den folgenden Regionen verfügbar: Australien, Osten, USA, Osten, USA, Osten 2, Europa, Norden, USA, Süden-Mitte, Asien, Südosten, Vereinigtes Königreich, Süden, Europa, Westen, USA, Westen 2.

Wichtig

Wenn das Limit für virtuelle Kerne und das Subnet 0 ist, bedeutet dies, dass das regionale Standardlimit für Ihren Subscriptiontyp nicht festgelegt ist. Sie können auch einen Antrag auf Quotenerhöhung stellen, um in einer bestimmten Region Zugriff auf die Daten der Subscription zu erhalten, indem Sie das gleiche Verfahren anwenden und die erforderlichen vCore- und Subnetzwerte angeben.

Anfordern einer Kontingenterhöhung

Wenn Sie mehr Instanzen in Ihren aktuellen Regionen benötigen, senden Sie eine Supportanfrage zum Erweitern des Kontingents über das Azure-Portal. Weitere Informationen finden Sie unter Anfordern von Kontingenterhöhungen für Azure SQL-Datenbank.

Nächste Schritte