Skalieren von Ressourcen für Pools für elastische Datenbanken in Azure SQL-Datenbank

GILT FÜR: Azure SQL-Datenbank

In diesem Artikel wird beschrieben, wie die für Pools für elastische Datenbanken und Pooldatenbanken in Azure SQL-Datenbank verfügbaren Compute- und Speicherressourcen skaliert werden können.

Ändern der Computeressourcen (virtuelle Kerne oder DTUs)

Nach dem Auswählen der Anzahl von virtuellen Kernen und eDTUs können Sie einen Pool für elastische Datenbanken dynamisch und bedarfsgerecht zentral hoch- oder herunterskalieren. Hierzu können Sie Folgendes verwenden:

Auswirkungen der Änderung der Dienstebene oder der Skalierung der Computegröße

Die Vorgehensweise zum Ändern der Dienstebene oder der Computegröße eines Pools für elastische Datenbanken ähnelt der Vorgehensweise für Einzeldatenbanken und umfasst im Wesentlichen folgende Schritte:

  1. Erstellen einer neuen Computeinstanz für den Pool für elastische Datenbanken

    Eine neue Computeinstanz für den Pool für elastische Datenbanken wird mit der angeforderten Dienstebene und Computegröße erstellt. Bei einigen Kombinationen von Dienstebenen- und Computegrößenänderungen muss in der neuen Computeinstanz jeweils ein Replikat der einzelnen Datenbanken erstellt werden. Dies umfasst das Kopieren von Daten und kann sich stark auf die Gesamtwartezeit auswirken. Die Datenbanken bleiben unabhängig davon während dieses Schritts online, und Verbindungen werden weiterhin an die Datenbanken in der ursprünglichen Computeinstanz weitergeleitet.

  2. Umleiten der Verbindungen zur neuen Computeinstanz

    Vorhandene Verbindungen mit den Datenbanken in der ursprünglichen Computeinstanz werden verworfen. Alle neuen Verbindungen werden mit den Datenbanken in der neuen Computeinstanz hergestellt. Bei einigen Kombinationen von Dienstebenen- und Computegrößenänderungen werden Datenbankdateien während des Wechsels getrennt und neu angefügt. Die Umstellung kann zu einer kurzen Dienstunterbrechung führen, in der Datenbanken in der Regel für weniger als 30 Sekunden nicht verfügbar ist. Sollten zu dem Zeitpunkt, zu dem die Verbindungen getrennt werden, zeitintensive Transaktionen ausgeführt werden, kann dieser Schritt länger dauern, da abgebrochene Transaktionen wiederhergestellt werden müssen. Mit der schnelleren Datenbankwiederherstellung können die Auswirkungen abgebrochener, zeitintensiver Transaktionen reduziert werden.

Wichtig

Während dieses Workflows gehen keine Daten verloren.

Wartezeit beim Ändern der Dienstebene oder beim Skalieren der Computegröße

Beim Ändern der Dienstebene, beim Skalieren der Computegröße einer Einzeldatenbank oder eines Pools für elastische Datenbanken, beim Verschieben einer Datenbank in einen/aus einem Pool für elastische Datenbanken oder beim Verschieben einer Datenbank zwischen Pools für elastische Datenbanken wird die geschätzte Wartezeit wie folgt parametrisiert:

Dienstebene Einzeldatenbank des Tarifs „Basic“,
Standard (S0-S1)
Pools für elastische Datenbanken des Tarifs „Basic“,
Standard (S2-S12),
Einzeldatenbank oder Pool für elastische Datenbanken des Tarifs „Universell“
Einzeldatenbank oder Pool für elastische Datenbanken der Tarife „Premium“ oder „Unternehmenskritisch“ Hyperscale
Einzeldatenbank des Tarifs „Basic“,
Standard (S0-S1)
•  Konstante Wartezeit unabhängig vom verwendeten Speicherplatz
•  In der Regel weniger als fünf Minuten
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
Pool für elastische Datenbanken des Tarifs „Basic“,
Standard (S2–S12),
Einzeldatenbank oder Pool für elastische Datenbanken des Tarifs „Universell“
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
•  Bei Einzeldatenbanken konstante Wartezeit unabhängig vom verwendeten Speicherplatz
•  In der Regel weniger als fünf Minuten bei Einzeldatenbanken
•  Bei Pools für elastische Datenbanken proportional zur Anzahl der Datenbanken
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
Einzeldatenbank oder Pool für elastische Datenbanken der Tarife „Premium“ oder „Unternehmenskritisch“ •  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
Hyperscale N/V N/V •  Konstante Wartezeit unabhängig vom verwendeten Speicherplatz
•  In der Regel weniger als zwei Minuten

Hinweis

  • Beim Ändern der Dienstebene oder Skalieren der Computegröße für einen Pool für elastische Datenbanken muss der verwendete Speicherplatz aller Datenbanken im Pool addiert werden, um die Schätzung zu berechnen.
  • Wenn eine Datenbank in einen oder aus einem Pool für elastische Datenbanken verschoben wird, ist für die Wartezeit nur der Speicherplatz relevant, der von der Datenbank verwendet wird, nicht der verwendete Speicherplatz des Pools für elastische Datenbanken.
  • Bei Pools für elastische Datenbanken vom Typ „Standard“ und „Universell“ verhält sich die Latenzzeit beim Verschieben einer Datenbank in einen/aus einem Pool für elastische Datenbanken oder zwischen Pools für elastische Datenbanken proportional zur Datenbankgröße, wenn für den Pool für elastische Datenbanken PFS-Speicher (Premium File Share, Premium-Dateifreigabe) verwendet wird. Um zu ermitteln, ob ein Pool PFS-Speicher verwendet, führen Sie die folgende Abfrage im Kontext einer beliebigen Datenbank im Pool aus. Wenn der Wert in der Spalte „AccountType“ PremiumFileStorage oder PremiumFileStorage-ZRS lautet, verwendet der Pool PFS-Speicher.
SELECT s.file_id,
       s.type_desc,
       s.name,
       FILEPROPERTYEX(s.name, 'AccountType') AS AccountType
FROM sys.database_files AS s
WHERE s.type_desc IN ('ROWS', 'LOG');

Tipp

Weitere Informationen zum Überwachen aktuell ausgeführter Vorgänge finden Sie unter: Verwalten von Vorgängen mit der SQL-REST-API, Verwalten von Vorgängen mithilfe der CLI, Überwachen von Vorgängen mit T-SQL und unter diesen beiden PowerShell-Befehlen: Get-AzSqlDatabaseActivity und Stop-AzSqlDatabaseActivity.

Weitere Überlegungen zum Ändern der Dienstebene oder Skalieren der Computegröße

  • Beim Verkleinern von virtuellen Kernen oder eDTUs für einen Pool für elastische Datenbanken muss die verwendete Poolspeichermenge kleiner als die maximal zulässige Größe der gewünschten Dienstebene und Pool-eDTUs sein.
  • Beim erneuten Skalieren von eDTUs für einen Pool für elastische Datenbanken fallen zusätzliche Speicherkosten an, wenn (1) die maximale Speichergröße des Pools vom Zielpool unterstützt wird und (2) die maximale Speichergröße die enthaltene Speichermenge für den Zielpool überschreitet. Wenn z.B. ein 100-eDTU-Standard-Pool mit einer maximalen Größe von 100 GB zu einem 50-eDTU-Standard-Pool herabgestuft wird, fallen zusätzliche Speicherkosten an, da der Zielpool eine maximale Größe von 100 GB unterstützt, und die enthaltene Speichermenge nur 50 GB beträgt. Daher beträgt die zusätzliche Speichermenge 100 GB – 50 GB = 50 GB. Ausführliche Informationen zu den Preisen für zusätzlichen Speicherplatz siehe SQL-Datenbank – Preise. Wenn die tatsächlich verwendete Speichermenge kleiner als die enthaltene Speichermenge ist, können Sie diese zusätzlichen Kosten vermeiden, indem Sie die maximale Datenbankgröße auf die enthaltene Menge reduzieren.

Abrechnung während der Skalierung

Die Abrechnung erfolgt für jede Stunde, in der eine Datenbank die höchste in dieser Stunde angewendete Dienstebene und Computegröße nutzt – unabhängig von der Verwendung der Datenbank und ob sie weniger als eine Stunde aktiv war. Wenn Sie beispielsweise eine Einzeldatenbank erstellen und diese fünf Minuten später löschen, wird Ihnen eine volle Datenbankstunde in Rechnung gestellt.

Ändern der Speichergröße in einem Pool für elastische Datenbanken

Wichtig

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.

vCore-basiertes Kaufmodell

  • Speicher kann bis zur maximalen Speichergröße bereitgestellt werden:

    • In den Dienstebenen „Standard“ oder „Universell“ erhöhen oder verringern Sie die Speichergröße in Schritten von 10 GB.
    • In den Dienstebenen „Premium“ oder „Unternehmenskritisch“ erhöhen oder verringern Sie die Speichergröße in Schritten von 250 GB
  • Der Speicher für einen Pool für elastische Datenbanken kann durch Erhöhen oder Verringern der Maximalgröße bereitgestellt werden.

  • Der Preis für den Speicher für einen Pool für elastische Datenbanken errechnet sich aus der Menge an bereitgestelltem Speicher multipliziert mit dem Speichereinheitenpreis für die Dienstebene. Ausführliche Informationen zu den Preisen für zusätzlichen Speicherplatz siehe SQL-Datenbank – Preise.

Wichtig

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.

DTU-basiertes Kaufmodell

  • Der eDTU-Preis für einen Pool für elastische Datenbanken enthält eine bestimmte Menge Speicher ohne zusätzliche Kosten. Zusätzlicher Speicher über die inbegriffene Speichermenge hinaus kann gegen zusätzliche Gebühren bis zur Obergrenze in Inkrementen von 250 GB bis zu 1 TB und dann in Inkrementen von 256 GB über 1 TB hinaus bereitgestellt werden. Informationen zu enthaltenen Speichermengen und Maximalgrößen finden Sie unter Pool für elastische Datenbanken: Speicher- und Computegrößen oder unter Ressourcenlimits für Pools für elastische Datenbanken, die das V-Kern-Kaufmodell verwenden.
  • Zusätzlicher Speicher für einen Pool für elastische Datenbanken kann durch Erhöhen der maximalen Größe mithilfe von Azure-Portal, PowerShell, Azure CLI oder REST-API bereitgestellt werden.
  • Der Preis für zusätzlichen Speicher für einen Pool für elastische Datenbanken errechnet sich aus der Menge an zusätzlich bereitgestelltem Speicher multipliziert mit dem Einheitenpreis für zusätzlichen Speicher für die Dienstebene. Ausführliche Informationen zu den Preisen für zusätzlichen Speicherplatz siehe SQL-Datenbank – Preise.

Wichtig

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.

Nächste Schritte

Allgemeine Ressourcenlimits finden Sie unter Ressourcenlimits des auf virtuellen Kernen basierenden Kaufmodells in SQL-Datenbank – Pools für elastische Datenbanken und unter Ressourcenlimits des auf DTUs basierenden Kaufmodells in SQL-Datenbank – Pools für elastische Datenbanken.