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

  • Artikel
  • 17 Minuten Lesedauer

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 in mehreren Hardwarekonfigurationen bereitgestellt werden.

Hinweis

Die Gen5-Hardware wurde in die Standardreihe (Gen5) umbenannt.

Informationen zu zuvor verfügbarer Hardware finden Sie weiter unten in diesem Artikel unter Zuvor verfügbare Hardware.

Hardwarekonfigurationen 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)		 4 bis 80 virtuelle Kerne 4 bis 80 virtuelle Kerne 4 bis 64 virtuelle Kerne
Max. Arbeitsspeicherbelegung (Verhältnis Arbeitsspeicher/virtueller Kern) 5,1 GB pro virtuellem Kern
Fügen Sie weitere virtuelle Kerne hinzu, um mehr Arbeitsspeicher zu erhalten.		 7 GB pro V-Kern 13,6 GB pro virtuellem Kern
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
Maximal reservierter Instanzspeicher* 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

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.

Regionaler Support für arbeitsspeicheroptimierte Hardware der Premium-Serie

Support für arbeitsspeicheroptimierte Hardware der Premium-Serie ist derzeit nur in folgenden ausgewählten Regionen verfügbar:

Gebiet Regionen, die arbeitsspeicheroptimierte Hardware der Premium-Serie unterstützen
Europa, Naher Osten, Afrika Frankreich, Mitte; Deutschland, Westen-Mitte; Europa, Norden; Schweden, Mitte; Vereinigtes Königreich, Süden; Europa, Westen
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; 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
8 virtuelle Kerne 6,28 GB 8,79 GB 22,06 GB
16 virtuelle Kerne 15,77 GB 22,06 GB 57,58 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
64 virtuelle Kerne 99,9 GB 139,82 GB 288,61 GB
80 virtuelle Kerne 131,68 GB 184,30 GB –

Merkmale des Diensttarifs

SQL Managed Instance umfasst zwei Dienstebenen: Universell und Unternehmenskritisch.

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 Unternehmenskritisch
Anzahl der virtuellen Kerne* 4, 8, 16, 24, 32, 40, 64, 80 Standard-Serie (Gen5) : 4, 8, 16, 24, 32, 40, 64, 80
Premium-Serie: 4, 8, 16, 24, 32, 40, 64, 80
Arbeitsspeicheroptimierte Premium-Serie: 4, 8, 16, 24, 32, 40, 64
*Die gleiche Anzahl von virtuellen Kernen ist für Abfragen mit Schreibschutz dediziert.
Max. Arbeitsspeicherbelegung Standard-Serie (Gen5): 20,4 GB bis 625 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 625 GB (5,1 GB/virtueller Kern) auf jedem Replikat
Premium-Serie: 28 GB bis 560 GB (7 GB/virtueller Kern) auf jedem Replikat
Arbeitsspeicheroptimierte Premium-Serie: 54,4 GB bis 870,4 GB (13,6 GB/virtueller Kern) auf jedem Replikat
Max. Instanzspeichergröße (reserviert) – 2 TB für 4 virtuelle Kerne
– 8 TB für 8 virtuelle Kerne
– 16 TB für andere Größen
 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, 8 virtuelle Kerne
– 2 TB für 16, 24 virtuelle Kerne
– 4 TB für 32 virtuelle Kerne
– 5,5 TB für 40, 64, 80 virtuelle Kerne
Arbeitsspeicheroptimierte Premium-Serie:
– 1 TB für 4, 8 virtuelle Kerne
– 2 TB für 16, 24 virtuelle Kerne
– 4 TB für 32 virtuelle Kerne
– 5,5 TB für 40 virtuelle Kerne
– 16 TB für 64 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).
Max. Größe der tempdb-Datenbank 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
Max. Anzahl von Datenbanken pro Instanz 100 Benutzerdatenbanken (es sei denn, der Grenzwert für die Instanzspeichergröße wurde erreicht). 100 Benutzerdatenbanken (es sei denn, der Grenzwert für die Instanzspeichergröße wurde erreicht).
Max. Anzahl von Datenbankdateien pro Instanz Bis zu 280, außer wenn die Instanzspeichergröße oder der Grenzwert für Azure Premium Disk-Speicherbelegungsplatz erreicht wurde. 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).
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.
Daten-/Protokoll-IOPS (ungefähr) 500 bis 7.500 pro Datei
*Erhöhen Sie die Dateigröße, um den IOPS-Wert zu erhöhen		 16.000 – 320.000 (4.000 IOPS/virtueller Kern)
Fügen Sie weitere virtuelle Kerne hinzu, um die E/A-Leistung zu verbessern.
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. 96 MiB/s
Datendurchsatz (ungefähr) 100–250 MiB/s pro Datei
*Erhöhen Sie die Dateigröße, um die E/A-Leistung zu verbessern.		 Nicht begrenzt.
E/A-Speicherlatenz (ungefähr) 5 – 10 ms 1 – 2 ms
In-Memory-OLTP Nicht unterstützt Verfügbar, Größe hängt von der Anzahl der V-Kerne ab
Max. Sitzungen 30.000 30.000
maximale Anzahl gleichzeitiger Worker 105 * Anzahl der virtuellen Kerne + 800 105 * Anzahl der virtuellen Kerne + 800
Schreibgeschützte Replikate 0 1 (im Preis inbegriffen)
Computeisolation Nicht unterstützt, da Instanzen vom Typ „Universell“ physische Hardware mit anderen Instanzen teilen können. Standard-Serie (Gen5) :
unterstützt für 40, 64, 80 virtuelle Kerne
Premium-Serie: unterstützt für 64, 80 virtuelle Kerne
Arbeitsspeicheroptimierte Premium-Serie: unterstützt für 64 virtuelle Kerne

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 beibehalten und sind nicht in der Größe enthalten. Sicherungen sind nicht in der Speichergröße enthalten.
  • Durchsatz und IOPS im Tarif „Universell“ hängen auch von der Dateigröße ab, die nicht explizit durch SQL Managed Instance eingeschränkt wird. 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.

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 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 Verwalten von Dateispeicherplatz in Azure SQL-Datenbank.

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 0 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. Wie viel Speicher 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 12.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 Abonnementtypen

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

Regionale Ressourcenbeschränkungen

Hinweis

Um die neuesten Informationen zur regionalen Verfügbarkeit von Abonnements zu erhalten, verwenden Sie zunächst die Option Region auswählen.

Unterstützte Abonnementtypen können eine begrenzte Anzahl von Ressourcen pro Region umfassen. Abhängig vom Abonnementtyp gelten für SQL Managed Instance zwei Standardgrenzwerte pro Azure-Region (die bei Bedarf durch das Erstellen einer speziellen Supportanfrage im Azure-Portal erhöht werden können):

  • 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 Abonnementtypen angezeigt (die Standardgrenzwerte können über eine Supportanfrage erweitert werden):

Abonnementtyp 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 Abonnementtyps. Der Grenzwert Max number of vCore units (Maximale Anzahl von virtuellen Kerneinheiten) 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 Abonnementtyp nicht festgelegt ist. Sie können auch eine Anforderung für eine Kontingenterhöhung für von Abonnementzugriff in einer bestimmten Region nach demselben Verfahren verwenden, indem Sie die erforderlichen Werte für virtuelle Kerne und Subnetze 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.

Zuvor verfügbare Hardware

Dieser Abschnitt enthält Details zu zuvor verfügbarer Hardware. Ziehen Sie in Betracht, Ihre Instanz von SQL Managed Instance auf Hardware der Standard-Serie (Gen5) zu verschieben, um von einer größeren Bandbreite an virtuellen Kernen, einer höheren virtuellen Kern- und Speicherskalierbarkeit, einem beschleunigten Netzwerkbetrieb, einer optimalen E/A-Leistung und minimalen Wartezeiten zu profitieren.

Wichtig

Gen4-Hardware wird eingestellt und steht für neue Bereitstellungen nicht mehr zur Verfügung, wie am 18. Dezember 2019 angekündigt. Kunden, die Gen4-Hardware für Azure SQL-Datenbank, Pools für elastische Datenbanken oder SQL Managed Instance verwenden, sollten vor dem 31. März 2023 zu derzeit verfügbarer Hardware migrieren, etwa zur Standard-Serie (Gen5).

Bis zum 31. März 2023 werden vorhandene verwaltete Gen4 SQL-Instanzen automatisch zu gleichwertiger oder besserer Hardware migriert. Wenn das Upgrade automatisch erfolgt, können verwaltete Instanzen auf Hardware der Premium-Serie aktualisiert werden, was gemäß Azure SQL Managed Instance – Preise zu Preiserhöhungen führt.

Die Downtime, die durch die automatische Migration verursacht wird, ist minimal und ähnlich wie die Downtime während der Skalierung von Vorgängen innerhalb einer ausgewählten Dienstebene. Migrieren Sie proaktiv zu einem Zeitpunkt Ihrer Wahl vor dem 31. März 2023, um ungeplante Unterbrechungen für Workloads zu vermeiden. Weitere Informationen zur Gen4-Hardwareeinstellung und zur Migration zu aktueller Hardware finden Sie in unserem Blogbeitrag zur Gen4-Einstellung.

Hardwareeigenschaften

Gen4
Hardware Intel® E5-2673 v3-Prozessoren (Haswell) mit 2,4 GHz, angefügte SSD, virtueller Kern = 1 PP (physischer Kern)
Anzahl von virtuellen Kernen 8, 16, 24 virtuelle Kerne
Max. Arbeitsspeicher (Verhältnis Arbeitsspeicher/Kerne) 7 GB pro V-Kern
Fügen Sie weitere virtuelle Kerne hinzu, um mehr Arbeitsspeicher zu erhalten.
Max. In-Memory-OLTP-Speicher Grenzwert für Instanzen: 1–1,5 GB pro virtuellem Kern
Max. reservierter Instanzspeicher Allgemein: 8 TB
Unternehmenskritisch: 1 TB

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

Wichtig

Gen4-Hardware wird eingestellt und steht für neue Bereitstellungen nicht mehr zur Verfügung, wie am 18. Dezember 2019 angekündigt. Kunden, die Gen4-Hardware für Azure SQL-Datenbank, Pools für elastische Datenbanken oder SQL Managed Instance verwenden, sollten vor dem 31. März 2023 zu derzeit verfügbarer Hardware migrieren, etwa zur Standard-Serie (Gen5).

Bis zum 31. März 2023 werden vorhandene verwaltete Gen4 SQL-Instanzen automatisch zu gleichwertiger oder besserer Hardware migriert. Wenn das Upgrade automatisch erfolgt, können verwaltete Instanzen auf Hardware der Premium-Serie aktualisiert werden, was gemäß Azure SQL Managed Instance – Preise zu Preiserhöhungen führt.

Die Downtime, die durch die automatische Migration verursacht wird, ist minimal und ähnlich wie die Downtime während der Skalierung von Vorgängen innerhalb einer ausgewählten Dienstebene. Migrieren Sie proaktiv zu einem Zeitpunkt Ihrer Wahl vor dem 31. März 2023, um ungeplante Unterbrechungen für Workloads zu vermeiden. Weitere Informationen zur Gen4-Hardwareeinstellung und zur Migration zu aktueller Hardware finden Sie in unserem Blogbeitrag zur Gen4-Einstellung.

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 sind die Grenzwerte für den Arbeitsspeicher aufgelistet, der für In-Memory-OLTP-Objekte verwendet werden kann.

Arbeitsspeicher für In-Memory-OLTP Gen4
8 virtuelle Kerne 8 GB
16 virtuelle Kerne 20 GB
24 virtuelle Kerne 36 GB

Merkmale des Diensttarifs

Wichtig

Gen4-Hardware wird eingestellt und steht für neue Bereitstellungen nicht mehr zur Verfügung, wie am 18. Dezember 2019 angekündigt. Kunden, die Gen4-Hardware für Azure SQL-Datenbank, Pools für elastische Datenbanken oder SQL Managed Instance verwenden, sollten vor dem 31. März 2023 zu derzeit verfügbarer Hardware migrieren, etwa zur Standard-Serie (Gen5).

Bis zum 31. März 2023 werden vorhandene verwaltete Gen4 SQL-Instanzen automatisch zu gleichwertiger oder besserer Hardware migriert. Wenn das Upgrade automatisch erfolgt, können verwaltete Instanzen auf Hardware der Premium-Serie aktualisiert werden, was gemäß Azure SQL Managed Instance – Preise zu Preiserhöhungen führt.

Die Downtime, die durch die automatische Migration verursacht wird, ist minimal und ähnlich wie die Downtime während der Skalierung von Vorgängen innerhalb einer ausgewählten Dienstebene. Migrieren Sie proaktiv zu einem Zeitpunkt Ihrer Wahl vor dem 31. März 2023, um ungeplante Unterbrechungen für Workloads zu vermeiden. Weitere Informationen zur Gen4-Hardwareeinstellung und zur Migration zu aktueller Hardware finden Sie in unserem Blogbeitrag zur Gen4-Einstellung.

Feature Allgemeiner Zweck Unternehmenskritisch
Anzahl der virtuellen Kerne* 8, 16, 24 8, 16, 24
*Die gleiche Anzahl von virtuellen Kernen ist für Abfragen mit Schreibschutz dediziert.
Max. Arbeitsspeicherbelegung 56GB – 168GB (7GB/V-Kern)
Fügen Sie weitere virtuelle Kerne hinzu, um mehr Arbeitsspeicher zu erhalten.		 56GB – 168GB (7GB/V-Kern)
+ zusätzliche 20,4 GB – 408 GB (5,1 GB/V-Kern) für Abfragen mit Schreibschutz.
Fügen Sie weitere virtuelle Kerne hinzu, um mehr Arbeitsspeicher zu erhalten.
Max. Instanzspeichergröße (reserviert) 8 TB 1 TB
Max. Datenbankgröße Bis zur derzeit verfügbaren Instanzgröße (max. 2 TB – 8 TB, abhängig von der Anzahl der virtuellen Kerne). Bis zur derzeit verfügbaren Instanzgröße (max. 1 TB – 4 TB, abhängig von der Anzahl der virtuellen Kerne).
Max. Größe der tempdb-Datenbank 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 von Datenbanken pro Instanz 100 Benutzerdatenbanken (es sei denn, der Grenzwert für die Instanzspeichergröße wurde erreicht). 100 Benutzerdatenbanken (es sei denn, der Grenzwert für die Instanzspeichergröße wurde erreicht).
Max. Anzahl von Datenbankdateien pro Instanz Bis zu 280, außer wenn die Instanzspeichergröße oder der Grenzwert für Azure Premium Disk-Speicherbelegungsplatz erreicht wurde. 32.767 Dateien pro Datenbank, außer wenn der Grenzwert für die Instanzspeichergröße erreicht wurde.
Maximale Größe der Datendatei Begrenzt auf die derzeit verfügbare Instanzspeichergröße (max. 2 TB – 8 TB) und den Azure Premium Disk-Speicherbelegungsplatz. Verwenden Sie bei Datenbanken über 8 TB mindestens zwei Datendateien. Begrenzt auf die derzeit verfügbare Instanzspeichergröße (bis zu 1 TB – 4 TB).
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.
Daten-/Protokoll-IOPS (ungefähr) Bis zu 30-40.000 IOPS pro Instanz*, 500 – 7.500 pro Datei
*Erhöhen Sie die Dateigröße, um den IOPS-Wert zu erhöhen		 16.000 – 320.000 (4.000 IOPS/virtueller Kern)
Fügen Sie weitere virtuelle Kerne hinzu, um die E/A-Leistung zu verbessern.
Grenzwert für den Protokollschreibdurchsatz (pro Instanz) 3 MiB/s pro virtuellem Kern
Max. 120 MiB/s pro Instanz
22– 65 MiB/s pro Datenbank
*Erhöhen Sie die Dateigröße, um die E/A-Leistung zu verbessern.		 4 MiB/s pro virtuellem Kern
Max. 96 MB/Sek.
Datendurchsatz (ungefähr) 100–250 MiB/s pro Datei
*Erhöhen Sie die Dateigröße, um die E/A-Leistung zu verbessern.		 Nicht begrenzt.
E/A-Speicherlatenz (ungefähr) 5 – 10 ms 1 – 2 ms
In-Memory-OLTP Nicht unterstützt Verfügbar, Größe hängt von der Anzahl der V-Kerne ab
Max. Sitzungen 30.000 30.000
maximale Anzahl gleichzeitiger Worker 210 * Anzahl der virtuellen Kerne + 800 210 * Anzahl der virtuellen Kerne + 800
Schreibgeschützte Replikate 0 1 (im Preis inbegriffen)
Computeisolation Nicht unterstützt Nicht unterstützt

Nächste Schritte