Übersicht über das Kaufmodell für virtuelle Kerne: Azure SQL-Datenbank und Azure SQL Managed Instance

Gilt für: Azure SQL Database Azure SQL Managed Instance

Dieser Artikel enthält eine kurze Übersicht über das Kaufmodell für virtuelle Kerne, das sowohl von Azure SQL-Datenbank als auch von Azure SQL Managed Instance verwendet wird. Weitere produktspezifische Informationen zum Kaufmodell für virtuelle Kerne finden Sie unter Kaufmodell für virtuelle Kerne: Azure SQL-Datenbank bzw. unter Kaufmodell für virtuelle Kerne: Azure SQL Managed Instance.

Überblick

Ein virtueller Kern (V-Kern) repräsentiert eine logische CPU und bietet Ihnen die Möglichkeit, die physischen Hardwaremerkmale (z. B. Anzahl der Kerne, Arbeitsspeicher und Speichergröße) auszuwählen. Beim vCore-basierten Kaufmodell erhalten Sie Flexibilität, Kontrolle und Transparenz in Bezug auf den individuellen Ressourcenverbrauch. Außerdem können Sie die lokalen Workloadanforderungen leicht auf die Cloud übertragen. Mit diesem Modell wird der Preis optimiert, und Sie können Compute-, Arbeitsspeicher- und Speicherressourcen entsprechend Ihren jeweiligen Workloadanforderungen auswählen.

Im vCore-basierten Kaufmodell hängen Ihre Kosten von der Auswahl und Verwendung der folgenden Elemente ab:

  • Dienstebene
  • Hardwarekonfiguration
  • Computeressourcen (Anzahl von virtuellen Kernen und Arbeitsspeichermenge)
  • Reservierter Datenbankspeicher
  • Tatsächlicher Sicherungsspeicher

Wichtig

In Azure SQL-Datenbank werden Computeressourcen (CPU und Arbeitsspeicher), E/A sowie Daten- und Protokollspeicher pro Datenbank oder Pool für elastische Datenbanken berechnet. Sicherungsspeicher wird pro Datenbank berechnet.

Das Kaufmodell für virtuelle Kerne bietet Transparenz in Bezug auf CPU-, Arbeitsspeicher- und Speicherressourcenzuordnung von Datenbanken, Hardwarekonfiguration, höhere Skalierungsgranularität und Preisrabatte mit Azure-Hybridvorteil (AHB) und reservierter Instanz (RI).

Für Azure SQL-Datenbank bietet das Kaufmodell für virtuelle Kerne höhere Compute-, Arbeitsspeicher-, E/A- und Speichergrenzwerte als das DTU-Modell.

Dienstebenen

Sowohl in Azure SQL-Datenbank als auch in Azure SQL Managed Instance sind zwei V-Kern-Dienstebenen verfügbar:

  • Universell ist eine budgetfreundliche Ebene, die für die meisten Workloads mit üblichen Leistungs- und Verfügbarkeitsanforderungen konzipiert ist.
  • Die unternehmenskritische Ebene ist für leistungsabhängige Workloads mit strengen Verfügbarkeitsanforderungen konzipiert.

Die Hyperscale-Dienstebene steht auch für Einzeldatenbanken in Azure SQL-Datenbank zur Verfügung. Diese Dienstebene ist für die meisten Geschäftsworkloads geeignet und bietet hochgradig skalierbaren Speicher, horizontale Leseskalierung, Schnellskalierung und eine schnelle Datenbankwiederherstellung.

Ressourceneinschränkungen

Weitere Informationen zu Ressourcenbeschränkungen finden Sie unter:

Computekosten

Das vCore-basierte Kaufmodell umfasst eine bereitgestellte Computeebene für Azure SQL-Datenbank und Azure SQL Managed Instance sowie eine serverlose Computeebene für Azure SQL-Datenbank.

Auf der bereitgestellten Computeebene spiegeln die Computekosten die gesamte Computekapazität wider, die kontinuierlich für die Anwendung bereitgestellt wird (unabhängig von der Workloadaktivität). Wählen Sie die Ressourcenzuordnung aus, die Ihren geschäftlichen Anforderungen hinsichtlich virtuellen Kernen und Arbeitsspeicher am besten entspricht, und skalieren Sie Ressourcen dann nach Bedarf für Ihre Workload herauf oder herunter.

Auf der serverlosen Computeebene für Azure SQL-Datenbank werden die Computeressourcen automatisch auf der Grundlage der Workloadkapazität skaliert und für die genutzte Computeleistung pro Sekunde in Rechnung gestellt.

Da der Dienstebene „Unternehmenskritisch“ automatisch drei zusätzliche Replikate zugeordnet werden, ist der Preis ungefähr 2,7 Mal höher als für die Dienstebene „Universell“. Entsprechend spiegelt der höhere Speicherpreis pro GB für die Dienstebene „Unternehmenskritisch“ die höheren E/A-Grenzwerte und die geringere Latenz des lokalen SSD-Speichers wider.

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

  • Jede Computegröße unterstützt eine konfigurierbare maximale Datengröße, die standardmäßig bei 32 GB liegt.
  • Wenn Sie die maximale Datengröße konfigurieren, kommen automatisch 30 Prozent zusätzlicher kostenpflichtiger Speicher für die Protokolldatei hinzu.
  • 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.
  • In den Dienstebenen „Universell“ und „Unternehmenskritisch“ wird Ihnen die maximale Speichergröße in Rechnung gestellt, die für eine Datenbank, einen Pool für elastische Datenbanken oder eine verwaltete Instanz konfiguriert ist.
  • Für SQL-Datenbank können Sie eine beliebige maximale Datengröße zwischen 1 GB und der unterstützten maximalen Speichergröße in Schritten von 1 GB auswählen. Für SQL Managed Instance können Datengrößen in 32-GB-Schritten bis zur unterstützten maximalen Speichergröße ausgewählt werden.

Wenn Sie die aktuell zugeordnete und verwendete Datenspeichergröße in SQL-Datenbank überwachen möchten, können Sie in Azure Monitor die Metrikallocated_data_storage bzw. storage verwenden.

Sowohl für SQL-Datenbank als auch für SQL Managed Instance kann die aktuell zugeordnete und verwendete Speichergröße einzelner Daten- und Protokolldateien in einer Datenbank mit T-SQL unter Verwendung der Ansicht sys.database_files und der Funktion FILEPROPERTY(... , 'SpaceUsed') überwacht werden.

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.

Sicherungsspeicher

Der Speicher für Datenbanksicherungen wird zugeordnet, um die Funktionen Zeitpunktwiederherstellung (Point in Time Restore, PITR) und Langzeitaufbewahrung (Long Term Retention, LTR) von SQL-Datenbank und SQL Managed Instance zu unterstützen. Dieser Speicher ist vom Daten- und Protokolldateispeicher getrennt und wird separat abgerechnet.

  • PITR: Bei den Ebenen „Universell“ und „Unternehmenskritisch“ werden einzelne Datenbanksicherungen automatisch in Azure-Speicher 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-Datenbank und 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 in Azure Blob Storage gespeichert. Sie können jedoch steuern, wie häufig die Sicherungen kopiert werden sollen. 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.

Nächste Schritte

Informationen zu den ersten Schritten finden Sie unter:

Ausführliche Informationen zu den spezifischen Compute- und Speichergrößen der Dienstebenen „Universell“ und „Unternehmenskritisch“ finden Sie hier: