Übersicht über Ressourcenlimits für Azure SQL Managed Instance
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 5,5 TB |
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.
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:
| Geografie | 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; USA, Mitte; USA, Osten; USA, Osten 2; USA, Norden-Mitte; USA, Süden-Mitte; USA, Westen; USA, Westen 2; USA, Westen 3 |
| Asien-Pazifik | Australien, Osten; Australien, Südosten; China, Norden 3; Indien, Mitte; Indien, Süden; 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.
| Feature | Allgemeiner Zweck | Universell der nächsten Generation | Unternehmenskritisch |
|---|---|---|---|
| Anzahl der virtuellen Kerne* | Standard-Serie (Gen5): 21, 4, 8, 16, 24, 32, 40, 64, 80 Premium-Serie: 21, 4, 8, 16, 24, 32, 40, 64, 80 Arbeitsspeicheroptimierte Premium-Serie: 4, 8, 16, 24, 32, 40, 64, 80 |
Standard-Serie (Gen5): 4, 8, 16, 24, 32, 40, 64, 80 Premium-Serie: 4, 6, 8, 10, 12, 16, 20, 24, 32, 40, 48, 56, 64, 80, 962, 1282 Arbeitsspeicheroptimierte Premium-Serie: 4, 6, 8, 10, 12, 16, 20, 24, 32, 40, 48, 56, 64, 802, 962, 1282 |
Standard-Serie (Gen5): 4, 8, 16, 24, 32, 40, 64, 80 Premium-Serie: 4, 6, 8, 10, 12, 16, 20, 24, 32, 40, 48, 56, 64, 80, 962, 1282 Arbeitsspeicheroptimierte Premium-Serie: 4, 6, 8, 10, 12, 16, 20, 24, 32, 40, 48, 56, 64, 802, 962, 1282 *Die gleiche Anzahl von virtuellen Kernen ist für Abfragen mit Schreibschutz dediziert. |
| Max. Arbeitsspeicherbelegung | Standard-Serie (Gen5) : 20,4 GB bis 408 GB (5,1 GB/virtueller Kern) Premium-Serie: 28 GB bis 560 GB (7 GB/virtueller Kern) Arbeitsspeicheroptimierte Premium-Serie: 54,4 GB bis 870,4 GB (13,6 GB/virtueller Kern) |
Standard-Serie (Gen5) : 20,4 GB bis 408 GB (5,1 GB/virtueller Kern) Premium-Serie: 28 GB bis 560 GB (7 GB/virtueller Kern) Arbeitsspeicheroptimierte Premium-Serie: 54,4 GB bis 870,4 GB (13,6 GB/virtueller Kern) |
Standard-Serie (Gen5): 20,4 GB bis 408 GB (5,1 GB/virtueller Kern) auf jedem Replikat Premium-Serie: 28 GB bis 560 GB (7 GB/virtueller Kern bis zu 80 virtuelle Kerne2) auf jedem Replikat Arbeitsspeicheroptimierte Premium-Serie: 54,4 GB bis 870,4 GB (13,6 GB/virtueller Kern bis zu 64 virtuelle Kerne2) auf jedem Replikat |
| Max. Instanzspeichergröße (reserviert) | Standard-Serie (Gen5): – 2 TB für 4 virtuelle Kerne – 8 TB für 8 virtuelle Kerne – 16 TB für andere Größen Premium-Serie: – 2 TB für 4 virtuelle Kerne – 8 TB für 8 virtuelle Kerne – 16 TB für andere Größen Arbeitsspeicheroptimierte Premium-Serie: – 2 TB für 4 virtuelle Kerne – 8 TB für 8 virtuelle Kerne – 16 TB für andere Größen |
Standard-Serie (Gen5): – 2 TB für 4 virtuelle Kerne – 8 TB für 8 virtuelle Kerne – 16 TB für andere Größen Premium-Serie: – 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 Arbeitsspeicheroptimierte Premium-Serie: – 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 |
Standard-Serie (Gen5): – 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: – 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 3 Arbeitsspeicheroptimierte Premium-Serie: – 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 Kerne4 - 12 TB für 48, 56 virtuelle Kerne - 16 TB für 64, 80, 96, 128 virtuelle Kerne |
| 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 |
1 Die Bereitstellung einer Instance mit 2 virtuellen Kernen ist nur innerhalb eines Instance-Pools möglich.
2 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.
3 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.
4 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.
Einige 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.
- Sie können mithilfe von Gruppen für ein automatisches Failover ein weiteres lesbares Replikat in einer anderen Azure-Region erstellen
- 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.
- 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 | Max. IOPS für die Dienstebene Universell der nächsten Generation | Max. IOPS für die Dienstebene 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 |
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
tempdblokaler SSD-Speicher verwendet, und diese Speicherkosten sind im V-Kern-Preis enthalten. - In der Dienstebene „Unternehmenskritisch“ wird für
tempdblokaler SSD-Speicher für Daten- und Protokolldateien gemeinsam genutzt, undtempdb-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 Metrikstorage_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.
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.
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:
- Enterprise Agreement (EA)
- Nutzungsbasierte Bezahlung
- Clouddienstanbieter (CSP)
- Enterprise Dev/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
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
- Weitere Informationen zu SQL Managed Instance finden Sie unter Was ist SQL Managed Instance?.
- Preisinformationen finden Sie auf der Seite mit den Preisen für SQL Managed Instance.
- Im Leitfaden für den Schnellstart erfahren Sie, wie Sie Ihre erste SQL Managed Instance-Instanz erstellen.
- SLA für Azure SQL Managed Instance
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für