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

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:

¹ Die Bereitstellung einer Instance mit 2 virtuellen Kernen ist nur innerhalb eines Instance-Pools möglich.

² Abhängig von der Anzahl der virtuellen Kerne.

³ Nur die Hauptregionen können 16 TB Speicherplatz bereitstellen. Kleinere Regionen beschränken den verfügbaren Speicher auf 5,5 TB.

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:

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.

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.

Anzahl der virtuellen Kerne

¹ Die Bereitstellung einer Instance mit 2 virtuellen Kernen ist nur innerhalb eines Instance-Pools möglich.

Max. Arbeitsspeicherbelegung

¹ 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)

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

² 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

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

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

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:

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:

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.

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').

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 langfristige Aufbewahrung – Azure SQL-Datenbank und azure SQL Managed Instance.

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

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 Gesamtzahl der Instanzen ist nicht begrenzt, solange sie sich innerhalb des vCore-Einheitenlimits befindet.

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):

¹ Berücksichtigen Sie bei der Planung von Bereitstellungen, dass die Dienstebene business Critical (BC) viermal mehr vCore-Kapazität erfordert als die Dienstebene "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.

² Größere Subnetz- und vCore-Grenzwerte sind in den folgenden Regionen verfügbar: Australien Ost, Ost-USA, Ost-USA 2, Nordeuropa, Süd-Zentral-USA, Südostasien, Vereinigtes Königreich, Westeuropa, West-USA 2.

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 Anforderungskontingenterhöhungen für Azure SQL-Datenbank und sql Managed Instance.

Verwandte Inhalte

• Was ist azure SQL Managed Instance?
• für verwaltete SQL-Instanzen
• der Schnellstartanleitung
• SLA für Azure SQL Managed Instance